Fw: [Mono-list] System.Windows.Forms plans.

[Mike Hearn]

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