OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: mauro on February 15, 2021, 09:11:47 am

Title: [SOLVED] highmem.exe can't load xul.dll
Post 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
Title: Re: highmem.exe can't load xul.dll
Post by: Remy on February 15, 2021, 09:18:45 am
Did you run firefox previously ?
Try unlocking the dll first
unlock xul.dll
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 15, 2021, 12:53:05 pm
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
Title: Re: highmem.exe can't load xul.dll
Post by: Andreas Schnellbacher on February 15, 2021, 01:30:23 pm
yum install lxlite-tools
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 15, 2021, 01:46:56 pm
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.
Title: Re: highmem.exe can't load xul.dll
Post by: Dariusz Piatkowski on February 15, 2021, 03:21:51 pm
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:

Code: [Select]
[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
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 15, 2021, 05:22:28 pm
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)"
Title: Re: highmem.exe can't load xul.dll
Post by: Lars on February 15, 2021, 05:49:56 pm
check if XUL.DLL is marked as read-only. If it is, remove the readonly attribute.
Title: Re: highmem.exe can't load xul.dll
Post by: Andreas Schnellbacher on February 15, 2021, 07:07:50 pm
... and which OS/2 version and kernel you have installed.
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 16, 2021, 07:54:03 pm
... and which OS/2 version and kernel you have installed.

Warp 4.52
--
14.086W4 - this is the info bottom of the splash screen
Title: Re: highmem.exe can't load xul.dll
Post by: Dave Yeo on February 16, 2021, 08:38:21 pm
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.
Title: Re: highmem.exe can't load xul.dll
Post by: Dave Yeo on February 16, 2021, 08:52:18 pm
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.
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 17, 2021, 02:01:34 pm
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
Title: Re: highmem.exe can't load xul.dll
Post by: Dariusz Piatkowski on February 17, 2021, 02:28:56 pm
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:

Code: [Select]
[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):

Code: [Select]
[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.
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 17, 2021, 05:28:08 pm
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):

Code: [Select]
[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)
Title: Re: highmem.exe can't load xul.dll
Post by: mauro on February 17, 2021, 06:19:38 pm
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

Title: Re: [SOLVED] highmem.exe can't load xul.dll
Post by: Dave Yeo on February 17, 2021, 07:16:50 pm
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.
Title: Re: [SOLVED] highmem.exe can't load xul.dll
Post by: Roderick Klein on February 17, 2021, 08:46:59 pm
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
Title: Re: [SOLVED] highmem.exe can't load xul.dll
Post by: OS4User on February 17, 2021, 09:05:44 pm
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
Title: Re: [SOLVED] highmem.exe can't load xul.dll
Post by: Dave Yeo on February 17, 2021, 09:09:45 pm
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.