Hello Peter,
I am not trying to be rude but...
--- Peter Dennis Bartok peter@novonyx.com wrote:
Rather than spending a whole lot of time rewritting things wouldnt
it
be better to help the Wine project get stable and move to the 1.0
goal?
There is a roadmap and TODO on Winehq of things that are needed for 1.0.
No, it wouldn't. Even if Wine already was 1.0 we still would not have the portability we're trying to get (ie. run on Solaris Sparc, Mac OS, etc) and
Well Winelib does run on PPC and the port to Sparc is mostly done. 99% of Wine even compiles on Alpha here for me. See
http://www.winehq.com/site/status_porting
debugging would still be almost impossible (Wine does funky stuff with register for thread storage, special stuff would be required to setup Mono-created threads before they'd be able to call Wine functions, etc). Also, there doesn't seem to be much interest from the Wine community to do anything that helps using Wine with SWF/Mono. We've had to resort to some quite complicated mechanisms to even be able to use Wine as a shared, runtime attached library, after Alexandre rejected a patch that only touched six lines of existing Wine code and added a new library to Wine, to allow straightforward use of Wine as a library. Having to take instead the complicated route it now means that many people are having problems getting SWF to run at all, with due to strict path dependencies.
I was there when Miguel came online to ask why the patch was not merged and I also seem to recall Alexandre proposed a fix the would work and seemed to make Miguel happy.
See: http://www.winehq.org/hypermail/wine-devel/2004/03/0150.html
Another problem was that we had to spend way too much time tracking what changed from one Wine version to the next. For example from April to May, the wine_get_unix_file_name() function arguments were changed (I'm not even asking why it was changed instead of introducing a new function with different arguments and leaving the old one for those people who might use it). Since I can't require always the latest Wine version, I have to come up with code figuring out what Wine version might be running, and write code to make version dependent Wine calls. I'd rather spend that time improving SWF.
Once again how can you fuss about unstable interfaces on a project that does not have a stable release? You could work with Winehq to create those stable interfaces.
Besides how can you blame the Wine project for tracking changes when the first patch Mono submitted was this?
http://primates.ximian.com/~duncan/mono-wine/sources/mono-wine.patch
A whole bunch of #ifdefs and other kludges that violates Winehq coding standards.
Notice how people complain on this mailing that they're having problems getting even basic stuff going? The SWF code works, it's the interaction with Wine that's mostly causing the problems. Again, as I said, it will become much easier for the regular user once the Wine dependency is removed and the controls are all in managed code.
Alright well I am not claiming to know very much about the project. Like I said I only lurk here because I care about how its going to run on ReactOS. I guess my final though on the matter is that if Vertigo Software could make a mananged Quake2, how hard can it be for you to make a managed Wine?
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
-
Steven Edwards