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)
BTW, the header files and libraries used would be licenced under something like BSD/X11 And the code thats shared between ReactOS and WINE would be LGPL or something similar.
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@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
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
-
Earnie Boyd -
Jonathan Wilson -
Steven Edwards