Author: Zach Tong
Issue: 2
Date: 24 Nov 2004
Ibrahim Damlaj informed the dev mailing list that Ekush.com was up again, with a much modified message (Here). There were two main opinions on the matter. 1) Accept nothing from the Ekush project, they are not to be trusted and
2) Accept patches carefully. This in turn led to some interesting discussion about "tainted" code from the leaked Windows
2000 source. K McI says that by merely looking at the patches to see if they are tainted in fact taints the project:
But wouldn't that require to possess said code, which is (I think) illegal, and expose us (Or whoever does this vetting) to
the risk of being "tainted" with the MS stuff?
.
This idea, the fact that no members of the ReactOS team can ever see the leaked code (even if checking to make sure it doesn't
get patched into ReactOS", led to more discussion in a spinoff thread titled [ros-dev] Idea to protect ReactOS. The participants decided that a third party would be needed to check the code. It was suggested that Microsoft do this,
which was decided might not be the best idea either:
"Right idea, but wrong source I think. We need a neutral party who is under a microsoft NDA but contributes code neither
to microsoft's nor our codebase."
It was also noted that this would probably be a service that would require payment at some point.
Many members felt that Ekush could not be trusted anyhow, and no patches should be added. While it dismisses Ekush, it does
not however dismiss large future patches from other sources that could contain leaked code. Ibrahim Damlaj brings up a good point about how vulnerable ReactOS is to "tainted" code:
"That's really freaky, since they may give M$ a chance to shut down the Reactos."
An interesting read can be found here. Ge van Geldorp sent the Ekush project a very diplomatic letter explaining the situation.
Jonathan Wilson made a proposal for sweeping changes in the organization of the headers currently in use by ReactOS. Basically, there are three different
header sets (Wine, ReactOS, MingW). Jonathan sums up the proposal:
"Basicly, the idea is that mingw-runtime would become the 'definitive' set of msvcrt.dll headers out there and that ReactOS,
MingW and WINE would
start using it for any case where you are talking to msvcrt.dll from the public side."
Alex Ionescu said he was
"already working on a complete header system overhaul that's been approved and very much requested by the other developers."
and would be guarnateed to
support MS PSDK/DDK/IFS
. Much debate ensued, with several trains of thought emerging. Jonathan said it would be a good idea to
"[Keep] the 'undocumented' stuff (i.e. the bits microsoft doesnt document in the Platform SDK) and the 'documented' stuff
seperate (i.e. putting the undocumented stuff into seperate headers)"
To this Alex Ionescu replied:
"We will do as planned and put undocumented stuff in the NDK"
. Furthermore, Alex recommended to wait for what he was working on, and then
"you can all flame me instead of arguing with each others"
.
Art Yerkes made a request to the dev mailing list to help get PuTTY working under windows. Casper Hornstrup points out that an earlier version (later determined to be 0.53b official) worked fine on ReactOS. Art replies with a very interesting point about ReactOS and the expectations we all place on what it can and can't do:
"1) My thoughts are twofold; putty works on wine and windows, and so a compatible system such as reactos ought to be able
to the same. I think having CreateDialog work right is not so much to ask.
2) We get no credibility having to port apps to run on reactos. Sometimes I do patch an app so i can get past a known problem
by my goal is always
ultimately to run the app unpatched. My guess is that an eventual end user will expect the author's version to work."
Ge van Geldorp determined that the problem was ReactOS's handling of the WM_SETREDRAW message. PuTTY's main dialog window is sent the message twice in windlg.c, first with a FALSE parameter, then later with a TRUE parameter. The second call is the call that makes the window display on Windows and Wine, but was not working on ReactOS. GvG fixed the problem, and PuTTY was restored to working condition (regarding its UI).
Steven Edwards wanted to merge the duplicate headers in reactos/include/wine into the headers of reactos/w32api/include.
Since ReactOS had i'ts own w32api it didn't need most of the headers that used #include_next. Magnus said that it would be
a problem due to compatability reasons with Wine and MinGW,
Some wine header are wrong. It will only work for wine. Until some fix wine compatible with mingw headers.
It was brought up ( by James Tabor) that Wine does not appear to be helping the situation by using things that not compatable. Steven reminds everyone that Wine's goals are different from ReactOS's. Mainly, they do not care if things are done the "Windows Way", as long as the end product works. ReactOS on the other hand, must implement things the same way Windows does.
Steven Edwards makes an interesting point:
"One problem that we face is that some of the headers such as FDI.h and
FCI.h mingw wont accept because Microsoft only publishes the specs in a package you have to accept a EULA to read."
This section contains nothing more than interesting CVS comments that I personally like. There are more CVS comments then listed here, and many more actual commits.
This work is licensed under a Creative Commons License.