Re: wine.info add fake dlls for msacm32.drv and midimap.dll
"Steven Edwards" <winehacker(a)gmail.com> wrote:
trace:winmm:DllMain 0x7e250000 0x1 (nil) trace:winmm:MMDRV_Init () trace:winmm:MMDRV_Install ('winealsa.drv', 'winealsa.drv', mapper=N); warn:winmm:MMDRV_Install Couldn't open driver 'winealsa.drv' trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); warn:winmm:MMDRV_Install Couldn't open driver 'wineoss.drv' trace:winmm:MMDRV_Install ('winecoreaudio.drv', 'winecoreaudio.drv', mapper=N); warn:winmm:MMDRV_Install Couldn't open driver 'winecoreaudio.drv' trace:winmm:MMDRV_Install ('wavemapper', 'msacm32.drv', mapper=Y); warn:winmm:MMDRV_Install Couldn't open driver 'msacm32.drv' trace:winmm:MMDRV_Install ('midimapper', 'midimap.dll', mapper=Y); warn:winmm:MMDRV_Install Couldn't open driver 'midimap.dll'
With this patch the firefox thinstall demo bug 10905 now works. I expect there may be other problems with other thinstall applications as he thinks there may be some changes that need to be done on their end to better accommodate Wine. I don't know if this really should be the case as it works on Windows and we should try to mimic that behavior.
DLLs are being added to wine.inf only if an app does check for a dll existence, which is not the case here. You need to investigate further what is going on. -- Dmitry.
Hi, On Sun, Apr 13, 2008 at 1:51 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
DLLs are being added to wine.inf only if an app does check for a dll existence, which is not the case here. You need to investigate further what is going on.
This is what Ge said -- I dug a bit deeper and understand what's going on now. Winmm (in driver.c) will try to load the low-level drivers using LoadLibrary. Thinstall intercepts that LoadLibrary call and tries to locate the driver, e.g. wineoss.drv, using the normal Windows search path for DLLs. We can't find the file because its not stored in the "normal" places like C:\Windows\System32 but in the build tree. So we fail the load and return error code 2 (ERROR_FILE_NOT_FOUND). Wine's LoadLibrary knows where to search in the build tree and would have no problem locating it. Unfortunately, we can't just pass the call on the Windows (or rather Wine) if we can't find a file. The reason we can't find a file might be that the application has deleted it. When a virtualized app deletes a file, we don't really delete the file but mark it internally as deleted. If we pass on a LoadLibrary call to Windows on a file that doesn't exist as far as the app is concerned, Windows would still happily load it (we only hide the file from the app, not from Windows). -- If I understand the issue correctly the problem is in Wine. The application works on Windows no problem. The Thinstall LoadLibrary hook can't be expected to know about builtin dlls if its searching the default directories or looking up KnownDLLs in the registry and they are not there, then failure is by design. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Sun, Apr 13, 2008 at 1:56 AM, Steven Edwards <winehacker(a)gmail.com> wrote:
If I understand the issue correctly the problem is in Wine. The application works on Windows no problem. The Thinstall LoadLibrary hook can't be expected to know about builtin dlls if its searching the default directories or looking up KnownDLLs in the registry and they are not there, then failure is by design.
This part was my thoughts on the subject. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
"Steven Edwards" <winehacker(a)gmail.com> writes:
If I understand the issue correctly the problem is in Wine. The application works on Windows no problem. The Thinstall LoadLibrary hook can't be expected to know about builtin dlls if its searching the default directories or looking up KnownDLLs in the registry and they are not there, then failure is by design.
This would require creating fake dlls for every single dll we support. That's a bit problematic considering that we need to load the dll to retrieve the proper info. It seems broken for Thinstall to try to second-guess the library search algorithm, especially now with activation contexts and the like. I'd argue that they should forward the call to LoadLibrary unless the file has been explicitly deleted. -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alexandre Julliard -
Dmitry Timoshkov -
Steven Edwards