Yet another case of required Viista APIs... - Ros-dev

17 Mar 2013

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