[ros-dev] ReactOS official compatibility target and the new build system

[Jérôme Gardou]

Dear reactos developers.

Once again, bringing reactos build to cmake arises questions. When this 
"port" has begun, it was decided that import libraries would be shipped 
with build environment, the now famous RosBE.

This decision was made considering that :
     1) functions exported by dlls do not change often.
     2) Building an import library is a process that requires unneeded 
extra time.
     3) 1 makes 2 unworthy.
     4) If dll A imports function from dll B, it's not necessary to 
build B before A.
     5) Solving 4 solves the problem of cross-dependency.

As our target is win2k3 sp1 compatibility, a wise choice would be to 
choose import libraries that expose function only present on win2k3 sp1. 
The problem is that some wine dlls export functions that are from other 
windows versions, and, worse, use them.
Let's see why this is a problem.
     - function A is a vista function from dll foo
     - function B is an XP function from dll bar
     - for some reasons, B implementation calls A.
As you're clever developers ;-), you've seen that this would raise an 
error from the linker, as A is not present in our libfoo.a

Hopefully, those cases are not too widespread, but they exist.

Let's consider solutions that have arisen as of now :
     1) Implement A as an inline function in headers, so anyone 
requiring it has it.
     2) Linking bar.dll to some winefoo.dll, which forwards everything 
from foo.dll and exports the function A.
     3) Add a "#if WIN32_WINNT > 0x502" before the guilty part of code, 
and "#else" with a win2k3 compliant implementation.
     4) Oh dreams -> Ideally, convince wine to do it themself 
(./configure --wintarget=2k3sp1).
     5) Change our target to win7, so we're ahead of wine. :-p
     6) Do not change anything, and let our user mode libraries be a 
complete inconsistent anarchy.

As 4 and 5 won't happen in a short time, let's consider 1, 2, 3 and 6:
     1 is the best solution for easy winesyncs. We guard inline 
implementation by #ifndef BUILDING_FOO_DLL
     2 would put a whole mess in system32 directory, but should be the 
most easy thing to do.
     3 requires some extra work when syncing wine dlls. Though doing it 
often would reduce hassle.
     6 isn't what I'd wish.

What do you think? Your input is much appreciated.
Best regards.
The french speaking cmake team :-)