OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: mauro on February 15, 2021, 09:11:47 am
-
Hi all, in order to solve my old issue that prevents running Firefox and another application meantime like Staroffice (maybe also happens with other ones), understanding that is a high memory handling issue mainly belonging to Firefox, I read that loading xul.dll in high memory by highmem.exe with the following OS2 command should be the the solution :
highmem.exe -c xul.dll
but the answer is
Error: "xul.dll" cannot be opened, rc=110.
Do you already have the knowledge on how to solve it?
Thank you
-
Did you run firefox previously ?
Try unlocking the dll first
unlock xul.dll
-
Hi Remy, thanks for replying.
SYS1041: The name unlock is not recognized as an
internal or external command, operable program or batch file.
however, Firefox has not been executed before attempting to load xul.dll in high memory, this command is given first of all as the system boots
-
yum install lxlite-tools
-
yum install lxlite-tools
thank you Andreas, now I've gone a little bit ahead, still with an oppositive (but different rc code) warning result:
[C:\USR\LIB\FIREFOX-45.9.0]unlock xul.dll
┌[ unLock ]──────────────────────────────[ Version 1.3.9 ]┐
├ Copyright 1996 by FRIENDS software ─ No rights reserved ┘
└┤Done
[C:\USR\LIB\FIREFOX-45.9.0]highmem.exe -c xul.dll
Error: "xul.dll" cannot be opened, rc=5.
-
Hi mauro,
What happens when you re-boot and try this before you even start FF?
In parallel to that, what's the result of the following command: 'highmem -vv xul.dll'
Here is what I get, xul.dll is flagged to load-high CODE only:
[G:\apps\tcpip\firefox]highmem -vv xul.dll
Processing module : xul.dll
object 0 : base 0x00010000, size 0x03740840, flags 0x00012005, executable, himem
readable, !writeable, executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming, 32bit, !IOPL
object 1 : base 0x03760000, size 0x0009b400, flags 0x00002003, data, !himem
readable, writeable, !executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming, 32bit, !IOPL
object 2 : base 0x00000000, size 0x00002324, flags 0x00002039, data, !himem
readable, !writeable, !executable, resource, discardable, shared,
!preload, !invalid, swappable, !16:16 alias, !conforming, 32bit, !IOPL
-
Hi Dariusz:
[C:\USR\LIB\FIREFOX-45.9.0]highmem -vv xul.dll
Processing module : xul.dll
object 0 : base 0x00010000, size 0x0291b780, flags 0x00002005, executable, !him
em
readable, !writeable, executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
object 1 : base 0x02930000, size 0x00079cb0, flags 0x00002003, data, !himem
readable, writeable, !executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
object 2 : base 0x00000000, size 0x00002324, flags 0x00002039, data, !himem
readable, !writeable, !executable, resource, discardable, shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
but no change about the described situation.
Then also given the command highmem.exe -c xul.dll with same negative answer.
All this tried before running FF first time. Tried with FF already running, in this case "unlock xul.dll" result is positive:" xul.dll UNLOCKED", but with no success for the purpose to have Firefox and Staroffice running meantime.
If Firefox is running, then Staroffice Writer just won't load, if Staroffice Writer is running then Firefox won't load, with this message instead : "Couldn't load xul.dll (OS2 error 8 faulty module : C:\USR\LIB\FIREFOX-45.9.0\XUL.DLL)"
-
check if XUL.DLL is marked as read-only. If it is, remove the readonly attribute.
-
... and which OS/2 version and kernel you have installed.
-
... and which OS/2 version and kernel you have installed.
Warp 4.52
--
14.086W4 - this is the info bottom of the splash screen
-
Well, you should update your kernel. If you don't have access to eCS or ArcaOS, the latest free one is 104a, available at http://www.os2site.com/sw/upgrades/kernel/ (http://www.os2site.com/sw/upgrades/kernel/). You'd need w420050811.zip to replace your W4 kernel.
-
There's also an updated DOSCALL1 at http://www.os2site.com/sw/upgrades/kernel/dc20050811.zip (http://www.os2site.com/sw/upgrades/kernel/dc20050811.zip), make sure that you use the w4 version.
-
check if XUL.DLL is marked as read-only. If it is, remove the readonly attribute.
I have applied the command
[C:\USR\LIB\FIREFOX-45.9.0]attrib -r -s -h xul.dll
then:
[C:\USR\LIB\FIREFOX-45.9.0]highmem.exe -c xul.dll
Processing module : xul.dll
[C:\USR\LIB\FIREFOX-45.9.0]
it should mean that xul.dll has been successfully loaded in high memory , does it?
But still no improve in the memory handling between Firefox and Staroffice.
Later on I'll apply the kernel patch and doscall1.dll replace suggested by Dave
-
Hi mauro,
I have applied the command
[C:\USR\LIB\FIREFOX-45.9.0]attrib -r -s -h xul.dll
then:
[C:\USR\LIB\FIREFOX-45.9.0]highmem.exe -c xul.dll
Processing module : xul.dll
[C:\USR\LIB\FIREFOX-45.9.0]
it should mean that xul.dll has been successfully loaded in high memory , does it?...
Correct, that should do it and here is how to confirm.
Initially when you checked this your output was as follows:
[C:\USR\LIB\FIREFOX-45.9.0]highmem -vv xul.dll
Processing module : xul.dll
object 0 : base 0x00010000, size 0x0291b780, flags 0x00002005, executable, !himem
readable, !writeable, executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
object 1 : base 0x02930000, size 0x00079cb0, flags 0x00002003, data, !himem
readable, writeable, !executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
object 2 : base 0x00000000, size 0x00002324, flags 0x00002039, data, !himem
readable, !writeable, !executable, resource, discardable, shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
when you run the same command now you should see the following (I will show just the stuff relevant to having marked the CODE to load-high (which is the '-c' parameter in highmem.exe):
[C:\USR\LIB\FIREFOX-45.9.0]highmem -vv xul.dll
Processing module : xul.dll
object 0 : base 0x00010000, size 0x0291b780, flags 0x00002005, executable, m
em
readable, !writeable, executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
The 'object 0:' stuff is CODE, and the 'himem' vs '!himem' you saw previously indicates that the CODE is marked to load high.
-
Hi mauro,
when you run the same command now you should see the following (I will show just the stuff relevant to having marked the CODE to load-high (which is the '-c' parameter in highmem.exe):
[C:\USR\LIB\FIREFOX-45.9.0]highmem -vv xul.dll
Processing module : xul.dll
object 0 : base 0x00010000, size 0x0291b780, flags 0x00002005, executable, m
em
readable, !writeable, executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
The 'object 0:' stuff is CODE, and the 'himem' vs '!himem' you saw previously indicates that the CODE is marked to load high.
yes, here it is:
[C:\USR\LIB\FIREFOX-45.9.0]highmem -vv xul.dll
Processing module : xul.dll
object 0 : base 0x00010000, size 0x0291b780, flags 0x00012005, executable, himem
readable, !writeable, executable, !resource, !discardable, !shared,
!preload, !invalid, swappable, !16:16 alias, !conforming,
32bit, !IOPL
seems responding to your description (himem replaces !himem)
-
Well, you should update your kernel. If you don't have access to eCS or ArcaOS, the latest free one is 104a, available at http://www.os2site.com/sw/upgrades/kernel/ (http://www.os2site.com/sw/upgrades/kernel/). You'd need w420050811.zip to replace your W4 kernel.
There's also an updated DOSCALL1 at http://www.os2site.com/sw/upgrades/kernel/dc20050811.zip, make sure that you use the w4 version.
downloaded and applied these ones as well, kernel update first and DOSCALL1.DLL substitution after.
while the kernel update went ok, with the current version 14.104a_W4 reported on the boot splash screen, the DOSCALL1.DLL replacement caused a trap at boot. Message screen here attached.
Could not even use FC2 loading in safe mode, it traps again.
Anyway I could reload the previous working machine state (it is a Virtualbox emulation) made just before this change.
The important to say is that after having applied again the kernel update, worked on the xul.dll attributes and loaded it in the high memory, now the issue is solved! :D
Firefox, Staroffice, ANPM and Java ImageEditor running at same time
Thank you all
-
Not surprised you needed the newer kernel, only a bit surprised about the trap. The kernel internally is DOSCALL0.DLL and is closely matched to DOSCALL1.
Be aware that there are still bugs in that kernel with high memory. The worst is that high memory isn't correctly released when closing the browser, so if you open and close FF repeatedly, things get funky.
You can install one of the mozturbo programs to keep the DLLs loaded or reboot regularly.
-
Not surprised you needed the newer kernel, only a bit surprised about the trap. The kernel internally is DOSCALL0.DLL and is closely matched to DOSCALL1.
Be aware that there are still bugs in that kernel with high memory. The worst is that high memory isn't correctly released when closing the browser, so if you open and close FF repeatedly, things get funky.
You can install one of the mozturbo programs to keep the DLLs loaded or reboot regularly.
I do not know about OS/4 but all other kernels do not have this update the 14.202 kernel has.
I am not aware of more bugs with the high loading of DLL's and unloading. If issue's report how to reproduce or we need a memory dump.
Roderick
-
I do not know about OS/4 but all other kernels do not have this update...
https://www.os2world.com/forum/index.php/topic,1953.msg19785.html#msg19785
-
My imperfect memory is that there were other issues with some kernels. Consider that mauro couldn't even correctly mark the DLL with the default kernel he was using.