To view parent comment, click here.
To read all comments associated with this story, please click here.
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.
> 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).






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.