"Vizzini" vizzini@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