[ros-kernel] Re: Proposed ReactOS headers and code sharing policy
dannysmith at clear.net.nz
Sun Oct 19 04:10:06 CEST 2003
----- Original Message -----
From: "Vizzini" <
> I think we have the Final Answer on what we're going to do about
> and code sharing. I want to get feedback from the ReactOS team and
> the MinGW and Wine projects before we do this, because I only want to
> it once. I will implement this policy (with any modifications made by
> this message thread) as soon as we are in general agreement.
> Executive Summary
> - Use MinGW for all public interface headers, i.e. everything that
> MinGW supports
> - Use non-OS-specific Wine libraries unmodified
> - Use portions of OS-specific Wine libraries (e.g. user32)
> - Keep it all straight with CVS vendor branches
> For headers, we will use MinGW as our external interface in all cases
> that MinGW supports, including kernel-mode code (i.e. the DDK). We
> submit patches to MinGW when we find problems with the public
> interfaces. There is the added benefit of having a compatibility
> against our public interface.
This sounds like excellent plan as far as Mingw is concerned. It can
I would suggest that you use the redhat winsup repository as the primary
CVS source for w32api headers at least. I've "been there, done that"
working with two separate repositories and it is a pain. Mingw will
continue to use redhat winsup CVS as it's official source repository. .
I look foward to discussion on details of handling inconsistencies
between w32api and DDK. In particular, should proposed changes that
affect both be submitted to Reacto and mingw patches list for review?
Or can we nominate someone from each group (yourself for Reactos?) to
be responsible for maintaining consistency?
My main plea is that undocumented stuff that is needed by ROS be keep
out of userland w32api interface.
> We will continue to maintain our own internal headers for anything
> doesn't belong in the public headers. We will begin to port our
> kernel-mode code to use the MinGW DDK headers, maintaining our
> headers for non-public things.
> There are two classes of DLLs we can borrow from Wine. The first
> includes system-specific DLLs like user32.dll, kernel32.dll,
> advapi32.dll, and ntdll.dll. The second class includes basically
> everything else.
> We will immediately start using the second class of libraries
> essentially unmodified. Any bugfixes we make will be sent back to
> as patches, but no ReactOS-specific code will ever be added to these
> The first class of libraries is more difficult. Some chunks of code
> will be used unmodified, ideally on a file-by-file basis. Other
> of code will have to be ReactOS-specific, and we will maintain those
> our local tree. If Wine ever chooses to merge our changes, that's
> too, but it certainly won't be required.
> I plan on managing both Wine and MinGW sources as CVS vendor branches.
> The ReactOS build system will have to be tweaked a little to look in
> right spots for things. We will stay current with MinGW and Wine
> changes through regular imports, probably on a major-release basis.
> makes this easy
> I would appreciate any feedback. This represents a major change for
> ReactOS project, but I believe it is the wisest thing to do. This
> system puts ReactOS in the position to grow and mature as cleanly as
> possible, and provides a high degree of code sharing and collaboration
> among our projects.
More information about the Ros-kernel