Hey,
Amine informed me about yet another case of Vista APIs being used in wine code. This problem is going to increase and we need a solution, the sooner the better.
My plan to address this is to use lower layer DLLs that contain the actual implementations, while the upper layer DLLs (kernel32, advapi32, msvcrt*) are just forwarders to the lower layer DLLs. The lower layer DLLs can contain whatever we want and wine dlls can link to them, while applications continue to see version consistent exports of the standard winapi dlls.
For the exports of kernel32 and advapi32, a possible way to organize this is to follow MS API reorganisation on Win7, where these APIs are separated into the API-MS-Win-core-* etc dlls. In fact on Windows the implementation still stays in either Kernel32 or kernelbase and the API-MS-* dlls are just "virtual" dlls. How these APIs are organized can be seen here: http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html
While from a logical perspective it might make sense to organize our implementations physically into these API DLLs, it comes with an overhead, since a bunch of extra dlls would need to be loaded and initialized on every process creation. We can avoid that by organizing our code in static libraries and merge them all together to 2 core dlls. The division like on Windows 7: kernelbase + kernel32 + advapi32, doesn't work for us, since kernel32 and advapi32 would still need to contain Vista+ APIs. Therefore I suggest to divide it into kernelbase.dll and kernelsup.dll, the latter containing the code that remains in kernel32 and advapi32 on Windows.
Additional advantage: For the various CRT modules this can be done as well and would provide the benefit of having a single full featured CRT, which we can use from our own code, while still providing a (limited) version specific MSVCRT. And all other MSVCR* can forward to that core DLL, so we only need to load CRT code once. We would have another benefit, when we decide to implement Windows-Version specific API layers. These can be implemented as different versions of kernel32.dll etc. which export whatever they do on a specific Windows Version and contain version specific hacks, if required. These Version specific DLLs would be placed into subfolders on system32, having the loader use them, whenever a link/pif/registry setting asks for a specific (non-default) version.
If someone has doubts and fears this could cause compatibility issues: Yes it could, but those only apply to extremely special system tools, which wouldn't work on Windows 7 either. Since we simply cannot be 100% compatible (unless we copy the MS binaries and call them ours), we need to make a compromise at certain points. We really have other problems than some crazy XP/2003 only system tools not working. The benefits far outweight the problems. Otherwise MS would never have fiddled with their DLLs.
If someone prefers a different system of organization, I'd be happy to hear about it.
If there are no objections, I will create a branch and work on that together with Amine.
Thanks, Timo