Slashdot Mirror
New Mono Roadmap, DotGNU 0.1 On CD
msh104 writes "The Mono project just released a nice status update for Mono. They also preview a roadmap for what the future will be like. It's quite nice to read if you want to find out if writing .Net programs for Linux will have a future for you. The Mono roadmap is available here." And gibbon writes "The DotGNU Project announced the availability of the DotGNU 0.1 CD-ROM release.
It runs on many platforms and the CD contains documentation, packages for GNU/Linux, FreeBSD and MS Windows.
It is now possible to use the base class libraries and XML. System.Windows.Forms and the web services are coming along well, too. The announcement contains more information and download links."
Even if the MS .Net API patent is granted, there are several reasons why it may be difficult or impossible for them to enforce it gainst Mono and DotGNU. For example, there is the matter of anti-trust law. Patent law says that when a patent is unenforcable because of anti-trust law, that makes the patent invalid. Of course Novell (for the Mono project) and the Free Software Foundation (for the DotGNU project) will have to prove this in court. Until this is done, Microsoft might be able to make hell hot for Novell, or Novell might feel forced to agree to some patent license from MS that makes Mono non-free. (Since DotGNU Portable.Net development is based outside the US where US patents have no legal force, DotGNU is much less vulnerable to bullying from MS.)
The ECMA-standard components of .NET alone (for which MS has promised royalty-free licensing of any patents they may get) do not give a useful platform. Most C# programs use non-ECMA class library components in essential ways.
How much the developers knew about Microsoft's MS's implementation is possibly relevant if MS claims contract violation (e.g. violation of some EULA clause) or copyright violation, but it is irrelevant in the IMO much more likely case of an attack based on patent claims.
The DotGNU project is 100% committed to making Windows.Forms mature. We're even offering significant cash prizes as an additional incentive to help move this forward as fast as possible.
If one can say that there are two successful component-software frameworks out there, they would have to be Java and ActiveX. Java is single-language and multi-platform, but multi-platform in that one is running the Java platform under all the different OS's. ActiveX is, unfortunately single platform (Windows), but it is really, truly, multi-language (besides Visual Basic, there is Delphi, C++/MFC, the scripting languages, Matlab, VS.NET hosts ActiveX controls quite well, thank you, and yes, even Java SWT that supports it in one form or another). It is multi-language in a sense that .NET isn't (really syntax skins over CLR-compatible languages).
With ActiveX, you have two things going on: pure COM objects and then ActiveX objects proper. COM is kind of like Mono/.NET without Windows.Forms, and ActiveX is like Windows.Forms. In fact, ActiveX support under .NET is integrated into Windows.Forms. COM is simple enough and clean enough that you could really have COM across platform. ActiveX tries mightily to hide it, but it really has the Windows handle and API behind it, and is the thing that ties you down to Windows.
Now Windows.Forms does have a clean, generic GUI API that could be ported to other systems, but on the other hand, it exposes both Window handle and displace context (DC). Not only that, all of the Longhorn revelations suggests that Microsoft plans to ditch Windows.Forms and move to something else.
Leaving out all the worries about patents and Microsoft behavior and all that, for Mono to succeed, it has to do more than just the COM part to .NET, it has to do an ActiveX-like part as well. As a Windows-constrained person, I see Windows.Forms as a waste of time because 1) ActiveX not only works with .NET quite well but it works with the legacy Windows stuff (VB 6 and all the sundry Web pages and scripting languages), and 2) it looks like Windows.Forms is going to be superceded by something else.
Windows.Forms components are only a little bit easier to use than ActiveX, and they are sure a heck of a lot easier to develop than ActiveX (don't get me started about IDispatch, QueryInterface, Automation data types, IDL, and type-library generation and maintenance). But for all its warts, ActiveX generated a whole lot of buzz. Matlab is cross platform, but the Windows version supports it. Data Translation supplies A/D card controller widgets in it. Eclipse Java-SWT supports it (again, only on Windows). Where's the buzz with Windows.Forms? Is Matlab rushing to come out with a version to host Windows.Forms widgets? Is Data Translation coming out with .NET native widgets for their A/D cards? Eclipse-SWT already supports Windows so it doesn't need to host Windows.Forms.
If I as a Windows developer think Windows.Forms is a waste of time (no future to putting a lot of work porting and polishing a GUI component library into Windows.Forms), perhaps Mono should invent its own GUI framework and try to beat MS to the punch regarding whatever MS has up its sleeve.
Windows.Forms does not have this big mass of reusable component software or people falling over themselves to make containers to host it, and I don't think it ever will -- it looks like a bride until Microsoft makes up its mind. If I could pick a direction, I would suggest cloning the Eclipse SWT API, and teaming up with the Eclipse people to agree on extension.
the DotGNU implementation of SWF is not "hacked". They just decided to write it on top of Xlib on non-windows platforms instead of going the mono route with wine being a dependency.
.NET binaries that rely on SWF on dotgnu in the near future, but you will be able to run DotGNU binaries using SWF on windows. Hopefully they'll get some theme support going so it looks native.
No, you won't be able to run
Two lies above:
* There were never any Windows.Forms cooperation plans. Each group has chosen a different implementation path.
* We never pulled Windows.Forms out of Mono, we continue to develop it.
Your conspiracy theory on the marketability of Gtk# is pure nonsense. We develop Gtk# to build Gnome applications, we have no choice if we want to leverage all the platform code available.
We develop Windows.Forms and other APIs to remain compatible with code that people develop on Windows, and move it to Linux. As simple as that: Mono is not only a great platform to create *new* software with Unix-isms, it is also a platform to enable the growth of Linux by bringing the Windows people over.
Miguel