OS/2, eCS & ArcaOS - Technical > Mail-News
Security fixes for Mozilla
Dariusz Piatkowski:
--- Quote from: André Heldoorn on July 21, 2019, 07:12:32 pm ---Always manually unload any turbo's (if loaded), close FF/SM/TB, unlock the specific DLL now (just to be sure), and ATTRIB -R the specific DLL (if read-only)...
--- End quote ---
...aha!!! I forgot about the read-only flag...indeed sir, there it is.
--- Quote from: André Heldoorn on July 21, 2019, 07:12:32 pm ---...Execute the matching ATTRIB +R later, if that's the issue. Probably, according to the OS/2 command HELP [rc_number_of_HIGMMEM], i.e. "HELP 5".
--- End quote ---
What is neat about this, and I had absolutely no idea after all these years, is that the program RC actualy translates to a system SYSxxx value. Of course that would rely on the code logic to actually pass this to the output w/o it being changes, but I never actually thought to check that, thank you for pointing it out!
André, one last thing though, what DLLs for FF are flagged as high-mem load eligible? No, I do not like a pre-made script doing this type of stuff for me, I do it by hand and that has always worked reliably here. This is mostly due to hold old my install is and how many numerous upgrades it has gone through, etc. etc. etc...
Dariusz Piatkowski:
Hey Dave!
--- Quote from: Dave Yeo on July 21, 2019, 08:02:00 pm ---The build process leaves some of the DLLs readonly and a readonly DLL can't be marked.
As I said, the binaries, both Firefox.exe and ffturbo.exe take care of setting BEGINLIBPATH and LIBPATHSTRICT so no worries about DLL conflicts.
I regularly run SM, TB and FF without any scripts or RUN!
--- End quote ---
Indeed, that was the issue. I am correcting this right now. I know you said this already, but thanks for pointing this out again, never hurts for this type of stuff to be re-iterated!
xynixme:
--- Quote from: Dariusz Piatkowski on July 21, 2019, 09:03:14 pm ---that the program RC actualy translates to a system SYSxxx value. Of course that would rely on the code logic to actually pass this to the output w/o it being changes, but I never actually thought to check that, thank you for pointing it out!
--- End quote ---
Exactly. I'll use the OS API DosOpen() to open the file (to write to it), and prints (not returns) the RC of the OS API when it's not 0. One day programmers may even decide to print SYS0005 instead of rc=5...
My source were several articles by Dave. Check the source code of InsTurbo.CMD to find DLLs compiled/supported by him. A (probably incomplete) list of other DLLs, not compiled/supported by Dave, can be found in OTHERDLLS.ZIP @ Hobbes. An example of such a DLL is HUNSPEL0.DLL. A recent RPM upgrade could overwrite such a marked DLL.
So check the source code of both InsTurbo (MozTurbo package) and OTHERDLLS.ZIP @ Hobbes. It's Rexx/text, so lists of DLLs should be easy to find. OTHERDLLS.ZIP works like InsTurbo.CMD. Or just use those tools.
xynixme:
--- Quote from: Dariusz Piatkowski on July 21, 2019, 09:03:14 pm ---I do it by hand and that has always worked reliably here. This is mostly due to hold old my install is and how many numerous upgrades it has gone through, etc. etc. etc...
--- End quote ---
The scripts will find the same DLLs as FF/SM/TB, and the same etcetera's apply to me. I'm not using RPM myself, for example. You'll be fine, and additionally you can even control the order of LIBPATH directories by using BEGINLIBPATH.
InsTurbo was requested and distributed by Dave, so you should be fine. It ain't a third-party "works for me" project. So far no known complaints, albeit the latest code supports (rare) long directory names better.
Dave Yeo:
Personally, while some of the DLLs in /usr/lib can be marked high, so far I've left them alone. They do take up some low memory. but it does get properly released though over the long term there may be fragmentation. If you do mark any high, have to consider that some other programs might not like it. I tried marking Cairo high at one point and the screensaver seemed to get unstable when using the Cairo modules. Might have been a coincidence.
Eventually we'll have to consider the QT libs and some mark the Java libs to load high. There's the same problem then of the kernel not properly releasing memory. Mozturbo could easily be adapted for others and if I was more skillful, I'd write a general purpose utility that reads a list and keeps them loaded.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version