Author Topic: Mozturbo help  (Read 55006 times)

xynixme

  • Guest
Re: Mozturbo help
« Reply #45 on: May 13, 2019, 12:59:48 pm »
FTR, regarding a .TYPE EA for marked DLLs: presumably both utilities, ABOVE512.EXE and HIGHMEM.EXE are open sourced. I'm not going to do it because of a.o. RPM being involved, but the programming community could introduce a standard LOADHIGH file .TYPE EA so other apps can detect that a DLL is marked by such an utility, without having to read the DLL file. And the DLL file with such an EA may possibly be linked to the tool with a undo-parameter (ASSOCTYPE-setting of its WPProgram object), and the icon of that utility.

Code: [Select]
/* Virtual, sample code to set intentionally ugly LoadDLLinMemoryAbove512MiBAllowed .TYPE EA for FOO.DLL */
CALL RxFuncAdd 'SysPutEA','RexxUtil','SysPutEA'

type='LoadDLLinMemoryAbove512MiBAllowed'
ea='DFFF00000100FDFF'x||D2C(Length(type))||'00'x||type

CALL SysPutEA 'FOO.DLL', '.TYPE', ea

EXIT

If both tools would set (and unset) the same .TYPE EA, then it will become a de facto standard for DLLs with a new mark. There is no need to mark the same DLL twice, and in case of possible new problems in the future a new app can warn that an earlier marked DLL can cause problems, without having to read bits of DLL files.

FWIW, but e.g. InsTurbo.EXE can skip the utility checks and changes when all DLLs, including read-only DLLs, are already marked.

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: Mozturbo help
« Reply #46 on: May 13, 2019, 01:07:33 pm »
Wow, that's fast! [insert your own turbo-joke here]... I've got all generic Turbo icon files I need now.

Here is another unload possible icon.

xynixme

  • Guest
Re: Mozturbo help
« Reply #47 on: May 13, 2019, 01:15:44 pm »
Here is another unload possible icon.
I'll use this creative one, because differences are even more clear. If there will be documentation written by me, then I'll credit you unless you don't want that.

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: Mozturbo help
« Reply #48 on: May 13, 2019, 01:26:40 pm »
Here is another unload possible icon.
I'll use this creative one, because differences are even more clear. If there will be documentation written by me, then I'll credit you unless you don't want that.

Andre, do what you want. It does not matter to me if I get credit or not.  I appreciate the effort you have put in to make the browser experience better.

xynixme

  • Guest
Re: Mozturbo help
« Reply #49 on: May 13, 2019, 02:02:51 pm »
Probably no credits then. I'm not even going to credit myself, because what I'm doing is nothing compared to having to deal with a wife not being able to use the phone until yet another 50+ MiB 1200/75 bps modem upload is finished. :-)

It'll be "fully functional, donated sample code".

e.g. InsTurbo.EXE can skip the utility checks and changes when all DLLs, including read-only DLLs, are already marked.
FWIW: setting such an EA could be restricted to the -c parameter of both utilities only. I guess it won't be perfect, but then "load high" was set correctly at least once...

And I've considered an uninstall option too, if VROBJ.DLL's relevant function works as expected (with REXXUTIL.DLL you may have to try to copy the object to <WP_NOWHERE> to confirm the source object exists), but all an uninstall will do is deleting the 2 WPS objects (and an implied deletion of the <WP_START> WPShadow object) per installed product. Uninstalling won't, for example, unmark the DLLs because a previous load high-setting is unrecorded and/or unknown.

xynixme

  • Guest
Re: Mozturbo help
« Reply #50 on: May 14, 2019, 05:29:02 pm »
1. The load-high (BEGIN-)LIBPATH functionality for NSS/NSPR support can be used for other DLLs too, like HUNSPEL0.DLL. Perhaps even better, AFAICT: if there's no HUNSPEL0.DLL, then don't try to load "required" HUNSPEL0.DLL functions. As stated earlier, I must have this DLL file installed, but I don't have to install any dictionaries. In my case the memory-world would be a better place without a HUNSPEL0.DLL.

2. I'll always save INSTURBO80.PNG, TURBO*.ICO and TURBO*80.PNG icon files in the same CHROME\ICONS\DEFAULT subdirectory as SM (and maybe TB), even when the product is Mozilla or Firefox. A clean main directory-policy, and no introduction of a second directory with icon files an user can use. The *.ICO files are used but none of the icon files is a requirement, so an user can decide to only install InsTurbo.EXE.

3. I'll print a warning when the size of MOZTURBO.EXE is 2371 bytes, i.e. (probably) IBM's and (probably) not yours. All MOZTURBO.EXEs don't support the turbo functionality, so to me prevention of SYS2070s is the only main difference.

4. It, or a sneak preview, may be ready before Warpstock Europe. ;) So far my concept keynote speech for someone is "A Turbo objects installer, a DLL high-loader and a default browser changer... Turbo objects! Load DLLs high! Are you getting it? These are not three separate apps. This is one app. And we are calling it InsTurbo. Here it is." :)
« Last Edit: May 14, 2019, 05:35:56 pm by André Heldoorn »

Eugene Tucker

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +12/-0
    • View Profile
Re: Mozturbo help
« Reply #51 on: May 16, 2019, 03:02:19 pm »
Hey on my laptop insturbo.cmd came back with a missing dll called freebl3.dll does anyone know what Yum package has that particular Dll? It worked perfectly fine on my desktop.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Mozturbo help
« Reply #52 on: May 16, 2019, 05:24:34 pm »
Hi Eugene

If you start ANPM and then click Find, select file and enter the filename you can quickly identify the package required.

In this case it seems to be in nss-softokn-feebl which I see should be available from netlabs-rel.


Regards

Pete

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Mozturbo help
« Reply #53 on: May 16, 2019, 05:47:00 pm »
It'll be included with the next release. I've reverted to the intree NSS and NSPR to allow updating the certificates and pins for security purposes.

xynixme

  • Guest
Re: Mozturbo help
« Reply #54 on: May 16, 2019, 07:21:23 pm »
0. Albeit there' s no need to move the NSS/NSPR DLLs to the tree of the Mozilla product w.r.t. InsTurbo, as long as it's installed in a CONFIG.SYS LIBPATH directory. If your install doesn't need it, then you can also copy any file to a missing DLL ("DIR > missing.DLL") if ABOVE512.EXE or HIGHMEM.EXE will just report an error ("Not a valid LX DLL") and continue. If your FF/SM/TB doesn't require a DLL, then you don't have to install it to please nothing but InsTurbo.

1. Perhaps a missing DLL also means a version of FF/SM/TB which is too old to be a default browser, because BEGINLIBPATH (not supported by WPUrl) is an implied recommended requirement then? If so, then the error text could be changed to e.g. "DLL(s) not found, or FF/SM/TB is too old (because apparently it doesn't require a newer DLL)".

2. Can a missing DLL become a warning instead of an error? I guess this depends on what you want to support. As such I have no problem with the fact that InsTurbo checks the setup, with a DLL-related error instead of a DLL-related warning. That was and is the current approach.

3. I've attached a first sample file, for any MOZILLA.EXE (and, optionally, MOZTURBO.EXE) only. My copy of Mozilla has a chrome\icons\default directory too, but in the case of FF the files can be moved to the directory of FF too. The file INSTURBO.ERR is a reserved file name, which may be deleted by INSTURBO.EXE. VROBJ.DLL is an usual, obvious requirement.

Unzip it in an empty directory, and execute INSTURBO.EXE

If there's any reported missing *.EXE file, then execute e.g. "DIR > MOZILLA.EXE" or "DIR > MOZTURBO.EXE" at the prompt and try again. Or copy a real *.EXE file. The *.EXE files just have to exist. ABOVE512.EXE or HIGHMEM.EXE aren't involved (no MOZILLA.EXE DLLs compiled and supported by Dave Yeo).

It may create the 3 WPS objects (2 at desktop, 1 in startup folder), and it may change OS2.INI even when the current WPUrl defaults are (a different) MOZILLA.EXE and/or working directory. If you don't want OS2.INI changes, then don't answer "Yes" during the confirmation of that setting.

When done, delete the 3 WPS objects, all files in the former empty directory (RM * -R), and restore the previous OS2.INI WPUrl default settings. By restoring OS2.INI, or by executing MOZTURBO.EXE in the directory of the old MOZILLA.EXE default browser.

There's no need to perform a full test, but of course any possible issue can be reported.
« Last Edit: May 16, 2019, 10:56:09 pm by André Heldoorn »

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: Mozturbo help
« Reply #55 on: May 16, 2019, 10:35:18 pm »
I noticed there is an updated above512

https://ecsoft2.org/above512

xynixme

  • Guest
Re: Mozturbo help
« Reply #56 on: May 16, 2019, 10:48:35 pm »
Only released because of IEEE 1541 (KiB, MiB). As such an upgrade is not required. Changes since v0.01b shouldn't be relevant.
« Last Edit: May 16, 2019, 10:51:10 pm by André Heldoorn »

xynixme

  • Guest
Re: Mozturbo help
« Reply #57 on: May 17, 2019, 01:28:23 am »
no plans to add any resources.
FTR, this is a programming subforum: if a beginner wants to add an existing GLOBE.ICO file as an icon resource to some quickly ported text-mode HELLOWORLD.EXE for Unix without an embedded OS/2 icon, then that may be as easy as typing:

Code: [Select]
ECHO ICON 1 GLOBE.ICO > HELLOWORLD.RC
RC HELLOWORLD.RC HELLOWORLD.EXE

Distributed source files will be slightly more complicated. No longer just the simplest HELLOWORLD.C file, but also a few extra files (*.ICO, *.RC, and optionally a *.MAK or a *.CMD file to build the EXE and to delete the *.OBJ and *.RES file).

xynixme

  • Guest
Re: Mozturbo help
« Reply #58 on: May 17, 2019, 10:11:03 am »
1. Due to an earlier RFC of Senior Management a missing DLL still is an error instead of a warning.

2. Dave, it's possible to replace the third-party > 512 MiB text-mode utilities by (yet) a(nother) DLL, if you don't mind having to include a InsTurbo.DLL file. Then the level of control and UI will improve, because now the user will have to check (duh!) the output. It's also easier to unlock DLLs and strictly use -c only, by using 1 known first-party utility instead of any of 2 third-party utilities. Processing may take a little bit longer, if you want to make sure that only -c is in use. Now it just executes e.g. "HIGHMEM.EXE -c XUL.DLL", and assumes that it'll work and that it's the right setting. A hit & hope strategy, which should typically work.

Do you want a (ABOVE512-based) Rexx DLL instead of using HIGHMEM.EXE or ABOVE512.EXE? If so, then a rather small, required InsTurbo.DLL file would appear in the main directory of the earlier MOZILLA.EXE preview, but the output dialog will no longer look like the attached "Please README.1ST and click here to accept the Terms & Conditions"-image.

xynixme

  • Guest
Re: Mozturbo help
« Reply #59 on: May 30, 2019, 08:34:18 pm »
Code: [Select]
/* OLD */
      arguments=dll.i '-c'
      IF Translate(FileSpec('N',high))='HIGHMEM.EXE' THEN arguments='-c' dll.i
      '@'||high arguments

Oops. A simplification during developments, and an usual Rexx code improvement related to supporting spaces in JFS/HPFS paths (of 8.3 DLL file names):

Code: [Select]
/* NEW (unverified) */

      '@"'||high||'" -c "'||dll.i||'"'

Above512 supports the same order of arguments, so there no longer is a need to reverse the order of the arguments.

Rexx doesn't understand the line with CMD.EXE's @, which will be send to the shell then. E.g. @"C:\MY TEST DIR\High Mem\HIGHMEM.EXE" "M:\Y TEST DIR\thunderbird\XUL.DLL" instead of @C:\MY TEST DIR\High Mem\HIGHMEM.EXE M:\Y TEST DIR\thunderbird\XUL.DLL