The non-portable DLLs are: ntdll.dll, kernel32.dll, advapi32.dll, gdi32.dll, user32.dll,
They are not portable as a dll, but much code is still portable. With some goodwill from wine we could even make these dlls portable if we wanted too.
I think we should _not_ try to make the non-portable DLLs portable because of the following reasons:
- 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.
After ripping code from Wine I usually discover lots of other bugs in ros (and wine) too, so imo sharing more code is a great "tool" for discovering bugs and shortcomings in ros.
- 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.
The "porting" headers are just macros. Whats bloated about that? Others have suggested to convert to wine style debug macros for all ros umode dlls, and i agree. Also i like the strlenW etc. macros wine uses. Unfortunately we would have to live with the strange unicode strings (it seems).
- 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.
As i said, i'm tired of fixing ros bugs in forked wine code, so obviously it isn't working (correctly). The chances for your code to get thrown away (sometime in the future) is much greater when not sharing, as someone (like me) notice that the ros version has lots of bugs thats fixed in wine, and rips the code all over again...
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
I don't see the point in maintaining two different impl. just so we can say "We wrote it". And we/ros contribute to Wine thus its as much ros "property" as Wines. Sure, a lot of code will be "lost" during an initial merge, but thats most duplicate code anyways. Afterwards, changes will go both ways, and everyone will be happy.
just because it simplifies your work.
It's not about simplifying work. Sharing code will be more work, but it makes sure we have the most up-to-date, bug free code.
Gunnar