Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - André Heldoorn

Pages: [1] 2 3 ... 29
Applications / Re: mozturbo
« 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.

Applications / Re: PMChart - and other v 2.1 applets
« on: March 04, 2019, 02:18:06 pm »
I made a quick and dirty PMChart PNG icon.
In general, does the full file name of those PNG files matter when the user or the system has to assign it to a WPS object?

Compared with the *.ICO equivalent (e.g. HELLO.ICO being a default icon for a HELLO.EXE in the same directory), that is.

Applications / Re: PMChart - and other v 2.1 applets
« on: March 04, 2019, 02:13:53 pm »
Here the EXE produced a SYS3175 in POPUPLOG.OS2 quite quickly (eCS 1.2), with and without those (OS/2) directories, with an initial stack size of 0x6000 or with stack size 0x8000. With stack sizes 0x9000 or 0xFFFF it didn't start anymore.

Applications / Re: PMChart - and other v 2.1 applets
« on: March 04, 2019, 03:25:20 am »
You may not need the directories when you move the HELP-path (*.HLP) & LIBPATH (*.DLL) files to the directory of the EXE.

Nowadays PMCHART.EXE may need an increased stack size too (why doesn't "EXEHDR /STACK[DOS|OS2]:ffff[H] PMCHART.EXE" to patch the EXE work?).

Applications / Re: mozturbo
« 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...

Applications / Re: mozturbo
« 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.

Applications / Re: mozturbo
« 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:



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

Games / Re: ArcaOS - Retro Gaming Machine
« on: February 15, 2019, 02:57:20 am »
Can someone else test those and tell me if it a problem with my configuration/machine, or those games really do not work with the latest "" port.
Contact the author? It's not unlikely that he's willing to use latest SDL DLLs or to allow for upgrades.

Applications / Re: mozturbo
« 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. ;)

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

Applications / Re: mozturbo
« 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

02-09-2019  21:15:26  SYS3175  PID 005f  TID 0001  Slot 00aa
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

02-10-2019  13:26:31  SYS2070  PID 008b  TID 0001  Slot 009a

Games / Re: ArcaOS - Retro Gaming Machine
« on: February 09, 2019, 08:10:04 pm »
There are several SDL games that depends on an older SDL12.DLL to run.
Regarding old versions I recently considered a SDL DLL directory tree (due to disk full-errors) for each version of e.g. FSLIB.DLL, but then you'd still have to manage LIBPATHs, it's an own "standard", and the gain would be about 10 MiB.

i don't know why compiling of apps/games (and/or the DLLs) is excluded as an option. If the apps/games and DLLs are frozen, then I may give that directory tree for old SDL DLLs a try. But only to gain about 10 MiB.

I've got 16 FSLIB.DLL candidates, and 36 SDL*.DLL candidates. Excluding the NetLabs-ones. I cannot recall any significant SDL-related issue with older, frozen apps/games which would require a SDL update, but YMMV.

If you wouldn't have excluded recompiling, then you could have contacted the author(s). A recent DLL-related improvement is the browser Links/2, which no longer uses own DLL files like a JPEG.DLL and a Z.DLL, but without its author having to rewrite related (ported) code to join the NetLabs SDL programme.

Of course the SDL directory tree would be as simple as x:\SDL12.DLL\188402 bytes\SDL12.DLL and matching BEGINLIBPATH and LIBPATHSTRICT settings for the game Amoebax and for the emulator ZSNES. Both are using that SDL12.DLL file, and an identical FSLIB.DLL file. I don't know if you can use both apps/games at the same time then.

Applications / Re: mozturbo
« 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).

Applications / Re: mozturbo
« 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.

Applications / Re: mozturbo
« 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.

Pages: [1] 2 3 ... 29