[ros-kernel] Headers, headers everywhere

[Vizzini]

[sorry, this e-mail got a little long on me...]

I don't want to divert the current wine forking thread into this so I'm
starting a new one.  Please reference bug 9
(http://reactos.com/bugzilla/show_bug.cgi?id=9) for more information.  

Also, I'm sure this topic has been discussed before, but recent
conversations with Steven lead me to believe that at the very least, the
members of this project are not yet of a single mind on this issue.

ReactOS currently supports four different sets of headers, to varying
degrees.

 1) w32api from the mingw folks
 2) wine headers from the wine team
 3) the Microsoft Platform SDK
 4) our own system of headers

This is sub-optimal.  :)  There are problems with each of these sets of
headers.  

The MinGW headers, as I understand, are difficult to keep updated.  I
hear they will only take patches if you can document the patch from MSDN
or a DDK or SDK.  As we rely on *lots* of undocumented stuff (being an
entire OS and not just an implementation of an API), this is a real bust
for us.  Also, those of us that work on the kernel side are constantly
updating various kernel-only headers, and while MinGW includes a ddk, it
will rapidly become stale between official releases.  I'm sure the same
thing is true on the user side, although perhaps somewhat less so.

Wine's headers aren't natively in a Microsoft-style format, and Wine has
broader goals than just an API implementation - they want to compile in
lots of different environments, and they are trying to provide a porting
environment in addition to an emulation environment.  This is good for
them, certainly, but we are a little different.  Also, the same
statements from above apply regarding keeping headers up-to-date and
patch acceptance.  Furthermore, wine doesn't have any kernel-related
headers (do they?) so we're missing a chunk from them.

The Microsoft Platform SDK should probably be our gold standard, since
it's the set of headers that actual user applications are built
against.  However, it is wholly unsuitable for us to actually use due to
its restrictive license.  Furthermore, not all of ReactOS is compatible
with the MS headers at this point.  This all also goes for the MS DDK.

So, due to these reasons and others, we have our own set of headers as
well.  These suffer from being Just Plain Wrong in a few circumstances,
and in any case are not nearly as tried and tested as any of the three
alternatives.

I don't have a coherent proposal for what to do about this yet, but I'm
pretty sure we need to make a decision.  If we are going to build a
ReactOS Development Kit, which headers are we going to ship in it? 
Which ones are we willing to stand behind when it comes to building our
releases?  How about when it comes to third-party development for
ReactOS?

We don't have to do an all-or-nothing here.  We can say, for example,
that we support w32api for all userland headers (or we can get even more
specific), but perhaps say that we provide our own DDK headers.  I just
want to be clear on what we decide, whatever it is.

Opinions?  I'd particularly like to hear from anyone who has debated
this in the past and reached a conclusion.

 -Vizzini