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