I would be lying to you if I told you I was privy to the rational behind Monos choices regarding exe/dll and S.W.F. Over the years I have seen many bitterly complain about both and these two items have been often cited as reasons against Mono. But from my vantage point I think that harping on these decisions detracts from the concrete benefits that have been realized by the Mono project. In other words: one is left comparing what-if's with the reality at hand-and frankly I do not think the reality at hand is all that bad.

Although far from optimal from the total cross-platform perspective I whole heartedly appreciate the work that was done to create Gtk#/cocoa#. Right now I have at least a dozen applications installed on my machine which make use of Gtk#- good applications which I enjoy using and which provide me with tangible benefits. The availability of Gtk# means that some of the brightest devs who support Linux are using this toolset to create applications which I enjoy using.

To be honest is it really any surprise that Miguel chose to poor more effort into bringing Mono to the GNOME desktop than to focusing on SWF? After all who was it who started the GNOME project ? Right, it was Miguel. Surely you have heard the endless tirade against Miguel because of his having supposedly "sold out" to the Evil(TM) MS world. You cannot make everyone happy: You cannot be everyones friend. With each decision you make you will gain some friends and lose some-such is life.

In Miguels estimation Linux was lacking in a comprehensive framework for rapid application development-he saw Mono as a solution to this problem: bringing the ease of app development of .Net to the Linux GNOME desktop. And for some non-insignificant number of GNOME hackers he was right-they embraced this tech and started making desktop apps which many user enjoy using. Furthermore I believe Mono was instrumental in Vala being so aggresively pursued-a lot of hackers these days do not want to break their heads on code written in C.

Gtk# illustrated an alternative way to create modern Linux desktop apps and if anything spurred more and more devs to invest energy in trying to bring the advantages of the programming styles present in .Net to Linux-and I believe that Vala is but one example of this-not that there is a direct link between Mono and Vala but that both are outlets for programmers wishing to have easier and better tools for creating applications which easens the burden of writing and maintaing applications. There have been calls from all quarters for years for GNOME to adopt a higher level language for app development-the political controversy about licensing pitted Gtk# versus Java, Vala is emerging as a 3rd alternative which has none of this baggage.

That Miguel would have wanted to see the fruits of his labor in creating Mono be available and immediately usable for GNOME hackers is hardly surprising-this is the community he came from, and he and others worked hard at creating a really good implementation of .Net custom-tailored to the Linux GNOME desktop, despite being attacked from the left and right continuously.

To a lesser extent Mono then extended this focus to cocoa#. From what I understand there are now a number of Mac apps written in cocoa#. Both Gtk# and cocoa# are targetting current devs in these respective communities offering them tools which have proven quite valuable to them. When we talk about devs we are talking for the most part about devs who are already committed to one OS/platform-only some of those devs are working on projects which are designed for cross-platform functionality. Cross-platform functionality is frequently an add-on, ie. once the initial app is completed and runs on *a* platform devs wish to extend it to other platforms (ie. google chrome). The number of devs working on projects which from conception are designed to be multi-platform is dwarfed by those working on apps for one platform which are then extended to become cross-platform. Mono made a strategic decision in choosing to focus on Gtk# and cocoa#. The Mono team also is fully cognisant of the conundrum where at once people want multi-platform apps and at the same time constantly bitch and moan about the lack of platform-specific integration(ie. trully multi-platform apps tend to be "at home" nowhere).

From the vantage point of those who wish to see Mono as a purely multi-platform framework surely many are greatly disappointed in Mono. But Mono is an alternative implementation of .Net which at once is custom-tailored to both Linux (via Gtk#) and Mac (via cocoa#) and which on these platform provides very "native" applications(at least this is true for Linux and probably to a lesser extent for Mac-I don't have a Mac so I can't say much about the degree of Mono's success in making itself "native" on Mac) AND at the same time Mono is generic enough to make it cross-platform for a wide range of apps (server(Second Life) and client) on a trully impressive range of platforms (Wii, iphone, Android, Maemo etc.). You could fault them for trying to much, but not for not trying hard enough.

I suspect that the decision against SWF had a bunch of factors. I think Mainsoft and the agreements between Mainsoft and Mono probably played a role in this. It is also possible that there were more patent concerns in this area and that MS had told them not to pursue this. And Miguel and his team have been privy to the planning of .Net far beyond what most .Net devs are and may have seen SWF as being but a short-lived tech which Microsoft itself would be leaving behind( I am not a .Net coder and no remarkably little about all the ins and outs but wasn't Avalon supposed to superced SWF ?-could be totally wrong but IIRC Miguel even mentioned this 2-3 years ago). At any rate I sill question the extent to which Mono could have created a multi-platform GUI which would not have been subject to derision by those who lament platform-specific integration. Java is only now becomming viable in this regard -people have bitched and moaned about Java being alien everywhere for so long-Java was practically forked for SWT to address this issue. Toolkits like Wx have only succeeded in addressing this issue to the extent that they have been successful and from my POV that success has been marginal. Qt seems to have the best cross-platform support-but there are issues there as well (licensing, costs, c++).

As regards the exe/dll: I simply do not see this as being such a big issue. Firstly I suspect if Mono was ever to reach the point that people considered Mono before considering .Net (ie. Mono became the standard) that this could be changed-perhaps it should-but not when the number of Mono developers is dwarfed 100 to 1 by .Net developers. Secondly I have no clue as to what would be involved in creating a format which ran natively (ie. without ilrun and other mechanisms)-is such even doable? Now making Mono target ELF for Linux apps would make a lot of sense-but I suspect that lot of Mono development still takes place in MS Visual Studio-perhaps this plays a role in this decision-I really don't know-but you know I have never cringed seeing a dll file in my file system, and I have not gotten a rash due to seeing exe files. Mono apps are usually started with a bash script -big friggin deal-do you *really* care so much about whether Linux can make use of the RES chunk of the exe/dll file? I just don't get why this is a *deal-breaker*.

I guess my last question is this: you seem to be quite competent in .Net programming- what is preventing *you* from offering your skills to implement the things you so wish to see ? I am not currently an active programmer and I would need to invest an awful lot of time and energy to be able to even be able to code something more than hello-world in c#, but then again I am not lambasting Mono for it's shortcommings -au contraire I thank the Mono team and devs for their work.

From the vantage point of those who wish to see Mono as a purely multi-platform framework surely many are greatly disappointed in Mono. But Mono is an alternative implementation of .Net which at once is custom-tailored to both Linux (via Gtk#) and Mac (via cocoa#) and which on these platform provides very "native" applications(at least this is true for Linux and probably to a lesser extent for Mac-I don't have a Mac so I can't say much about the degree of Mono's success in making itself "native" on Mac) AND at the same time Mono is generic enough to make it cross-platform for a wide range of apps (server(Second Life) and client) on a trully impressive range of platforms (Wii, iphone, Android, Maemo etc.). You could fault them for trying to much, but not for not trying hard enough.

Some key points about Mono that I'll pull from from their FAQ to clear some misconceptions:

What is Mono™ exactly?

The Mono Project is an open development initiative sponsored by Novell to develop an open source, UNIX version of the Microsoft .NET development platform. Its objective is to enable UNIX developers to build and deploy cross-platform .NET Applications. The project implements various technologies developed by Microsoft that have now been submitted to the ECMA for standardization.

What is the difference between Mono and the .NET Initiative?

The ".NET Initiative" is a somewhat nebulous company-wide effort by Microsoft, one part of which is a cross-platform development framework. Mono is an implementation of the development framework, but not an implementation of anything else related to the .NET Initiative, such as Passport or software-as-a-service.

Aren't you just copying someone else's work?

We are interested in providing the best tools for programmers to develop applications for Free Operating Systems. We also want to help provide the interoperability that will allow those systems to fit in with other standards. For more background, read the Mono Project white paper.

I suspect that the decision against SWF had a bunch of factors. I think Mainsoft and the agreements between Mainsoft and Mono probably played a role in this. It is also possible that there were more patent concerns in this area and that MS had told them not to pursue this. And Miguel and his team have been privy to the planning of .Net far beyond what most .Net devs are and may have seen SWF as being but a short-lived tech which Microsoft itself would be leaving behind( I am not a .Net coder and no remarkably little about all the ins and outs but wasn't Avalon supposed to superced SWF ?-could be totally wrong but IIRC Miguel even mentioned this 2-3 years ago). At any rate I sill question the extent to which Mono could have created a multi-platform GUI which would not have been subject to derision by those who lament platform-specific integration. Java is only now becomming viable in this regard -people have bitched and moaned about Java being alien everywhere for so long-Java was practically forked for SWT to address this issue. Toolkits like Wx have only succeeded in addressing this issue to the extent that they have been successful and from my POV that success has been marginal. Qt seems to have the best cross-platform support-but there are issues there as well (licensing, costs, c++).

The #WT I mentioned earlier is a derivative of SWT. It did not require development completely from scratch.
If you have tracked the evolution of GUI toolkits, you may have noticed they have over time matured to fit in with the platform. Qt in its earlier incarnations was out of placed outside of Windows. But over time it has made design improvements and adapt itself even to GTK/GNOME L&F to better integrate with the DE. Qt has also improved so much on the Mac that an end-user of ours was hard pressed to weed it out as a non-Cocoa/Carbon app.
We've had the same experience with SWT. There is even a port of SWT underway for Cocoa64. Win64 support has been around for a long time.
While I agree there are GUI toolkit/frameworks that still have long ways to go (GTK on Windows/Mac and Swing on Windows), there are mature technologies to derive from.

As regards the exe/dll: I simply do not see this as being such a big issue. Firstly I suspect if Mono was ever to reach the point that people considered Mono before considering .Net (ie. Mono became the standard) that this could be changed-perhaps it should-but not when the number of Mono developers is dwarfed 100 to 1 by .Net developers. Secondly I have no clue as to what would be involved in creating a format which ran natively (ie. without ilrun and other mechanisms)-is such even doable? Now making Mono target ELF for Linux apps would make a lot of sense-but I suspect that lot of Mono development still takes place in MS Visual Studio-perhaps this plays a role in this decision-I really don't know-but you know I have never cringed seeing a dll file in my file system, and I have not gotten a rash due to seeing exe files. Mono apps are usually started with a bash script -big friggin deal-do you *really* care so much about whether Linux can make use of the RES chunk of the exe/dll file? I just don't get why this is a *deal-breaker*.

I am not disgusted by the sight of EXE/DLL, though I've had Linux admins that were confused that I sent them a Windows program for testing because of the EXE/DLL.

I was trying to point out that Mono applications could benefit more from native formats. For example, standard system tools like ldd are especially beneficial in cases where trouble shooting runtime dependencies are needed. This is doable just not done currently. Under Windows the Dependency Viewer provides similar functionality for Win32/Win64 native binaries. This includes .Net apps and assemblies as well. Using ldd in this manner could not happen under Linux unless the ELF binary is used.

I guess my last question is this: you seem to be quite competent in .Net programming- what is preventing *you* from offering your skills to implement the things you so wish to see ? I am not currently an active programmer and I would need to invest an awful lot of time and energy to be able to even be able to code something more than hello-world in c#, but then again I am not lambasting Mono for it's shortcommings -au contraire I thank the Mono team and devs for their work

From past experiences in OSS projects, I've learnt that it is key for a project to have firm supporters and stick with a clear goal. #WT was one of the biggest disappointment for me personally as I saw my contributions fall to wayside and the direction the Mono folks took instead. The original SharpDevelop team that sparked of #WT decided it was best to lay the project to rest and instead focus on consuming S.W.F. Lessons were learnt and I moved on to alternatives.