Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.
May I remind you that this thread was started by you, asking why we are abandoning Wine, not by me complaining about Wine. All I did was give you the reasons why we are no longer using Wine. You may not like them, you may disagree with them, but the decision has been made. And there is really nothing to be gained in nitpicking or pointing fingers. I don't understand the comment about managed Quake, but we don't have to create managed Wine. We simply have to create the SWF controls in managed code and the underlying SWF framework. Wine doesn't have anything to do with the framework, anyway, so it's down to the controls. And even by using the Wine controls we still would have to either modify Wine to support the additional functionality required by SWF, or subclass them, basically recreating the drawing code for those controls and just using the WndProc messages from Wine. So, you can see it's really just a small step to then drop Wine and handle the management of Windows ourselves instead of using Wine for it. Not trying to be rude either. You asked, I answered. Peter -----Original Message----- From: "Steven Edwards" <steven_ed4153(a)yahoo.com> To: "Peter Dennis Bartok" <peter(a)novonyx.com>; <mono-winforms-list(a)ximian.com> Cc: <wine-devel(a)winehq.com> Date: Thursday, 01 July, 2004 21:03 Subject: Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.
Hello Peter,
I am not trying to be rude but...
--- Peter Dennis Bartok <peter(a)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 _______________________________________________ Mono-winforms-list maillist - Mono-winforms-list(a)lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
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.
PDB might not be able to fuss, but I will. I recently asked about a way to figure out which version of Wine is in use at run-time because of the recent changes to wine_init()'s prototype. Alexandre appeared quite adamant that he was against introducing any such mechanism. Wine has a bit of a problem with the Mono project and our much smaller FST project to support VST win32/x86 plugins on linux. It has previously been a self-contained project that did not provide libraries, and whose internal API was not accessed by anyone or anything outside of Wine itself. It now is being used by (at least) 2 projects as a *library*, and it can either accept that role - which implies providing (at least) runtime version info - or reject it, which would be a great shame. --p
Paul, --- Paul Davis <paul(a)linuxaudiosystems.com> wrote:
PDB might not be able to fuss, but I will. I recently asked about a way to figure out which version of Wine is in use at run-time because of the recent changes to wine_init()'s prototype. Alexandre appeared quite adamant that he was against introducing any such mechanism.
Wine has a bit of a problem with the Mono project and our much smaller FST project to support VST win32/x86 plugins on linux. It has previously been a self-contained project that did not provide libraries, and whose internal API was not accessed by anyone or anything outside of Wine itself. It now is being used by (at least) 2 projects as a *library*, and it can either accept that role - which implies providing (at least) runtime version info - or reject it, which would be a great shame.
You are asking for stable interfaces and those can only come once there is a Wine 1.0. Its not here and dont get me wrong I think the Wine TODO list is way to long and things should be close to frozen by now but thats not the case. All you are doing is pointing out that its not stable which is well known. I wish it was stable now but its not and until the TODO is done its not going to be. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Hi, I'm largely incompetent in this field, so please forgive my fallacies in the comment below, but I felt sad reading Steven Edwards <steven_ed4153(a)yahoo.com> write:
--- Paul Davis <paul(a)linuxaudiosystems.com> wrote:
PDB might not be able to fuss, but I will. I recently asked about a way to figure out which version of Wine is in use at run-time because of the recent changes to wine_init()'s prototype. Alexandre appeared quite adamant that he was against introducing any such mechanism.
You are asking for stable interfaces and those can only come once there is a Wine 1.0. [...] All you are doing is pointing out that its not stable which is well known.
Well, not in my reading. Paul's asking for a way to *know* about (and act accordingly to) interface changes. He asked for an exported WINE_VERSION symbol for example. Alexandre didn't want to encourage that kind of version checks. Right, one shouldn't check for API versions but for features, and that's what people want in the first place anyway (if I understand correctly).
[Wine] now is being used by (at least) 2 projects as a *library*, and it can either accept that role - which implies providing (at least) runtime version info - or reject it, which would be a great shame.
It's not causing me warm fuzzies to see great projects duplicating each others' efforts for the lack of open negotiation. Knowledgeable people, please propose something to let these guys use and help Wine! -- Feri.
On Thu, 01 Jul 2004 21:22:24 -0700, Steven Edwards wrote:
You are asking for stable interfaces and those can only come once there is a Wine 1.0.
To be frank, I think we could declare Wine interface stable *today*. Versioning APIs is not exactly rocket science, yes it implies compromises but it's quite clear that Wine 1.0 is years away. These people want to use it today. We have all kinds of goals for 0.9 and 1.0 mixed in together and we seem to have decided pretty much arbitrarily that they should all occur at once, but I don't see the logic behind that. I really feel that yes we should support Wine as a library, and that means making the APIs we export stable ASAP. I especially think we should stop the nonsense where we use GNU symbol versions in libwine marked "1.0" while not actually keeping them stable. OK, so having had that rant, I also think that not using Wine to implement System.Windows.Forms is crazy too (hmm, there's a theme here, guess I'm feeling contrary today). The only reason to implement SWF is to run .NET apps built for Windows, it's a sucky toolkit compared to GTK# and isn't going to be used for writing apps on Linux that's for sure. Therefore perfect compatibility is crucial. SWF is a very leaky API, there are the obvious ones like WndProc and Control.Handle but it almost certainly leaks in other ways: for instance, the order in which events are fired, that sort of thing. This *matters*, I've seen many apps crash and burn in mysterious ways due to tiny differences in the order notifications were sent to it and other subtleties. Now, I think some of Peters arguments are valid and some aren't. Let's take a look at them: * Wine is too hard to use as a library. It does complicated things with registers and threads, and requires wierd bootstrap code. I'm not sure what to make of this one. The low level code isn't optional, it's required in order to provide the environment Win32 code requires. Mono likewise does some pretty complicated stuff to provide a .NET JITing runtime so you guys are clearly competent when it comes to low level code. If you skip the hard stuff here then you'll just hit a brick wall further down the road when you start trying to run *real apps* which P/Invoke to native code, poke controls via their Handles and other icky things. .NET simply wasn't created for portability at all, regardless of what Microsoft might say, and production .NET apps developed for Windows will require a Windows environment. * Wine isn't portable enough. I disagree here. I think this is bunk. It's been ported to a bunch of CPU archs and operating systems. It's probably runs on only slightly fewer platforms than Mono itself. * Wines APIs are unstable. See above. I think Peter is right, our exported APIs are not that large, and making them stable is not that hard either. They don't even have to be hard-iron set-in-stone will never ever ever change stable, simply doing our best would be a big improvement over what we have now. The flip side of this is that nobody is forcing you to use the latest version of Wine, or even dynamically link to it in the first place, you could easily just import snapshots into Mono CVS. * People find it too hard to setup. Well, I've been flicking through the June archives of mono-winforms-list and I'm not seeing this at all ... yes there are lots of people saying "I wrote this app and it doesn't work!" but then SWF isn't complete and neither is Wine, so no big surprises there. The only setup related problems I could see are related to hardcoded paths being compiled into binaries - this is trivial to fix inside Wine and Mono, in fact I wrote a patch months ago to do this for Wine (so it can run from any prefix). It'd be easy to get this applied. The other problems I've seen are just random crashes which could be in the SWF code or Wine, I don't know which. Wine really is not hard to set up. You just install it, same as any regular library. Yes, you can then not do mv /opt/wine1 /opt/wine2 and have it run, but that's like a 10 minute fix as I already did 99% of the work. * GDI+/Wine interactions are too slow. I suspect this isn't a problem for Microsoft because they implemented GDI+ in native code then bound it to .NET. You guys are trying to implement GDI+ in .NET and then make Wine use it, which is a suboptimal solution. I think if you had done it the way Microsoft did by writing a GDI+ DLL for Wine and then mapped that to System.Drawing, there would not need to be this constant mapping into System.Drawing contexs and things would go a lot faster. Yes, that means implementing GDI+ in Win32/C, not much fun I know, but it's the way Microsoft did it and therefore if we want compatibility the way we must do it too (Wine will have to implement GDI+ itself at some point anyway). * All our problems will go away if we implement S.W.F in C# I strongly disagree with this notion. Nobody sane implements a production widget toolkit unless they have to, they are HUGE, win32 especially so because it's so old. The listview control alone has a bazillion different modes. I think Dimi estimated it'd cost $145,000 to develop at current market rates. Even worse, you can't implement SWF is managed code and get correct compatibility without reimplementing most of Wine in managed code as well, which would be even sillier. The plan of doing an emulated WndProc in C# with the most common case is just going to lead to an endless stream of people trying to run apps and reporting "blah blah message isn't implemented", or worse "blah app has native code and passes it Control.Handle". I'm very sceptical you can use a "winelib plugin" to fix that - how can this work when the HWND the native code is trying to use is fake? Oh, don't forget details like handles being valid in any process! Programs that use OLE embedding between themselves *depend* on that fact. It especially makes me sad to see this because eventually people are going to start coming to us with hybrid .NET/Win32 apps and want to run them via Wine or Mono. They won't run on Mono because they'll P/Invoke to native GUI code to do stuff that .NET/SWF can't do, and they won't run on Wine because we don't implement the .NET framework. I really think we should make another attempt to work together on this one - last time Paul raised the issue of wine_init changing its prototype (which caused them pain), Alexandre actually reverted the change. Too late in some respects, the damage was already done, but I think it's wrong to say we aren't interested in working with you. The last time Mono even had a presence on this list, it was asking how to open Wine as a library and example code was written for you. None of the other concerns were ever raised here, as far as I remember. Well, you seem to have made up your mind, but I just have this horrible sinking feeling that one day WineHQ is going to have to do our own implementation of S.W.F in order to be able to run apps of the complexity people demand. Half baked solutions along the lines of "sorry using Control.Handle/the registry/whatever isn't portable" won't cut it when this is the last app blocking a migration to free software but they can't/won't rewrite it. ciao -mike
I really feel that yes we should support Wine as a library, and that means making the APIs we export stable ASAP. I especially think we should stop
I don't think this is necessary. The functionality that Wine offers is significant enough that developers like myself and Torben (I don't know about the Mono/SWF guys) would probably be willing to put up with frequent API changes. But I can't do that when there is no way for me to discover the correct prototype for wine_init() or some of the very limited number of other internal wine functions we need to call. Stable APIs - if you want. Accurate and useful version information - can't live without it.
I really think we should make another attempt to work together on this one - last time Paul raised the issue of wine_init changing its prototype (which caused them pain), Alexandre actually reverted the change. Too late in some respects, the damage was already done, but I think it's wrong to
Perhaps more to the point, I didn't even know that he had done this! --p
On Fri, 2004-07-02 at 09:40 -0400, Paul Davis wrote:
Perhaps more to the point, I didn't even know that he had done this!
This is a common problem, Alexandre doesn't tend to announce commits people may find interesting to the list. I've taken up monitoring wine-cvs and picking out some of them, I must have overlooked that one :(
Bascily, there should be 3 sorts of APIs exported in WINE. 1.windows apis. These dont change (some may be added or their implementation improved but the prototypes of an existing call wont change unless it was wrong in the first place) 2.internal WINE apis. These should be for WINE use only and free to be changed for whatever reason. and 3.external WINE apis. There should be a limited set of special APIs which are made available to enable projects like mono and others wanting to interact with win32 code and/or the windows API implementation in WINE. These should be specificly documented and made stable (as in, we wont changer the prototype and we wont change the basic idea of what these functions do). For example, a function that one can call after loading WINE as a shared library to enable WINE to initalize itself. And one to do whatever per-thread stuff WINE needs to do for an existing thread created outside WINE (or alternativly a way to create a WINE thread that can then be used outside the WINE code) And some functionality to enable the loading of windows DLLs and calling code inside them properly. (this should be done so that it will work both for user dlls and also for system dlls so that you can e.g. do WineLoadLibrary("ole32.dll") and it would load the correct ole32.dll based on if the user has said they want native or builtin and then you could get the correct addresses) And whatever else is needed to enable mono, linux winamp plugin loaders and whatever else might want to make windows API calls and/or load and use WIN32 code. If these were made stable, then apps that use them could be gauranteed that things wont break. Then, the only thing they need versioning for is to identify if a certain windows API is present or not. If it is, WineGetProcAddress (or whatever it is) will return an appropriate address. If its not, it would return an arror and you could work around it. (which may mean prompting the user to upgrade WINE).
On Fri, Jul 02, 2004 at 10:48:57PM +0800, Jonathan Wilson wrote:
Bascily, there should be 3 sorts of APIs exported in WINE. ... and 3.external WINE apis. There should be a limited set of special APIs which are made available to enable projects like mono and others wanting to interact with win32 code and/or the windows API implementation in WINE. These should be specificly documented and made stable (as in, we wont changer the prototype and we wont change the basic idea of what these functions do).
In other words, what Wine needs is not so much a stable API as a stable meta-API to determine what is actually supported.
For example, ...
If these were made stable, then apps that use them could be gauranteed that things wont break. Then, the only thing they need versioning for is to identify if a certain windows API is present or not. If it is, WineGetProcAddress (or whatever it is) will return an appropriate address. If its not, it would return an arror and you could work around it. (which may mean prompting the user to upgrade WINE).
The smaller said native-interaction API is, the easier it will be to keep stable. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
participants (8)
-
David Lee Lambert -
Ferenc Wagner -
Jonathan Wilson -
Mike Hearn -
Paul Davis -
Peter Dennis Bartok -
Shachar Shemesh -
Steven Edwards