Re: wine.info add fake dlls for msacm32.drv and midimap.dll

[Dmitry Timoshkov]

"Steven Edwards"  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.

wine.info add fake dlls for msacm32.drv and midimap.dll

[Steven Edwards]

Hi,

On Sun, Apr 13, 2008 at 1:51 AM, Dmitry Timoshkov
 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.

wine.info add fake dlls for msacm32.drv and midimap.dll

[Steven Edwards]

On Sun, Apr 13, 2008 at 1:56 AM, Steven Edwards  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.

wine.info add fake dlls for msacm32.drv and midimap.dll

[Alexandre Julliard]

"Steven Edwards"  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.