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):
/* 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.