22 Dec
2004
22 Dec
'04
1:42 p.m.
Gunnar Dalsnes wrote:
I'm tired of fixing bugs in code ported from wine
<x> years ago. In most
cases the bugs has already been fixed in the wine code we ripped from,
but the ros variant is forked so much its impossible to inc. those fixes
into ros, so the only choice is to rip the whole wine source over again,
loosing any possible fixes/improvements we had made to the ros variant
vs. the wine variant.
Take for example the file lib\kernel32\misc\profile.c. This file is
99.9% unchanged from wine, and only includes and some prototypes needed
changes. I want to move files like this into wine subdirs. like
lib\kernel32\misc\wine\profile.c and generate an initial diff
lib\kernel32\misc\wine\profile.diff with changes made to make it run on
ros using the wine porting headers. It does not mean that this diff will
contain ERR changed to DPRINT etc. Only the bare changes to make it
compile. Moving files into wine dirs in off course not necesary, but it
makes it clear that this file(s) are shared thus there are rules to
follow when changing them.
First or all we have to distinguish between portable and non-portable DLLs.
Portable DLLs, like comctl32.dll, can be shared between ReactOS and Wine
because they do not use non-portable features of the underlying OS. In
most cases they only use the Win32-APIs.
Non-portable DLLs are not portable because they use features that differ
between ReactOS and Wine. Examples are kernel32.dll because consoles are
implemented in different ways, gdi32.dll and user32.dll because the use
the INT2E interface to call into win32k.sys.
The non-portable DLLs are:
ntdll.dll, kernel32.dll, advapi32.dll, gdi32.dll, user32.dll,
I think we should _not_ try to make the non-portable DLLs portable
because of the following reasons:
1) We always need to ensure that a DLL works on ReactOS. Wine developers
cannot check whether one of their patches break a DLL on ReactOS.
2) Don't mix ReactOS code and Wine code. This is bloating the ReactOS
DLLs and we'll have two sets of debug APIs (DPRINT/CHECKPOINT vs.
FIXME/ERR/WARN/TRACE) in one DLL.
3) Don't replace working ReactOS code just because you think you can. I
don't want to see a lot of my work getting thrown away without a major
_technical_ benefit. And I don't want to face a situation where I am at
an exhibition (like LinuxWorld Expo) and a visitor tells me that the
ReactOS developers didn't write any user-mode components because each
and every component has been merged with Wine and the ReactOS code has
been replace by Wine code just because it simplifies your work.
Regards,
Eric Kohl