[ros-kernel] a proposal that will affect MingW-Runtime, w32api,
ReactOS and WINE
jonwil at tpgi.com.au
Sat Oct 18 13:44:53 CEST 2003
Currently, we have 3 different projects that are working towards windows
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,
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.
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)
More information about the Ros-kernel