[Mingw-users] a proposal that will affect MingW-Runtime, w32api, ReactOS and WINE

[Earnie Boyd]

Jonathan Wilson wrote:
> 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.
> 

Please note that design differences help to enforce the issue of our not 
enfringing on MS Copyright.  I agree that if MSDN says FOO is declared 
in foo.h that FOO should be declared in foo.h.  However, if MSDN says 
FOO is declared in foo.h and bar.h then implementation of how both files 
define FOO is another matter.  Too often we run into problems with 
duplicate definitions that resolve to the same value but are defined 
differently and cause compiler warnings and errors.  We should place 
such definitions into a common header with __need_FOO macro filters. 
This gives us one place to define what is needed and makes maintenance 
easier since it is defined only in one file.

> 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)
> 

Ok

> 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.
> 

Ok

> 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.
> 

These undocumented features would have to be hailed as such.  I.E. they 
would need to go to include/undocumented.

Earnie
-- 
http://www.mingw.org
Powered by SourceForge <http://sourceforge.net/projects/mingw>