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 ... 28
Web applications / Re: Firefox high mem
« on: Today at 06:39:12 pm »
marking data as high is usually discouraged as it can cause problems, your mileage may vary.
Which dictionary DLL?
Thanks, I'll restrict it to code and - so far - to this single DLL only. AFAIK I have no need to start experimenting with varying mileages.

The manually installed HUNSPEL0.DLL, which AFAICT just has to be loadable and isn't used by any other app. And if another app is using it, then such an app never complained about missing "spell checker's data files".

Web applications / Re: Firefox high mem
« on: January 20, 2019, 03:26:11 am »
I assume ABOVE512.EXE can be used too, to mark that single and unused FF/SM dictionary DLL (code & data) as high?

Games / Re: Tetris-like game
« on: January 20, 2019, 03:23:03 am »
They seem to be losing the race
Of course they are losing the racing, because the reduced number of available OS languages already has reduced the number of users significantly. Small communities tend to "move on", while leaving most of the community behind. Sometimes with weird excuses, like the frequently used "most of us are using xWorkplace" or targetted non-OS/2 CPUs while claiming to write OS/2 software.

No need to explain why eCS 2.x DE may account for Silvian and eCS 2.x EN for Dave (and a few countries where well over 95% of the people calim to speak English), but there is that language-related link.

A neutral case may still be Object Rexx. We could still be the largest installed base, but were left behind because the happy few wanted to "move on" (and accepted a matching offer).

It's just a conclusion. Translating ArcaOS 7 to e.g. Finnish, Italian and Japanese won't restore the size of the community, and may stretch available resources beyond limits. I could have left the community too, if I wouldn't have bought more than enough old machines about 10-15 years ago. Albeit leaving isn't really an option, due to the software in use and as long as browsing is reasonably possible.

There may be a few strategic errors too, like trying to support more hardware than required. It was hard to keep up with *.*, and it will become even harder to try to keep up with *.*. We may reach the end before 64 bits would kill us.

Back on-topic: the development of games can be used to learning something step-by-step, but I'm not sure how classic 32-bit Windows games will efficiently contribute to climbing a steep 16-bit Win-OS/2 and 64-bit OS/2 learning curve.

Utilities / Re: best process killer application
« on: January 20, 2019, 02:34:08 am »
If you are using eCS, or ArcaOS, CADH (Ctrl-Alt-Del Handler) is installed by default. TOP is also included in the CADH menu.
FWIW: the silently added component TOP is only included with some versions of eCS. Probably the v2.x DE/EN ones.

Its author has released at least one CADH-related update in 2018, i.e. since the last version of eCS: "Added ability to use CADH.SYS for force kill option.". Dunno if some CADH WPI package was updated too.

Applications / Re: WinZip
« on: January 20, 2019, 01:50:24 am »
FWIW the install program (setup.exe) stopped with an error saying the timestamp of the README.TXT file did not match the timestamp of SETUP. I fixed that by running TOUCH *.*  on the install files and restarting SETUP.EXE.
No timestamp errors with a WINZIP6316.EXE, but that file has to be renamed to a FAT 8.3-compliant WINZIP63.EXE first.

Applications / Re: WinZip
« on: January 20, 2019, 01:33:27 am »
Thanks. My older v6.0 had just 3 buttons (OK, and the Help-screens of a License Agreement and Ordering Information).

Applications / WinZip
« on: January 17, 2019, 03:10:42 pm »
Does someone recall how to use a WinZip 6.0 registration code with Win-OS/2?

The screenshot @ has no Registration-button. FWIW: I'm not using theirs.

Utilities / Re: best process killer application
« on: January 17, 2019, 03:04:51 pm »
I saw the zip consisting in some executable files, how should they be installed-used ? Sometimes it is a matter of copying the files in the respective folders
TOP is one of the secret, silent OS upgrades, and there is an informal upgrade package for eCS 1.x at Hobbes. Installing TOP is simple, FWIW. Thh upgrade package just uses the same directory structures, so we are all talking about the same TOP.

Applications / Re: mozturbo
« on: January 05, 2019, 11:59:06 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.
Regarding HUNSPEL0.DLL (8.3 DLL file name): I've just installed this DLL and no other files. So mine doesn't load and expand any dictionary files or other files, if that's what HUNSPEL0.DLL would be doing with your RAM. As such FF/SM only requires HUNSPEL0.DLL of that package, which doesn't appear to be a large file.

Nevertheless I'll mark HUNSPEL0.DLL as high, since it seems to be safe and I'm pretty sure no other app uses it. It just has to be there, as some useless technical requirement.

Applications / Re: mozturbo
« on: January 05, 2019, 11:34:06 am »
using the FCF_TASKLIST flag means a full PM app, I believe it applies to the frame, something that would be overkill
A hidden frame, FWIW. So basicly the same effects as Rich's DETACH, regardless of the abuse of democracy by claiming "most of us are using ...": not visible, no shutdown dialogs, no requirements of requirements to avoid useless dialogs. ;-)

Which slower hardware and DETACH it'll appear in whatever task list a few people are using for a few zilliseconds, but that's it. It may be possible to hide selected apps, but that's not required with solutions like (not) FCF_TASKLIST or DETACH. DETACH is better, since there is no meaningful PM UI.

I've never tried to replace/upgrade eCenter bij xCenter, so apparently I'm not using what "most of us are using" indeed. That rather popular assumption is right. :-)

Applications / Re: mozturbo
« on: January 05, 2019, 11:17:42 am »
The main user, that I know about, is VBOX 5.0.6, which uses about 100 meg of lower shared memory.
FWIW: Object Rexx' file-I/O, otherwise a better Rexx interpreter, is a good way to run out of shared memory too. Until a WPS reset. I've never checked if ORexx would beat ~100 MiB, though.

Applications / Re: mozturbo
« on: January 05, 2019, 10:28:51 am »
SMTURBO.EXE -T wasn't running anymore after several failing attempts to start SEAMONKEY.EXE, each resulting in a SYS2070. I was able to start SEAMONKEY.EXE after killing MOZTURBO.EXE -L as well, but that may be unrelated. SEAMONKEY.EXE was the first started, related product after a cold boot (loading was finished, I was editing a file before opening the browser).

01-05-2019  10:16:05  SYS2070  PID 0039  TID 0001  Slot 009a


Applications / Re: mozturbo
« on: December 27, 2018, 01:04:33 pm »
I'll stick to the default settings w.r.t. high or low memory.

BTW, with mozturbo running and doing various tests which involved unloading and reloading, I managed 8 days of uptime, usually the system traps or locks up after 2-3 days. Been years since I've had much more then 3 days uptime.

Probably no surprise, but according to Theseus it seems okay to use it with systems with <= 512 MiB of RAM too. One tends to not use e.g. SM that often then, but one also tends to not use other hungry apps. Which allows me to use the *TURBOs everywhere.

PMTPOSD2 would be hardly more than a skeleton app with too many bones, but it has a matching stealth mode (no tasklist, no extra shutdown dialog). I'll try DETACH instead, if that fully hides it as well.

Thanks for the smart solutions!

Applications / Re: mozturbo
« on: December 27, 2018, 12:49:26 pm »
Please don't! Currently it can be launched as a background daemon (e.g. "detach ffturbo") which uses almost no memory on its own. I can't see how making it a PM app adds anything useful.

Creating a couple of program objects to launch and terminate it makes more sense to me:
No protests obviously, as long as results are the same: an user doesn't see it in any default tasklist and can shutdown the system without an extra dialog. Without PM all *TURBO.EXEs will work the same way too, AFAICT. Including the original one.

Applications / Re: mozturbo
« on: December 21, 2018, 05:10:42 pm »
Is it recommended to use high memory in general, because all qualifying FF/TB or SM DLLs will always be loaded, even when you're not going to use FF/SM/TB while working with some large database?

Can it be compiled as a PM app, without the FCF_TASKLIST flag? You may be able to use Van Wijk's PMTPOSD2 (stealth mode) as sample code.

Pages: [1] 2 3 ... 28