[ros-kernel] Proposed ReactOS headers and code sharing policy

[Eric Kohl]

"Vizzini" <vizzini at plasmic.com> wrote:

> 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
>
> Details
> -------
> 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 will
> submit patches to MinGW when we find problems with the public
> interfaces.  There is the added benefit of having a compatibility check
> against our public interface.

One important detail was missing from the discussion. Kernel-mode and native
code (ntdll, smss, etc.) does _not_ know about Win32 types, like BYTE, WORD,
DWORD, INT, UINT or the LP* types. Unfortunately, the use of these types
does not cause any trouble because of the braindead mix of SDK and DDK
headers. Actually, we need three different sets of headers: Kernel-mode
headers which include all definitions used in ntoskrnl and drivers,
native-mode headers which include only the Nt/Zw/Rtl functions used in ntdll
and other native components and finally Win32 headers which include the
remaining stuff.


> We will continue to maintain our own internal headers for anything that
> doesn't belong in the public headers.  We will begin to port our
> kernel-mode code to use the MinGW DDK headers, maintaining our internal
> headers for non-public things.

Component-internal headers should be moved into the component directory
(<component_path>/<header_name>.h) or into a component-specific include
directory (<component_path>/include/<header_name>.h). They should always be
added to a .c file by using '#include "..."'. Non-public headers which are
shared by components (the csrss-subsystem communication protocol for
example) should be treated as public headers, they become part of the SDK,
DDK or native headers but are not shared between projects.


> The first class of libraries is more difficult.  Some chunks of code
> will be used unmodified, ideally on a file-by-file basis.  Other chunks
> of code will have to be ReactOS-specific, and we will maintain those in
> our local tree.  If Wine ever chooses to merge our changes, that's fine
> too, but it certainly won't be required.

If code is ported from Wine to ReactOS, we have to make sure it will be
adjusted to the ReactOS/MS style. I do not like to see any
Wine-isms/Unix-isms in ntdll/ntoskrnl or a driver because this will become a
portability issue sooner or later.


Another issues are licenses and copyrights. IMO, public headers and import
libraries should not be licensed or copyrighted at all. They should be in
the public domain, so anybody can use them the way they want.

Wine code is published under the LGPL, which is important because of
Winelib. ReactOS on the other hand should use a clean mix of licenses: GFDL
for the documentation, public domain for public headers and import libraries
and GPL for the internal code. We should establish a GPL/LGPL dual-license
agreement so that shared code automatically changes its license when it is
moved from ReactOS to Wine or vice versa.


Regards,
Eric Kohl