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

[Steven Edwards]

Jason and I proposed this at Wineconf and we have discussed this with
the Mingw developers in the past. The big issue becomes this: Are you
willing to do the leg work needed to make it happen? I am but most are
not. It is a thankless and not well noticed job. Not to mention a
project that is going to take quite a long time. It has take over two
years just for those of us that have been working on both WINE and
ReactOS to get things to the point they are now. Dont get me wrong I am
not trying to bring you down. Your proposal is put together much better
than any of the others so far but its still just that. If you want to
put together a team of developers to work on this I for one am happy to
join and be part of that team. I dont have high hopes of this plan
being adopted but if it is I for one am willing to get behind it but
its going to need strong leadership and time. Not to mention the
polictical problems you are going to face

Also you are leaving the mono Windows.Forms people out of this
dicussion. They of all people should also be included in any plans we
have. Without all 4 projects working together our prospects dont look
good.

Thanks
Steven

--- Jonathan Wilson <jonwil at tpgi.com.au> wrote:
> 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)
> 
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com