[ros-kernel] Sharing code with wine

[Casper H. <ch...@us...>]

Porting wine code seem to be the hot topic these days, so I think it is
time to discuss ways to share code with the wine project before having
ported most wine code and no (easy) way to update it in the future.

>From looking through current wine code, I see that most wine DLL's can
be shared between the two projects. There are occational references to
wine/*.h in the wine DLL modules and some of the headers in that
directory
are wine specific, but most of then are not. IMHO, it will be in the
best
interest of both projects to share Windows API DLLs wherever possible.
The reason for this is obvious; A DLL has to be implemented only once.

So what are the problems associated with such a project?

Structure - Should we move all the shared wine code into a separate
directory like reactos/wine?

It has been mentioned on the ros-kernel list to use mingw headers
instead
of having separate headers due to the fact that 1) mingw headers have a
greater chance of beeing updated more often 2) The mingw team could
benefit
from these headers (the ntddk case). Another possibillity is to have our
own
version of the Windows headers shared with wine.

I'm leaning towards the former - using mingw headers. This way may mean
more
work when updating shared wine code, because if there is a change in
public
Windows headers, both set of headers needs to be updated (wine and
mingw).
Of course, we could just do it properly from the start and implement the
full
set of Windows headers. Then this will not be a problem ;o)

Synchronization - How do we synchronize between the two? Can this happen
automatically? Should it be? Has anyone heard of cvsup
(http://www.polstra.com/projects/freeware/CVSup/) and wether it can
synchronize
on the file or directory level instead of cvs module level? If it can
synchronize on the file or directory level then that would be great. And
if
we could have this done automatically without too many conflicts, it is
worth
considering.

Build system - The two projects have their own build system. The wine
team uses
GNU autoconf and we use GNU make with a helper makefile. Since the wine
build
system is very posix centric and we have a customized build system, I
think we
should keep the build systems seperated. This involves maintaining two
sets of
make files, but I think it is worth it. The end result is different
anyway,
ReactOS DLL's ARE DLL's, whereas the wine DLL's are included in a big
executable image.

Copyright - IIRC from the list discussions, we can use wine code without
obtaining permission from the wine developers, but the wine developers
cannot
use ReactOS code without permission from each of the copyright holders.
Does
transferring copyright to FSF (if we decide to) change anything? Like,
then the
FSF would have to grant the wine team permission to use the code.

Wine modules that I do think is worth porting/sharing:

gdi32.dll - obviously
icmp.dll - OS dependent
kernel32.dll - OS dependent
ntdll.dll - obviously
opengl32.dll - wine specific
user32.dll - we will have calls directly to win32k.sys
wnaspi32.dll - OS dependent
all winsock related modules

and the 16-bit only DLL's.

Let's discuss this topic and propose a plan for code integration to the
wine developers.

- Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================