Linked by Thom Holwerda on Thu 7th Jun 2007 16:30 UTC, submitted by Michael Zandstra
"Alex Ionescu, the ReactOS kernel coordinator, has resigned. Alex first joined the project in 2004, around the 0.2.2 release. Since then, he's been at the center of quite a few squabbles about how to code the kernel. However, Alex has also been responsible for completely rewriting the kernel almost from the ground up. Today, about 60% of the kernel code is probably his. The reason for Alex's departure is because of his joining David Solomon's Expert Seminars as an instructor. Because this job would place him in close contact with many Microsoft programmers and also give him access to other Microsoft properties, continuing with the project would have resulted in possible conflicts of interest."
Permalink for comment 246176
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:
2006-08-02
I guess the real point to be made is ressources. You need far more developers. What changed over the years is that now the architecture is more or less clean. All it needs is someone to pay some skilled full-time developers.
All the major wine developers are employed by Codeweavers.
Like any big project wine is difficult for new people to get involved in: you need a deep understanding of not just the Windows API and the UNIX APIs, but wine's internals as well. It's rewarding work though.
Speaking as a wine hacker myself, yes wine is basically complete: the architecture is all there, what is needed is a lot of work to finish off the last 10%. There is interesting differences between some fundamental APIs in Windows and in UNIX, some of which I suspect Microsoft deliberately put in to make porting away from Windows more difficult. As an example one bug I fixed recently concerned the send() function that sends data over a socket. On UNIX the semantics always were that write/send for a blocking file descriptor sends as much data as it can in one go and then returns. On Windows the semantics are that it sends everything, waiting as long as it takes. The result is apps written with the UNIX assumptions worked perfectly on Windows and wine, but apps written with the Windows semantics broke due to the short writes until I patched wine to loop calling send() until all the data is sent.
What a sneaky trap: the Windows semantics are a subset of the UNIX semantics so UNIX apps can be recompiled for Windows and still work, but apps written with the Windows semantics will encounter short writes on UNIX that didn't happen on Windows, needing a lot more work to port away from Windows.