Eric Kohl wrote:
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.
- 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.
- 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