Author Topic: mozturbo  (Read 35338 times)

xynixme

  • Guest
Re: mozturbo
« Reply #30 on: January 29, 2019, 09:38:09 am »
I also marked some of the supporting DLLs to load high, namely icudt.dll, icuin.dll, icuuc.dll, hunspell10.dll, libvpx4.dll as they used the most and seemed safe. The NSPR and NSS DLLs are probably safe as well.
Is XUL.DLL the single other one (of  your "I also ...")?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: mozturbo
« Reply #31 on: January 29, 2019, 06:03:24 pm »
Usually (sometimes out of laziness, just xul.dll) I've been marking all the DLLs included with the moz app to load code high. Note that "make package" leaves some DLLs marked readonly for some reason and they need to be have that attribute changed. "Make install" doesn't mark them readonly. My dists are made with "make package"

xynixme

  • Guest
Re: mozturbo
« Reply #32 on: January 31, 2019, 04:36:08 pm »
icudt.dll, icuin.dll, icuuc.dll, hunspell10.dll, libvpx4.dll as they used the most and seemed safe.
FWIW, not important: with those and XUL.DLL marked as high, and MOZTURBO.EXE started with a.o. LIBPATHSTRICT=T, both SMTURBO.EXE -t (in WP_START) and SEAMONKEY.EXE produce a SYS2070 once. Even after a cold boot. Kill SMTURBO.EXE (and MOZTURBO.EXE), mark XUL.DLL as high (again), shutdown, power off, wait a few seconds, power on, wait until a.o. FFTURBO.EXE should have done its job, start SeaMonkey, ...

Code: [Select]
01-31-2019  16:13:05  SYS2070  PID 0034  TID 0001  Slot 0097
D:\SEAMONKEY\SMTURBO.EXE
XUL->PLDS4.26
182
------------------------------------------------------------

01-31-2019  16:13:35  SYS2070  PID 0036  TID 0001  Slot 0095
D:\SEAMONKEY\SEAMONKEY.EXE
XUL->PLDS4.26
182
Once, with a Pentium 4 machine. After a next warm reboot everything worked as expected. Always, so far. May be normal, it's the first time I'm really using this high-memory feature.

I'll mark the other suggested ones as high later (NSS/NSPR?). If the rare SYS2070s occur again, then I'll use a full XOR approach. SMTURBO XOR FFTURBO XOR MOZTURBO. Now it's (SMTURBO XOR FFTURBO) and MOZTURBO.


The eCS 1.2 UNI 104 kernel of a Pentium III IBM ThinkPad 600X (with SMTURBO.EXE -l) crashed, twice, when I tried to kill SMTURBO.EXE via CAD before marking XUL.DLLs of FF/SM as high (done, unlocking is an alternative without a crashing kernel). One of the kernel crashes may have been related to an USB flash drive.


So far, so good.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: mozturbo
« Reply #33 on: January 31, 2019, 06:45:25 pm »
Weird that you're getting a sys2070 with LIBPATHSTRICT. Are you setting BEGINLIBPATH with uppercase Pathnames? If so, try lower casing them. FYI, the missing export is
_PL_SizeOfArenaPoolExcludingPool @26 RESIDENTNAME
which seems to have been introduced between 17 and 24.
Also, are you trying to mark SM1.19 DLLs to load high? This is unsupported and untested and may fail due to using an old version of os2safe.h (and who knows what else), but then again might work. Really it could be recompiled, but judging by how many casts I had to add to mozturbo, it is a bigger job then I feel like undertaking.
The kernel crashes are possibly kernel bugs in unloading DLLs marked to load high, a known issue with newer kernels being patched to fix some of these bugs. Another reason to keep them loaded. BTW, why use the uni kernel? The W4 kernel will give perhaps 10% better performance and ArcaOS doesn't even include the uni kernel as it doesn't add anything but overhead.

I've recompiled the old mozturbo with LIBPATHSTRICT if you want to test. This is only for use with SM 1.19 and is untested.

Edit, forgot to mention that I usually run all 3 turbo programs, ffturbo, smturbo and tbturbo without problems.

xynixme

  • Guest
Re: mozturbo
« Reply #34 on: February 05, 2019, 03:17:44 am »
FWIW: the system load during boots seems to be too much for XWLAN. With a T42p I have to restart it to obtain a connection, which never was a problem before the *TURBO.EXEs were in use. Is a built-on delay of a few milliseconds be an option, instead of pumping DLLs to memory with all available power? I don't know if that could prevent the rare SYS2070s too. As if setting up a WLAN connection is time-critical, but it doesn't get enough time slices.

In the case of the ThinkPad T42p I'm using MOZTURBO.EXE -l (old, with LIBPATSTRICT setting) and FFTURBO.EXE -t. A slower T23 has the same problem.

Weird that you're getting a sys2070 with LIBPATHSTRICT. Are you setting BEGINLIBPATH with uppercase Pathnames? If so, try lower casing them. FYI, the missing export is _PL_SizeOfArenaPoolExcludingPool @26 RESIDENTNAME which seems to have been introduced between 17 and 24.
Yes, uppercased or a reality-matching mixed case. I've got a registered version of DragText, so I can edit the settings and change it to lower case.

The latest change was to mark XUL.DLLs as high too, after HUNSPEL0.DL (first test) and next the other generic DLLs. If that works fine everywhere (a.o. old hardware with far less than 512 MiB of RAM), then I'll try to test lower cased path settings.

The entry point always was 26. If I mark XUL.DLL as high (yes: again, shouldn't be a change) then the expected result after a reboot is a SYS2070 by  XUL.DLL. I'm not sure if a SYS2070 occured after marking XUL.DLL as high and after 2 reboots. If it did occur, without trying to reproduce it, then it occured once.

Quote
Also, are you trying to mark SM1.19 DLLs to load high? This is unsupported and untested and may fail
Certainly not. Only full file names specfiied by you. So just XUL.DLL in the FF/SM directories, and not yet the NS* ones which "should be safe". Code only.

Quote
Another reason to keep them loaded. BTW, why use the uni kernel? The W4 kernel will give perhaps 10% better performance and ArcaOS doesn't even include the uni kernel as it doesn't add anything but overhead.
The only reason to upgrade the default (eCS 1.2) kernel was because some software packages may require a newer version. Apparently I'm using uni20050811.zip

Quote
I've recompiled the old mozturbo with LIBPATHSTRICT if you want to test. This is only for use with SM 1.19 and is untested.
Willling. With the T42 and LIBPATHSTRICT aplies to the old  MOZTURBO.EXE Mozilla fails to start at the moment (no SYS2070), but it's the default browser of eCS 1.2. Probably 1.19; no newer or older version installed by an user.

Quote
Edit, forgot to mention that I usually run all 3 turbo programs, ffturbo, smturbo and tbturbo without problems.
Here SYS2070s after the initial SYS2070 are quite rare, there's that XWLAN issue, and I just noticed that I couldn't start Mozilla (MOZTURBO uses LIBPATHSTRICT, and so does the WPProgramobject of Mozilla itself).

Mozilla is a single, unreproduced case. The SYS2070s are too rare to not use the smart functionality, and XWLAN always has problems setting up a connected with any of the heavier *TURBOs in use. Could be reproducable with "-t" and a T42.

I've restricted the number FFTURBO.EXE and/or SMTURBO.EXE in use to 1 per install, with -l or -t. And MOZTURBO. A next test coud be to get rid of MOZTURBO, which is just an old member of an old family of products.

1. Review the existing high-installs everywhere (make take up to about one backup cycle/month).

2. Lower cased BEGINLIBPATH, with forced SYS2070 (mark XUL.DLL as high) or rare common one.

3. New MOZTURBO.EXE instead of an old one with SET LIBPATHSTRICT=... as object settings.

4. Optional: no MOZTURBO.EXE (nice-to-have as a respected member of the family, but Netscape FF/SM are users'default)

5. Mark the other DLLs "which sould be safe" as high too.

6. Try the commands "SLEEP.EXE 1 & SMTURBO.EXE -t", or something like that, to see what the effects of a delay are.

Please note that just the gain of -t is enough to justify having to set up a WLAN connect manually or having to reboot after a SYS2070 of *TURBO.EXE.

I'm expecting that the WLAN issue would be reproducable, with OS/2 or eCS software. A slower T23 (1.x GHZ Pentium III Mobile) never establishes an initial connection anymore, and so does a faster T42p Pentium 4. Especially with a T42 the eexpected result always is a succesfull WPA-connection, without any manual retry.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: mozturbo
« Reply #35 on: February 05, 2019, 05:59:21 am »
Hi André

If you have XWP installed a solution to startup timing problems is to use the xwp startup folder(s) and set time delay as required to avoid startup problems.


Regards

Pete



Remy

  • Hero Member
  • *****
  • Posts: 645
  • Karma: +9/-1
    • View Profile
Re: mozturbo
« Reply #36 on: February 05, 2019, 12:52:23 pm »
Or ArcaOS startup folder 
« Last Edit: February 06, 2019, 10:22:51 pm by Remy »

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: mozturbo
« Reply #37 on: February 05, 2019, 06:55:03 pm »
Hi

Or ArcaOS startup folder


If the ArcaOS startup folder is from the cutdown XWP - that should work. I do not recall there being any setting to delay app startup in the standard OS/2 startup folder.


Regards

Pete

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: mozturbo
« Reply #38 on: February 05, 2019, 08:51:07 pm »
Just use startup.cmd combined with sleep().
Code: [Select]
X:
cd \path\to\Firefox
detach ffturbo
sleep 3
cd \path\to\SeaMonkey
detach smturbo
sleep 3
cd \path\to\Thunderbird
detach tbturbo
Adjust paths etc as needed. Do have to wait a few seconds during startup.
Personally, I manually start WiFi after boot on my T42.

xynixme

  • Guest
Re: mozturbo
« Reply #39 on: February 09, 2019, 02:16:18 pm »
Status update: in general the all new high DLLs work everywhere (full *.DLL file names explicitly mentioned).

Since then I have experienced at least one fresh, unforced SYS2070 with SMTURBO.EXE, XUL.DLL and the same entry point.

The classic MOZTURBO (with BEGINLIBPATH) and SMTURBO.EXE (with BEGINLIBPATH) are in use.

So now I will modify (edit) the SET BEGINLIBPATH=U:\PPER\CASE to a lower case full path name. With backslashes, for all *TURBOs in my startup procedure.

I'm not going to modify the paths of all of SeaMonkey's WPProgram objects, because SMTURBO is the first entry in POPUPLOG.OS2 and manually starting SM itself will create a next entry. FWIW: there is no browser in any startup procedure.

If l:\ower\case doesn't help, then some new MOZTURBO.EXE or getting rid of the old MOZTURBO.EXE seems to be a next test.

xynixme

  • Guest
Re: mozturbo
« Reply #40 on: February 09, 2019, 02:38:31 pm »
If you have XWP installed a solution to startup timing problems is to use the xwp startup folder(s) and set time delay as required to avoid startup problems.
eWP is in use. An upgrade to the light or full version is an option. A translated version is available. Albeit I first have to test that because I don't want it to screw up the eCenter look, upto and including the eCS-button people may be used to. Unfortunately there is no scheduled new install, so I haven't had an opportunity to upgrade the eWP component.

I'm not sure if a theoretical delay of less than a few milliseconds per loaded large DLL will be enough, so using STARTUP.CMD xor the virtual <WP_START> "command line /c sleep 2 & detach E:\TCPIP\SEAMONKEY\SMTURBO.EXE -t".

FWIW: of course, if needed, I'm willing to test *TURBO.EXEs with an experimental lower priority setting (DosSetPriority API). In English the typical status of XWLAN with a T42, without any delay, remains "searching connection with the current connection profile". Silently.

I will not SLEEP until the rare SYS2070s seem to be (not) solved, in order to avoid mixing tests and mixed test results.

xynixme

  • Guest
Re: mozturbo
« Reply #41 on: February 09, 2019, 02:49:35 pm »
I do not recall there being any setting to delay app startup in the standard OS/2 startup folder.
No such clear setting with OS/2, eWP of eCS 1.2 and a registered DragText indeed.

I'm not using a German or English OS, so I don't know which OS introduced such a setting. eCS 2.x and/or ArcaOS. Nevertheless thank you for mentioning ArcaOS, since this is not my personal forum and you don't have to remember what I'm using. It looks like XWLAN almost gets it right, so any built-in sleep may help. Or, perhaps, a theoretical lower (TURBO.EXEs) or higher (XWLAN's connection phase) priority.

I've downloaded the SM1 MOZTURBO, but will first test the lower case full paths w.r.t. the rare SYS2070 errors (a guesstimated 5% of boots, or forceable by marking e.g. a high XUL.DLL as high).

xynixme

  • Guest
Re: mozturbo
« Reply #42 on: February 10, 2019, 01:46:57 pm »
Update: still a SYS2070 (3rd entry below) with l:\ower\case BEGINLIBPATH settings, so back to U:\PPER\CASE. The 4rd entry just is the moment you are using SM for the first time and notice the 3rd entry. FWIW: PLDS4.DLL is not a mentioned full file name, so it's not marked as high. XUL.DLL of SM is.

The next test will involved your attached new MOZTURBO. Without any SLEEP, to not mix tests, and the Pentium 4 desktop computer in question has no WiFi anyway.

Code: [Select]
02-09-2019  20:19:02  SYS2070  PID 0034  TID 0001  Slot 0096
D:\SEAMONKEY\SMTURBO.EXE
XUL->PLDS4.26
182
------------------------------------------------------------

02-09-2019  21:15:26  SYS3175  PID 005f  TID 0001  Slot 00aa
D:\PROGRAMS\MOZILLA\MOZILLA.EXE
c0000005
1f4cf6cc
P1=00000001  P2=6d660001  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=6d660000  EBX=022f013c  ECX=ffffffff  EDX=00000000
ESI=0012ed18  EDI=6d660001 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1f4cf6cc  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0012ecf8  SSACC=f0f3  SSLIM=ffffffff
EBP=0012ed28  FLG=00012246

LIBC066.DLL 0001:0000f6cc

------------------------------------------------------------

02-10-2019  11:24:50  SYS2070  PID 0036  TID 0001  Slot 0097
D:\SEAMONKEY\SMTURBO.EXE
XUL->PLDS4.26
182
------------------------------------------------------------

02-10-2019  13:26:31  SYS2070  PID 008b  TID 0001  Slot 009a
D:\SEAMONKEY\SEAMONKEY.EXE
XUL->PLDS4.26
182

xynixme

  • Guest
Re: mozturbo
« Reply #43 on: February 10, 2019, 03:58:00 pm »
Cosmetic copy-paste mozturbo.cpp error: #define MOZ_APP_DISPLAYNAME "seamonkey.exe"

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: mozturbo
« Reply #44 on: February 10, 2019, 09:09:18 pm »
Cosmetic copy-paste mozturbo.cpp error: #define MOZ_APP_DISPLAYNAME "seamonkey.exe"

This is trying to compile? Weird that it would error there. Which version of GCC and what compile switches?