Author Topic: Mismatch in DLL file name and internal module name massively confuses mod loader  (Read 5760 times)

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
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.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Which version of OS/2? Here on ArcaOS, I have,
mmres_en.dll ā”‚   32376ā”‚19/04/17ā”‚ 9:11pā•‘

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
I updated both Resource DLLs (the english as well as the german one) but yes that's the version I am talking about:

[d:\mmos2\mmclass\bin]bldlevel mmres_en.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#(c) Chris Wohlgemuth :0.2 (13.03.02) (mmres_en.DLL)#@##1## 13
.03.2002 18:17:00      My ;-)  ::::1::@@Resource-DLL
Vendor:          (c) Chris Wohlgemuth
Revision:        0.02
Date/Time:       13.03.2002 18:17:00
Build Machine:   My ;-)
File Version:    0.2.1
Description:     Resource-DLL

But the problem is the GERMAN Resource: DLL mmres_de.dll.
And the real universal problem is that the OS module loader will barf on the mismatch between file name and internal module name. This is true for ANY DLL loaded. I could easily create a test case that would blow your whole system just by creating (and loading a DLL) that has a mismatch in filename and internal module name.
« Last Edit: March 31, 2019, 09:32:43 pm by Lars »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Doesn't seem to be a mmres_de.dll in the ArcaOS repository, just mmres_en.dll. Where did you get it?

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
MMRES_DE.DLL  installed with eCS 2.2 beta. Back at the time, I chose the installation in german.
Maybe you need to look into the CWMM install package to find it (but I don't know where you find that on the DVD, eCS or ArcaOS).
If you want to experience the "sudden system reboot", what you can do is to back up mmres_en.dll, lxlite /x the DLL, use a hex editor to change the internal module name from MMRES_EN to say MMRES_DE and save back.
For once that will prevent the DLL from loading. But if you try often enough (by invoking volume.exe multiple times, say 10 times) it will eventually take down your whole system.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
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.

Quote
I could easily create a test case that would blow your whole system just by creating (and loading a DLL) that has a mismatch in filename and internal module name.

What if  you prepare some test so I can run it om my computer and have this reboot?
« Last Edit: April 01, 2019, 09:30:40 pm by OS4User »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
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.

Quote
I could easily create a test case that would blow your whole system just by creating (and loading a DLL) that has a mismatch in filename and internal module name.

What if  you prepare some test so I can run it om my computer and have this reboot?

Ok, just give me some time. Where can I send that ?

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Ok, after having had a private exchange I take it for granted that this problem is fixed in the OS/4 kernel but not in the IBM or AN kernels.