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.
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.
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
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.
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.