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