Author Topic: Mozturbo help  (Read 3867 times)

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #60 on: June 01, 2019, 03:10:56 pm »
Unrelated, but possibly relevant for users: "FFTURBO.EXE -u" to unload DLLs first may cause a TRAP. UNLOCKing individual DLLs works (not tested with ABOVE512.EXE's unlock parameter).

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 10
  • -Receive: 138
  • Posts: 1980
    • View Profile
Re: Mozturbo help
« Reply #61 on: June 01, 2019, 05:09:06 pm »
Unrelated, but possibly relevant for users: "FFTURBO.EXE -u" to unload DLLs first may cause a TRAP. UNLOCKing individual DLLs works (not tested with ABOVE512.EXE's unlock parameter).

If the DLLs were loaded high, this is likely a kernel issue.

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #62 on: June 05, 2019, 01:53:18 pm »
Quote from: Dave Yeo
Due to this there is also a new release of mozturbo

Also some icons, thanks to David Graser. The icons have to be associated manually for now.
0. Does TB have that chrome\icons\default subdirectory with icon files too (FF doesn't)?

1. In v0.7 there's no MOZTURBO.EXE. The installer supports the whole family.

2. In v0.7 there's no MOZTURBO.ICO.

3. It may be worth considering a MozTurbo product release per package (FF/MOZ/SM/TB). Each with shared files, like the README and the installer. To avoid unneeded EXE and ICO files, and to not introduce a chrome/icons/default subdirectory for FF. The installer does support both directories as a home of its icon files, and I guess an existing chrome/icons/default subdirectory is a good place for a xxTURBO.ICO file and a xTURBO_unloadl.ICO file.

4. The color of the turbo has changed. Then I'll also need a MOZTURBO.ICO (same as #2), and perhaps 4 icons in a crate for the "xxTURBO -u" unload objects.

5. The new color of the v0.7 turbo ("gold") no longer matches the color of the Turbo installer icon ("silver").

6. The installer can support a Turbo icon per product, when all of those files are available. Typically I've got 2 turbo's in use, so an icon per product in the folder <WP_START) does make some sense. To change this, I need that MOZTURBO.ICO.

7. MozTurbo v0.7 doesn't include the PNG version of the distributed ICO files.

The attached image shows the new "color problem", introduced by the distributed v0.7 icons.
« Last Edit: June 05, 2019, 01:57:30 pm by André Heldoorn »

David Graser

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 42
  • Posts: 416
    • View Profile
Re: Mozturbo help
« Reply #63 on: June 06, 2019, 12:08:02 am »
Quote from: Dave Yeo
Due to this there is also a new release of mozturbo

Also some icons, thanks to David Graser. The icons have to be associated manually for now.
0. Does TB have that chrome\icons\default subdirectory with icon files too (FF doesn't)?

1. In v0.7 there's no MOZTURBO.EXE. The installer supports the whole family.

2. In v0.7 there's no MOZTURBO.ICO.

3. It may be worth considering a MozTurbo product release per package (FF/MOZ/SM/TB). Each with shared files, like the README and the installer. To avoid unneeded EXE and ICO files, and to not introduce a chrome/icons/default subdirectory for FF. The installer does support both directories as a home of its icon files, and I guess an existing chrome/icons/default subdirectory is a good place for a xxTURBO.ICO file and a xTURBO_unloadl.ICO file.

4. The color of the turbo has changed. Then I'll also need a MOZTURBO.ICO (same as #2), and perhaps 4 icons in a crate for the "xxTURBO -u" unload objects.

5. The new color of the v0.7 turbo ("gold") no longer matches the color of the Turbo installer icon ("silver").

6. The installer can support a Turbo icon per product, when all of those files are available. Typically I've got 2 turbo's in use, so an icon per product in the folder <WP_START) does make some sense. To change this, I need that MOZTURBO.ICO.

7. MozTurbo v0.7 doesn't include the PNG version of the distributed ICO files.

The attached image shows the new "color problem", introduced by the distributed v0.7 icons.

some new pngs
« Last Edit: June 06, 2019, 12:29:13 am by David Graser »

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 10
  • -Receive: 138
  • Posts: 1980
    • View Profile
Re: Mozturbo help
« Reply #64 on: June 06, 2019, 04:06:16 am »
Quote from: Dave Yeo
Due to this there is also a new release of mozturbo

Also some icons, thanks to David Graser. The icons have to be associated manually for now.
0. Does TB have that chrome\icons\default subdirectory with icon files too (FF doesn't)?

Yes, it does.

Quote
1. In v0.7 there's no MOZTURBO.EXE. The installer supports the whole family.

2. In v0.7 there's no MOZTURBO.ICO.

Don't have the source for mozturbo.exe in my tree and which mozturbo? I have about half a dozen here :) I don't think many are using mozilla.exe of any version and likewise for Seamonkey v1.x. Anyone who is already has the mozturbo.exe for which ever version they're using.
I should update the documentation to reflect that it is supported though.
I lost track of the icons spread across different threads and didn't notice it. Could add it for next release.

Quote
3. It may be worth considering a MozTurbo product release per package (FF/MOZ/SM/TB). Each with shared files, like the README and the installer. To avoid unneeded EXE and ICO files, and to not introduce a chrome/icons/default subdirectory for FF. The installer does support both directories as a home of its icon files, and I guess an existing chrome/icons/default subdirectory is a good place for a xxTURBO.ICO file and a xTURBO_unloadl.ICO file.

It's a consideration that needs thought. I figure most people already have at least a couple of moz apps installed.

Quote
4. The color of the turbo has changed. Then I'll also need a MOZTURBO.ICO (same as #2), and perhaps 4 icons in a crate for the "xxTURBO -u" unload objects.

5. The new color of the v0.7 turbo ("gold") no longer matches the color of the Turbo installer icon ("silver").

Once again, I think I lost track of which icons I downloaded, sorry.

Quote
6. The installer can support a Turbo icon per product, when all of those files are available. Typically I've got 2 turbo's in use, so an icon per product in the folder <WP_START) does make some sense. To change this, I need that MOZTURBO.ICO.

I'll see about finding the icons and perhaps adding an icon package or a version 0.8

Quote
7. MozTurbo v0.7 doesn't include the PNG version of the distributed ICO files.

I'll add a PNG package starting with David's pngs that he just posted.

Quote
The attached image shows the new "color problem", introduced by the distributed v0.7 icons.

:( Need to find the right icons.

David Graser

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 42
  • Posts: 416
    • View Profile
Re: Mozturbo help
« Reply #65 on: June 06, 2019, 04:10:37 am »
Dave,

I am working on some new OS/2 icons for those PNGs.

Mozturbo - Is it a turbo with a mozilla icon?  Is that is what is needed?
« Last Edit: June 06, 2019, 05:00:54 am by David Graser »

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 10
  • -Receive: 138
  • Posts: 1980
    • View Profile
Re: Mozturbo help
« Reply #66 on: June 06, 2019, 05:52:08 am »
Dave,

I am working on some new OS/2 icons for those PNGs.

Mozturbo - Is it a turbo with a mozilla icon?  Is that is what is needed?

I believe that is what André is talking about.
Thanks

David Graser

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 42
  • Posts: 416
    • View Profile
Re: Mozturbo help
« Reply #67 on: June 06, 2019, 07:02:01 am »
Dave,

I am working on some new OS/2 icons for those PNGs.

Mozturbo - Is it a turbo with a mozilla icon?  Is that is what is needed?

I believe that is what André is talking about.
Thanks

PNGs
« Last Edit: June 06, 2019, 07:36:51 am by David Graser »

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #68 on: June 12, 2019, 03:56:41 pm »
1. The UI of the PM version, unlike the CMD file, now supports entering any base directory of the third-party utility, e.g.

Code: [Select]
D:
D:\
D:\TOOLS
D:\TOOLS\NON-PATH\
D:\TOOLS\NON-PATH\ABOVE512
D:\TOOLS\NON-PATH\MEM\HIGHMEM\

So the user doesn't always have to type the full directory path anymore, in case the user decided to type the path. Of course the longer the typed path, the faster any qualifying utility will be found. Other methods are searching or selecting the utility.

2. If the color of the metal changes to silver again (fine with me, easier for me and probably easier for David) compared with the v0.7 turbo distribution, then I'll look at the full collection of new icons later. The installer supports all TURBO.EXEs compiled by Dave indeed, so MOZTURBO.EXE for Mozilla belongs to the family too. His MOZTURBO.EXE solves a SYS2070 error. The main difference is that loading DLLs high is not supported then, but users still can install that turbo and/or change a default WPUrl setting to set or restore Mozilla as the default WPUrl browser.

For me the only minor change is a turbo icon/PNG per product (MOZ/FF/SM/TB) and a turbo unload icon/PNG per product, instead of a generic icon.

3. The *TURBO.ICO of the *TURBO.EXEs can be an embedded resource (MAKEFILE, RC.EXE-line), but I still assume Dave won't do that.

4. D&D. If the user should be able to drop ABOVE512.EXE or HIGHMEM.EXE, then I need a 40x40'ish OS/2 bitmap artwork for the drop zone, with a maximum of 256 colors. Not much larger. This is NOT a request, but if creative juices come up with a really great design then I'm willing to use it. I guess it should be clear that it's a drop zone. The attached "under construction" artwork roughly shows the area and context. "Search..." the utility, or drop it. I suggest to NOT support drag & drop, unless a design is really, really great. The user can drop any file object, so a design may be as generic as a file magnet or file whirlpool. Please do NOT design anything unless those juices come up with a really, really great design, because supporting D&D is overdoing it a little bit. So this really is NOT a request. I'm just willing to conceed if a design is a winner, which clearly indicates there's a drop zone.
« Last Edit: June 12, 2019, 03:58:50 pm by André Heldoorn »

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #69 on: June 12, 2019, 04:59:38 pm »
I'll attach a full sample distribution file for Mozilla only (distribution per product), with the latest silver icon status per product (i.e. just the Mozilla browser, in this case).

MOZILLA.EXE and all text files are bogus, and I had to rename Dave Yeo's file LICENSE to LICENSE.TXT because there already is a LICENSE file in my original x:\PROGRAMS\MOZILLA directory.

Normally the user has to unzip this sample package in the directory of MOZILLA.EXE, but for a sneak preview you can unzip it in an empty directory.

Using any PNG file is optional. Users may delete those PNG files. If the user doesn't want the .\chrome\icons\default\*TURBO*.ICO files in that Mozilla directory, then the user can move those *TURBO*.ICO files to the directory of MOZILLA.EXE. A clean main directory-policy, or a clean chrome\icons\default directory-policy.

Do not use this sneak preview package, with the latest icons by David Graser, for anything else. It's not retested, and it's incomplete. In theory it should work for Mozilla (no DLLs loaded high, no turbo fuctionality).

In the end it can be distributed as a single package, probably with too many icon files (for each product) and Firefox has no icons subdirectory. This sample is a virtual distribution per product, i.e. Mozilla.

The only icons change was replacing the generic turbo (un)load icons by - in this case - Mozilla turbo (un)load icons. I will not change the CMD file accordingly.
« Last Edit: June 12, 2019, 05:06:01 pm by André Heldoorn »

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #70 on: June 12, 2019, 06:16:53 pm »
FTR I'll attach the full latest collection of renamed (silver) artwork in actual use, without having looked at EAs, and so on. A few of the file names are identical to the ones in the v0.7 distribution. From my point of view the collection is complete.

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #71 on: June 12, 2019, 06:37:24 pm »
Don't have the source for mozturbo.exe in my tree and which mozturbo? I have about half a dozen here :) I don't think many are using mozilla.exe of any version and likewise for Seamonkey v1.x. Anyone who is already has the mozturbo.exe for which ever version they're using.

Mozilla with an outdated, but by default unused, MOZTURBO.EXE, is probably the default browser for many users of eCS. I, for one, am using whatever the default is, with NETSCAPE.EXE being the single downgraded explicit exception. For local HTML files.

I'll attach the one without SYS2070, including source. Not sure if you distributed it this way, or that I did append the source file to the package. It is a member of the family, and there's probably no reason to not promote its MOZTUBO.EXE.

But ... InsTurbo.EXE will a show a warning when its MOZTURBO.EXE has a known size of 2371 bytes. A warning, because the user can upgrade MOZTURBO.EXE afterwards, and the old MOZTURBO.EXE will probably work often. Often, but not always (SYS2070s).

For InsTurbo it's a member of the family. The installer could support all known browsers, but restrictions are (A) being a member of the Mozilla family of products and (B) the availability of a version of *TURBO.EXE compiled by you.

I guess a main use of its support may be the standardized ability to downgrade to a MOZILLA.EXE browser, and it does promote the use of *TURBO.EXEs in general. Hence the earlier choice to not exclude the old MOZILLA.EXE. Excluding it later isn't that hard, because it intentionally is the only product abbreviation with a length of 3 characters.

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #72 on: June 12, 2019, 06:55:32 pm »
It's a consideration that needs thought. I figure most people already have at least a couple of moz apps installed.

I'll add a PNG package starting with David's pngs that he just posted.
Quite likely indeed. Here 3 installed per system (Mozilla, FF and SM), with 2 modern turbo's with settings which make the most sense. Or least non-sense. MOZTURBO.EXE always is one of the TURBOs. I still have to look at a few possible optimizations or changes.

I've compiled a package in actual by InsTurbo.EXE righ now, which includes your v0.7 file names FFTURBO.ICO, SMTURBO.ICO and TBTURBO.ICO. And matching *80.PNG file names.

I've decided to use the existing subdirectory with icons, which only FF doesn't have then, but as stated earlier the *.ICO files can be moved to the directory of teh main EXE too. For InsTurbo.EXE the PNG files play no role, so those files can be saved anywhere.

So far the goal remains that the user can unzip a Turbo package in the main directory, with a single InsTurbo.EXE. So far the only possible conflict is an existing LICENSE in MOZILLA.EXE's directory, and FF doesn't have that .\chrome directory structure with icons. No big deals at all. Each distribution method has a disadvantage.

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 57
  • -Receive: 15
  • Posts: 537
    • View Profile
Re: Mozturbo help
« Reply #73 on: June 14, 2019, 12:53:23 pm »
Automated installers, because a v0.8 of InsTurbo.EXE should be released soon (via Dave Yeo):

InsTurbo.EXE doesn't supports all DLLs which should be save to load high. HUNSPEL0.DLL, for example. So you will have to mark and repackage DLLs anyway, and mark those DLLs again after a third-party upgrade via another installer.

The user/customer/buyer has to execute InsTurbo.EXE after each unautomated upgrade of the Mozilla product, to mark the DLLs of the product again. This may require installing a common WPProgram object for InsTurbo.EXE.

For managed systems the manager can execute the installer once, per sale or per upgrade of the Mozilla product, and distribute a repackaged Mozilla product (with e.g. marked DLLs and a MozTurbo package). This matches the distribution method of a marked HUNSPEL0.DLL and other third-party DLLs, which should be okay to mark. The WPProgram objects and WPUrl settings aren't anything special, i.e. no hidden tricks, so SysIni() for WPUrl objects and SysCreateObject()/SysCreateShadow() can be used in any other own simple Rexx install script.

Missing Mozilla DLLs are reported (as an error, as requested), so even closed source it's possible to find out which DLLs will be marked.

In general it's good to keep an automated install in mind. In this case there's probably no or little added value. An upgrade of any of the non-legacy Mozilla product would require an automated install too, to mark the distributed DLLs as high again.

New is that a missing SysBootDrive() function should come down to not scanning the LIBPATH line in CONFIG.SYS for DLLs. If needed, one can distribute an ancient version of REXXUTIL.DLL  Then don't move required, shared Mozilla DLLs to the LIBPATH. I could insert old Rexx code to find the boot drive anyway, but I assume an outdated REXXUTIL.DLL and other system DLLs can always be upgraded, regardless of the language of the OS. It's recommended to not move DLLs in the base directory of the Mozilla product to the LIBPATH when the managed system has an old version of REXXUTIL.DLL. A test, for users of an old version of OS/2 (probably older than the Y2K FixPak and/or modern APIs):

Code: [Select]
/* BootTest.CMD, for the oldest versions of OS/2 with an installed Mozilla browser (not tested) */

CALL RxFuncAdd 'SysLoadFuncs','RexxUtil','SysLoadFuncs'
CALL SysLoadFuncs

/* All REXXUTIL.DLL functions for Rexx loaded; next test if SysBootDrive() is one of those functions */

IF RxFuncQuery('SysBootDrive')=1 THEN DO
   SAY 'Please do not move Mozilla DLLs to the LIBPATH, or perhaps upgrade components of your system first.'
   EXIT
END

SAY 'SysBootDrive() is available, as expected. The boot drive is:' SysBootDrive()

EXIT

Please note that DLLs loadable above 512 MiB require a rather modern kernel too, so a missing SysBootDrive() function is not that likely. Typically REXXUTIL.DLL will have to be downgraded, which is extremely unlikely at the moment. InsTurbo.EXE supports that, but then you shouldn't move Mozilla DLLs to a LIBPATH directory.

I have no solution for non-high DLLs installed/upgraded by other installers later, like HUNSPEL0.DLL and other large DLL files, or an upgrade of the Mozilla product. That could require a ".LOADHIGH" EA, and Mozilla products checking the DLLs and matching EAs.

Neil Waldhauer

  • Sr. Member
  • ****
  • Thank You
  • -Given: 7
  • -Receive: 25
  • Posts: 420
    • View Profile
    • Blonde Guy
Re: Mozturbo help
« Reply #74 on: June 14, 2019, 03:31:39 pm »
Only a few automated installers fail to support automated installation. Is it really that hard?

I'm finding that the Bitwise Firefox build is quite a bit more stable here. I'm guessing that depends on what web pages we visit. For the pages I visit, Bitwise Firefox lasts about 10x longer than Nightly. Neither one lasts very long.

Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com