Author Topic: mozturbo  (Read 3152 times)

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 9
  • -Receive: 129
  • Posts: 1862
    • View Profile
Re: mozturbo
« Reply #45 on: February 10, 2019, 09:37:08 pm »
As for the sys2070's, I think this may just be an artifact of the way things work.
Smturbo preloads the DLLs in the applications directory and subdirectory, which then load their dependencies, one of which is NSPR's PLDS4, finds the mozilla.exe PLDS4.DLL in memory and uses that, possibly along with NSPR4.DLL and PLC4.DLL and loads them. These seem to be the only DLLs that have names in common between SM 1.19 (and presumably whatever version of Mozilla you're using) and SM2.49. Generally the NSPR4 stuff is very stable but obviously an extra export was added at some point and is missing from the older version. Bitwise also may have made changes that made the libs incompatible in subtle ways.
Ordering the loading so smturbo runs first and finds its proper version of NSPR etc first in LIBPATH is probably needed. Possibly it just won't work the way you're trying to use it as mozilla.exe may then try to use the newer NSPR with its modifications.
While it is possible to expand the turbo programs to take this in account, I really don't have the interest in supporting such setups.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 39
  • -Receive: 9
  • Posts: 432
    • View Profile
Re: mozturbo
« Reply #46 on: February 14, 2019, 02:49:17 am »
Ordering the loading so smturbo runs first and finds its proper version of NSPR etc first in LIBPATH is probably needed.
LIBPATHSTRICT=T and BEGINLIBPATH=B:\Rowser's\EXE\dir were always in use with the <WP_START> turbo objects too, FWIW. I'll check the PATHs and order in use w.r.t. those shared DLL file names. If it could be a possible cause, then I'll insert such a test because even better PATHs will be a theoretical improvement anyway.

So far no rare SYS2070s with the new "seamonkey.exe"-MOZTURBO.EXE, without any SLEEP or unreported changes.  I'm waiting for the first unforced SYS2070, with this MOZTURBO.EXE

Please note I'm just reporting what's happening, without expecting support for Mensys' SM 1.19. ;)

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 9
  • -Receive: 129
  • Posts: 1862
    • View Profile
Re: mozturbo
« Reply #47 on: February 14, 2019, 04:31:02 am »
I guess strictly speaking, I can offer what limited support my skills enable for SM 1.19 as I built it I believe. Didn't even realize that Memsys was distributing it :)
Whether my environment could rebuild it, I'm not sure.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 39
  • -Receive: 9
  • Posts: 432
    • View Profile
Re: mozturbo
« Reply #48 on: February 15, 2019, 03:30:31 am »
Didn't even realize that Memsys was distributing it :)
Sorry, I was probably mixing up versions & products... Too la^b^early...

Regarding the (three) *4.DLLs there shouldn't be a problem? MOZTURBO should use its own, which are located in its BEGINLIBPATH boot drive subdirectory, which isn't a LIBPATH directory (well, "." is).

With a clean boot drive policy FFTURBO xor SMTURBO should use a different copy of those *4.DLLs, which are located in a LIBPATH subdirectory.

Nevertheless I'll append that LIBPATH subdirectory to the BEGINLIBPATH too, just to make sure that it's there. Twice, and once in front.

Current <WP_START>-folder WPProgram settings (typed, errors possible), D:\INTERNET\BIN is the LIBPATH subdirectory where the modern *4.DLLs are saved:

MOZTURBO:
EXENAME=CMD.EXE
PARAMETERS=/c detach C:\PROGRAMS\MOZILLA\MOZTURBO.EXE -l
STARTUPDIR=C:\PROGRAMS\MOZILLA
SET LIBPATHSTRICT=T
SET BEGINLIBPATH=C:\PROGRAMS\MOZILLA

SMTURBO:
EXENAME=CMD.EXE
PARAMATERS=/c detach D:\SEAMONKEY\SMTURBO.EXE -t
STARTUPDIR=D:\SEAMONKEY
SET LIBPATHSTRICT=T
SET BEGINLIBPATH=D:\SEAMONKEY;D:\INTERNET\BIN

So far still no unforced SYS2070s with the "seamonkey.exe" MOZTURBO.EXE (which can be compiled with "ICC MOZTURBO.EXE" too, if I ignore the MAKE.CMD options of GGC; I may insert DosSleep() and DosSetPriority later).

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 9
  • -Receive: 129
  • Posts: 1862
    • View Profile
Re: mozturbo
« Reply #49 on: February 15, 2019, 04:56:54 am »
Not surprised that icc can also compile it as it is simple. Probably would have been happy without the casts I added. Seems GCC defaults to having a bunch of warnings.
You could easily recompile the seamonkey mozturbo for mozilla.exe by changing MOZ_APP_DISPLAYNAME and the other mozturbo programs should be as easy to recompile. Note I passed MOZ_APP_DISPLAYNAME on the command line. Source is at Bitbucket.
About the GCC options. -Zomf runs emxomf to convert the object file into native OS/2 obj format and uses ilink (default, wlink here) to link, also with the -g parameter, can use OS/2 debugger mostly. -Zhigh-mem causes the program to attempt to allocate memory in the high memory arena first, I had weird behaviour loading the DLLs that were marked to load high without that option, forget the specifics and it may have had a different cause.

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 39
  • -Receive: 9
  • Posts: 432
    • View Profile
Re: mozturbo
« Reply #50 on: February 15, 2019, 05:15:05 pm »
-Zhigh-mem causes the program to attempt to allocate memory in the high memory arena first, I had weird behaviour loading the DLLs that were marked to load high without that option, forget the specifics and it may have had a different cause.
1. I've seen a SYS2070 with another machine, so faulty hardware isn't a likely cause. Not that someone suggested that, but it could have been possible.

2. When I kill (C-A-D) a SM session due to a 100% CPU load (but not to PLUGIN-CONTAINER.EXE being started), then it seems like a shutdown doesn't complete anymore. CAD has to pressed to complete a regular shutdown.

3. I'm still waiting for at least one new SYS2070 to complete the current test. If a possible later code change really works for me, then I'll consider sharing the change before introducing 2 versions of a same package. I'm at least thinking about DosSetPriority tests for XWLAN (or DosSleep), assuming that such a process is slightly more time-critical than loading the DLLs. Hopefully the user won't notice a speed difference. Nothing fancy, I'm not a programmer and even a PM test version would be mainly copy & paste "programming".

No warnings with "ICC mozturbo.exe", but I didn't use that EXE. I cannot recall any IBM option related to high-memory, so hence just ICC without compiler or linker options.

I've changed the case of the paths earlier, but then a SYS2070 still occured. So it wasn't an exclusive solution. I'll lower-case it again after a new SYS2070, to avoid mixing tests now (your new NEWTURBO.EXE and longer BEGINLIBPATH for FF/SM).

0. Needless to say that the gains are outnumbering the e.g. rare SYS2070 by far. (Re-)starting the browser no longer has a project-status, for one.
« Last Edit: February 15, 2019, 05:17:32 pm by André Heldoorn »

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 39
  • -Receive: 9
  • Posts: 432
    • View Profile
Re: mozturbo
« Reply #51 on: March 04, 2019, 03:06:41 am »
So far no SYS2070, since Dave's new MOZTURBO.EXE... I'll continue to wait for a while, but it looks very good...

André Heldoorn

  • Sr. Member
  • ****
  • Thank You
  • -Given: 39
  • -Receive: 9
  • Posts: 432
    • View Profile
Re: mozturbo
« Reply #52 on: March 14, 2019, 10:00:32 pm »
Still no SYS2070s, so I'm willing to rate that as being solved by Dave's new MOZTURBO.EXE. Soon I'll try a few modifications, like DosSetPriority or DosSleep to try to avoid the issue of significantly less initial Wi-Fi connections by XWLAN, and perhaps an unwanted test move to PM to make regular shutdowns work more often.