Hello,
There are a number of dlls which are of common us, e.g. mss32.dll or binkw32.dll in the gaming industry.
These are usually distributed with the game. Nevertheless, they relay in other dlls of the system, e.g. zlib1.dll goes through msvcrt.dll to perform its activities.
Nevertheless, zlib1.dll is part of an open source project and it would not be difficult to adapt the code for fitting in wine as a library asking directly for the operating own system libraries, thus increasing performance.
Therefore, I propose to include in the source tree a directory for "commonly used dlls not included in Windows" It could include at least the open source usual dlls e.g. python24.dll hapdbg.dll zlib1.dll or even comon closed dlls (although this would be a harder work and we can work without an implementation for the time being.) such as mss32.dll binkw32.dll
Which would boost games such as Civ4 and furthermore it would make it more reliable as these open source libraries do not need to go through the wine implementations of the windows dlls in which they relay.
What do you think?
Am Sonntag, 29. Juli 2007 11:10 schrieb Luis C. Busquets Pérez:
Hello,
There are a number of dlls which are of common us, e.g. mss32.dll or binkw32.dll in the gaming industry.
These are usually distributed with the game. Nevertheless, they relay in other dlls of the system, e.g. zlib1.dll goes through msvcrt.dll to perform its activities.
Therefore, I propose to include in the source tree a directory for "commonly used dlls not included in Windows"
This does not sound bad, and indeed we've had a discussion about that concerning openal.dl, and we have decided that an openal thunk to Linux is a good thing. Someone started a stub which didn't make its way in because of implementation problems, but I think Chris Robinson is continueing the work on it.
But in general it raises some further concernes regarding the compatiblity of the libs. E.g. if zlib1.dll takes a pathname to a file, and the game passes "C:\myfunkyfile.zip", linux zlib will complain that it can't find the file. Simmilarly, Windows apps won't find "/tmp/myextactedfile/". Other issues may occur too, depending on what the libs do. E.g. if we make a qt thunk and the application tries to retrieve the Win32 HWND from a window created with qt, it will lead to problems if we just call Linux qt.
For the performance, it may help in some areas, but the linux lib is not necessarily faster. Wine does not emulate anything, Win32 code(and thus the dlls) run natively on the CPU. using zlib.dll isn't slower than zlib.so. Simmilarly msvcrt.dll isn't slower than libc.so. Implementation differences between the libs may occur, but Wine does not impose any performance impact. There are exceptions, like openal, which does not do the work on its own, but rather calls the sound hardware. A openal->dsound->alsa->hardware conversion on the fly is not as efficient as openal->alsa->hardware, or even openal->hardware.
It depends on the libs wether a direct thunk to the Linux lib is possible or not. Solid understanding of the library is needed to decide if a thunk is possible and makes sense.
-
"Luis C. Busquets Pérez" -
Stefan Dösinger