Linked by Thom Holwerda on Thu 7th Jun 2007 16:30 UTC, submitted by Michael Zandstra
ReactOS "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."
Thread beginning with comment 246092
To view parent comment, click here.
To read all comments associated with this story, please click here.
Elektro
Member since:
2006-08-19

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.

Reply Parent Score: 1

draethus 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.

Reply Parent Score: 4

Elektro Member since:
2006-08-19

I don't mean codeweavers, I mean a sponsor who says: Let's dump 10 developers on the directX implementation or so and let's finish it. Someone needs to spent real money on Wine. Once Corel supported it. When you compete with a company that had thousands developers to build something you require some people. The wine development team did not scale very well.

Reply Parent Score: 1

Morin Member since:
2005-12-31

> 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.

Not defending MS (whose tactics could certainly include a "trap" as you describe), but Windows' version of send is actually more intuitive to a developer, so the reason for this difference could as well be the decision to make it as easy for application developers as possible (which is IMO a sensible goal, as it results in higher-quality applications, increasing the overall quality of the whole platform).

Reply Parent Score: 2