a proposal that will affect MingW-Runtime, w32api, ReactOS and WINE

[Jonathan Wilson]

Currently, we have 3 different projects that are working towards windows 
"compatibility".
We have ReactOS
We have WINE
and We have MingW-Runtime and w32Api (refered to as just MingW from now on)

The 3 projects have different goals but the same target. Microsoft Windows 
and the Microsoft SDK, DDK and compiler. All 3 projects are working in some 
way to be compatible with those.

All 3 projects have their own set of header & library files including 
windows SDK headers like windows.h, MSVCRT headers like stdlib.h or stdio.h 
and (to some extent) ddk headers like ntddk.h

The first part of what I am proposing is that the 3 sets of headers be 
"merged" to create a new "SDK/DDK" for building windows apps.
This SDK would contain:
1.a new set of windows headers and libraries (windows.h and friends) built 
up from a combination of ReactOS headers, WINE headers and w32api headers. 
They would be (with the help of MSDN) designed to be as close to the 
microsoft headers as possible (in so far as where things are declared e.g. 
if abc is in def.h on MS SDK, put it in def.h in this new SDK).
This set of headers and libraries would be used:
A.by MingW users for windows programming and development
B.by the reactos team to build ReactOS
C.by the WINE team to build WINE
and D.by people building apps with WINELIB.

2.same as 1 but for MSVCRT.dll/MSVCRT.lib and would be used by WINE, MingW 
and ReactOS. It would endevour to provide 100% coverage of what the MS 
runtime provides in its MSVCRT.dll as well as all the glue code in 
MSVCRT.lib (like the Thread Local Storage stuff I made)
It would be used by MingW developers to write for win32, by ReactOS to 
build their OS and their clone of msvcrt.dll and by WINE to build WINE and 
its clone of msvcrt.dll (which would be the same one as the ReactOS clone, 
see below)

3.same as 1 but for winddk.h & friends (i.e. kernel mode ddk). Would be 
used by MingW for kernel-mode development should anyone want to do that.
Also, it would be used by WINE for anything kernel-mode that is needed
And by ReactOS to build the kernel and kernel drivers.

In addition, there would be additions to the libraries plus new header 
files for all 3 items (SDK, MSVCRT and DDK) that would include any 
"undocumented by MS but documented by someone else" functions. One thing to 
remember is that just because they are undocumented doesnt mean that 
Microsoft (or even 3rd parties that have documentation/headers/code that 
isnt "genreally available) hasnt used them.

The new "SDK" could contain features designed with the different projects 
in mind. For example, ReactOS core modules could be built with a flag that 
would tell the headers not to define the "generic" versions of ansi/unicode 
functions. But application developers could build with this flag off.
And so on.

A specific "ReactOS SDK" wouldnt exist since this new SDK would do it all.
The 3 existing sets of header/library files (i.e. WINE headers, 
MingW-Rintime/W32api and ReactOS headers) would be thrown away and replaced 
with this new SDK.

Internal stuff (i.e. stuff thats internal to ReactOS or internal to WINE 
and is not visible to userland apps or to kernel drivers) would go in their 
own internal header files, as needed by each project.

Also,

Now on to the other part of my proposal, code sharing between ReactOS and WINE.
Basicly, ReactOS (and to some extent WINE) is divided up into 5 parts:
1.kernel (ntoskrnl.exe, hal.dll, win32k.sys etc)

2.kernel drivers (mouclass.sys, ndis.sys, vga.sys, videoprt.sys etc)

3.userland core (user32.dll, gdi32.dll, kernel32.dll, ntdll.dll and any 
other userland dll that makes calls to kernel-mode without going via one of 
those 4 dlls)

4.support components (the system services etc)
and 5.other dlls and apps (like comctl32.dll, comdlg32.dll, shell32.dll, 
msvcrt.dll, crtdll.dll, ole32.dll etc)

My view is that:
A.where possible components 2 and 4 should be designed to work on windows 
as well as on ReactOS

B.sharing parts of component 3 (specificly some of the user32 stuff) does 
make sense and should be done in a way thats clean in that the "shared" 
code doesnt rely on any of the internals of WINE or ReactOS and only calls 
  "published" APIs (i.e. regular user32 or gdi32 calls). For example, the 
MessageBox code can be implemented on top of the Dialog Box api and so on.

C.as for component 5, we should implement one and only one copy of those 
dlls. They should only use published APIs and should work "out of the box" 
on Windows, ReactOS and WINE when compiled with the new "SDK" mentioned 
above. DLLs that talk to kernel mode (such as winmm talking to the sound 
driver or winsock talking to networking) should certainly be implemented so 
that they will work OOB on both windows and ReactOS (since we are 
supporting 3rd party drivers in ReactOS anyway we need to implement the 
"glue" between e.g. winmm and the driver in the same way MS did).
WINE is a different issue, mabie they can just implement something in their 
kernel/ntdll that "appears" to e.g. winmm like the sound driver, I dont know.

Ideally, WINE, ReactOS and w32api/MingW-Runtime should be designed to be as 
alike to Windows and Microsoft SDK as possible. (including those bits of 
code that are shared between the projects)