Mono is the open-source version of Microsoft’s .NET Framework. It implements most of the backend framework features, but unfortunately, falls flat on its pretty little face when attempting to display the user interface – which is what desktop apps are all about.
Wine on the other-hand, is a Linux port of (major parts of) Microsoft’s Win32 library – the core dependencies of the Windows development libraries, and more importantly, the win32 interface elements. With Wine, you can run many traditional C++ win32 executables on Linux, with certain limitations.
Mono’s biggest stumbling block is the GUI and .NET programs that use P/Invoke to call native non-managed win32 dlls – Mono is a pure .NET environment, and can’t handle them. But from the description above, that’s exactly what WINE excel at… So can’t we use WINE + Mono to make just about any .NET program run on Linux fresh out of the .NET compiler?
Unfortunately, the answer is no. Back when the Mono project was first starting out, the Mono development team considered using WINE to implement the System.Windows.Forms namespace of the .NET Framework (which is practically 100% native C++ unmanaged win32 code in .NET wrappers). But they made the right choice in deciding to not take the easy way and go that route, leaving the integrity of the Mono project intact and focusing on true cross-platform user interface libraries instead (the GTK# is now the UI Library of choice for cross-platform .NET applications).
But until the GTK# library becomes a more viable choice or the Mono “port” of SWF becomes more complete (see below), shouldn’t something like this be made possible? It certainly would be great to just type
$ wine win32_NET_app.exe --mono=/usr/lib/mono/
or maybe (depending on what app does the integration):
$ mono win32_NET_app.exe --wine=/usr/lib/wine/
And have Wine hand-off the .NET Win32 application to Mono, and intercept the P/Invoke calls to Win32 DLLs, replacing them with its own ported Win32 libraries on-the-fly.. That would be great, wouldn’t it?
Unfortunately, we’re not the people in charge at Wine or Mono and such an implementation would take some time and effort to get going – though it is our opinion that if such a thing is done it must be Wine that is modified and not Mono – in order to preserve the true cross-platform nature of the Mono project and keep it from the legal quagmire that is the Win32 library.
At the moment, the Mono team is working on a “port” of sorts for System.Windows.Forms which will let almost all programs written and designed for Windows run on Linux without a problem. Instead of porting the actual SWF controls to Mono, the Mono team is working on a “compatibility layer” of sorts that will render the controls on-the-fly, making it look more “natural” no matter what platform it’s running on.
In the mean time, we highly recommend developers consider using the (technically-inferior, compatibility-superior) GTK# UI library instead of SWF for your .NET projects (on and off of Windows); and end-users can install the latest dev copy of Mono to gain access to the SWF “ported” library to make those Windows apps work!
Actually, using Wine was not the easy way out (too much instability, and GDI+ inefficiencies, and was the reason they abandoned it.
There’s supposed to be a closing paren after “inefficiencies.”
“consider using the (technically-inferior, compatibility-superior) GTK#”
Looks right to me…
ReactOS is built on the Wine code (more or less, obvious or otherwise) and it’s quite stable (relatively speaking, for an alpha OS) and doesn’t seem to have any serious GDI deficiencies.
http://neosmart.net/blog/2006/reactos-the-next-windows/