Eric Kohl wrote:
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.
I heartily agree with 1 and 2, but I don't think I understand half of 3.
Don't ditch anything without a technical benefit, I agree.
But I dont understand:
"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."
If the visitors statement sometime in the future was correct, would that
be a bad thing?
regards,
Jakob