31
Applications / Mismatch in DLL file name and internal module name massively confuses mod loader
« on: March 31, 2019, 11:09:45 am »
I always had the problem that closing and restarting the Volume applet repeatedly while a video (with sound) was playing in Firefox would eventually blow up the whole system with a subsequent reboot.
I have now found the reason: the CWMM classes (which the volume applet is part of) come with 2 resource DLLs: MMRES_EN.DLL and MMRES_DE.DLL ( in the \MMOS2\MMCLASS\BIN directory).
On my system which has set LANG to de_DE, the volume applet would attempt to load MMRES_DE.DLL, for all others that would be MMRES_EN.DLL.
Apparently, somebody decided to just copy the file MMRES_EN.DLL over to MMRES_DE.DLL as a shortcut to producing the german resources DLL.
However that leads to the following: the file is called MMRES_DE.DLL but the internal module name (set during link time) is MMRES_EN.
The volume applet attempts to load the resource DLL dynamically. It fails because the filename (stem) does not match the internal module name. But what's more: this mismatch between the filename and the internal module name will eventually massively confuse/screw up the module loader (if done repeatedly) until the whole system reboots without showing any trap screen or the like.
My solution was to LXLITE /X (unpack) the DLL, use a hex editor to modify the internal module name from MMRES_EN to MMRES_DE and do an LXLITE to pack it again. Now the proper resource DLL is loaded (even though it still contains english resources ...).
Now my system does not reboot anymore on running the volume applet.
If someone has an AN account I suggest to raise a problem report against this module loader oddity.
I have now found the reason: the CWMM classes (which the volume applet is part of) come with 2 resource DLLs: MMRES_EN.DLL and MMRES_DE.DLL ( in the \MMOS2\MMCLASS\BIN directory).
On my system which has set LANG to de_DE, the volume applet would attempt to load MMRES_DE.DLL, for all others that would be MMRES_EN.DLL.
Apparently, somebody decided to just copy the file MMRES_EN.DLL over to MMRES_DE.DLL as a shortcut to producing the german resources DLL.
However that leads to the following: the file is called MMRES_DE.DLL but the internal module name (set during link time) is MMRES_EN.
The volume applet attempts to load the resource DLL dynamically. It fails because the filename (stem) does not match the internal module name. But what's more: this mismatch between the filename and the internal module name will eventually massively confuse/screw up the module loader (if done repeatedly) until the whole system reboots without showing any trap screen or the like.
My solution was to LXLITE /X (unpack) the DLL, use a hex editor to modify the internal module name from MMRES_EN to MMRES_DE and do an LXLITE to pack it again. Now the proper resource DLL is loaded (even though it still contains english resources ...).
Now my system does not reboot anymore on running the volume applet.
If someone has an AN account I suggest to raise a problem report against this module loader oddity.