Making a system DLL unavailable (problem with COMMCTRL)
Hello, I have a Windows 3.1 application here that uses the OWL library. I have problems running it properly, and I have found the following: http://www.xploiter.com/programming/c/borland/3031.html Looking at what wine outputs when I use "WINEDEBUG=dll" or loaddll, I see that my program tries to load commctrl.dll and always succeeds. The problem is, I want it not to succeed, since AFAIK, 16 bit COMMCTRL functionality is not implemented in WINE, and the OWL library has a backup plan where it emulates some of the controls (like described on the site above) when it can't find COMMCTRL, which is what it does in Windows 2000 or XP for example. I have confirmed that the COMMCTRL is at the source of the problem by using one from a Windows 98 installation. Dialogs that are not showing using WINE's builtin COMMCTRL are now showing (although they are having sizing problems... anybody might know why?). Is there like a "disable" option in the [DllOverrides] section? Or some other way to disable a system DLL? I can't seem to just be able to "remove" commctrl.dll since even 32 bits builtin DLL (in this case comctl32.dll) require the 16 bit counterpart. In this case, when comdlg32 tries to load, it loads comctl32 and fails because it can't load commctrl. I don't think it's a good idea to make 32 bits DLL be dependent of their 16 bit counterpart. Thank for any input! -- Samuel Audet <guardia(a)step.polymtl.ca> http://www.step.polymtl.ca/~guardia/
Samuel Audet a écrit :
Hello,
I have a Windows 3.1 application here that uses the OWL library. I have problems running it properly, and I have found the following: http://www.xploiter.com/programming/c/borland/3031.html
Looking at what wine outputs when I use "WINEDEBUG=dll" or loaddll, I see that my program tries to load commctrl.dll and always succeeds. The problem is, I want it not to succeed, since AFAIK, 16 bit COMMCTRL functionality is not implemented in WINE, and the OWL library has a backup plan where it emulates some of the controls (like described on the site above) when it can't find COMMCTRL, which is what it does in Windows 2000 or XP for example.
I have confirmed that the COMMCTRL is at the source of the problem by using one from a Windows 98 installation. Dialogs that are not showing using WINE's builtin COMMCTRL are now showing (although they are having sizing problems... anybody might know why?).
Is there like a "disable" option in the [DllOverrides] section? Or some other way to disable a system DLL? I can't seem to just be able to "remove" commctrl.dll since even 32 bits builtin DLL (in this case comctl32.dll) require the 16 bit counterpart. In this case, when comdlg32 tries to load, it loads comctl32 and fails because it can't load commctrl. I don't think it's a good idea to make 32 bits DLL be dependent of their 16 bit counterpart. one of the things you could try (but that's risky) is to compile wine twice. First time with standard option, second time with disabling compilation of 16 bit part. Then use the commctrl DLL from the second compilation in the first compilation. But you need to do everything by hand. The best solution anyhow is to understand why Wine's commctrl in 16 bit fails and fix it.
A+
Hello, Eric Pouech wrote:
one of the things you could try (but that's risky) is to compile wine twice. First time with standard option, second time with disabling compilation of 16 bit part. Then use the commctrl DLL from the second compilation in the first compilation. But you need to do everything by hand. The best solution anyhow is to understand why Wine's commctrl in 16 bit fails and fix it.
Thanks for the tip! I have tried something else since then. I modified OWL50.DLL to look for COMMCTRL.DLL in say CRAPPY00.DLL, and that made the DLL unavailable all right, but it still didn't work correctly. I get the same "no dialog" dialog window that is either huge, or tiny, depending on other options, and with 100% CPU usage. My guess is, OWL50.DLL correctly detects that Wine's COMMCTRL.DLL is a stub and starts using its emulated controls, but fails to display them... Anybody has some debugging experience with Wine to give me hint as to where I should start looking why OWL50.DLL can't display its emulated controls on Wine? Thank you later!
Hi! Mike Hearn wrote:
Try "commctrl"="native"
Hum... I must have been tired the other day, because Wine actually never provides a built-in commctrl.dll, which is OK. Ok, so the only big problem seems to be that OWL50.DLL can't display its emulated controls. Yes, the native commctrl.dll from Windows 98 kind of works. The dialog window size is incorrect. Any hint as to where I should start looking in the code or the debugger? Thank you! bye
On Mon, 31 May 2004 08:21:17 -0400, Samuel Audet wrote:
Ok, so the only big problem seems to be that OWL50.DLL can't display its emulated controls. Yes, the native commctrl.dll from Windows 98 kind of works. The dialog window size is incorrect. Any hint as to where I should start looking in the code or the debugger?
That sort of problem is tricky, try a +dialog,+win trace to get you started. thanks -mike
participants (3)
-
Eric Pouech -
Mike Hearn -
Samuel Audet