Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mono Beta 2 Released

Posted by michael on from the copycat dept.

A little birdy writes "Less than a month after Beta 1 was released, Mono Beta 2 has been released. See the Release Notes, or go directly to the download page. It includes a C# compiler, an implementation of the Common Language Infrastructure and two stacks of APIs: a Unix, Linux, GNOME, Mono stack for APIs that takes the most advantage of your Unix server and desktop and a set of APIs compatible with the Microsoft .NET Framework 1.1 that provides support for ASP.NET (web services and web forms), ADO.NET and many other components." And in a related story: darthcamaro writes "The drive to develop a FOSS implementation of Microsoft's .NET framework by DotGNU and Novell's Mono project is being painted as a contest between the Free and Open Source communities in an article on internetnews.com. The article details the running argument between DotGNU's Norbert Bollow and Mono's Miguel de Icaza on the issues of commercial involvement, software patents and all the 'religious' stuff that the Free software community holds against the open source community."

5 of 289 comments (clear)

  1. Worthy Cause, but Huge Barriers to Entry by jacksonyee · · Score: 5, Interesting
    For Bollow, the decision to build a framework that is compatible with .NET is based on market reality. "In the industry, companies are using Microsoft stuff. The only way we can make it possible at acceptable cost to migrate to GNU/Linux is by making it possible for them to run their essential apps on both systems," he said. "My goal is to prevent Microsoft from catching the world in their .NET."

    I agree with Bollow's reasoning and reality, but I fear that his sentiments may fall far short of his dream. He'll have to cope with

    1. Trying to implement a moving standard as Microsoft continues to update libraries and APIs
    2. Dealing with any incompatibilities and bugs within Microsoft's .NET code
    3. Potential legal threats from miscellaneous things which Microsoft may choose to patent
    4. Acceptance from both Microsoft supporters and Linux supporters to convince both sides to use one common platform

    With that said, I think it's a very good idea to try to slowly nudge Microsoft developers over to other platforms, particularly if we come out with more advanced and/or convenient features than Microsoft's own standards. Nevertheless, time will tell whether this project pans out or not.

  2. Re:I'm an applications developer... by miguel · · Score: 5, Interesting

    Yes, we are not able to fully support the
    Windows.Forms API on the 1.0 timeframe (you can
    get the previews, but they are not ready to ship).

    Windows.Forms has a number of problems for
    open source software anyways: for instance, it
    does not do constraing-based layout, so for
    every language that you want to support, you must
    relayout your dialog boxes manually (or if you
    have a larger font size).

    By using Gtk# you take advantage of the Linux-specific
    APIs and Linux-specific features (you can use
    Gtk# on Windows, Linux and MacOS).

    On the other hand, there is a community of
    MacOS developers working on bindings to Cocoa
    bindings to give them the same flexibility and
    OS integration on the Mac.

    Windows.Forms would give you a Windows-solution
    everywhere.

    We are going to support it for the sake of helping
    Windows developers move to Unix, but it is not
    a particularly great toolkit.

    miguel.

  3. Re:What applications are there by miguel · · Score: 5, Interesting

    Hello,

    Part of the problem is that the Windows.Forms API
    exposes an entry point to hook up to the win32
    programming model the `WndProc' method override
    on Control.

    This is used to allow the developer to catch events
    and process events that Windows.Forms might not
    support directly with the managed API.

    Also, since the Windows.Forms and Drawing APIs
    are not comprehensive, developers of third-party
    controls often depend on calling into Win32
    calls (with P/Invokes). These are used for
    special effects or more complicated behavior than
    is available through the managed APIs.

    For instance, a common scenario is embedding
    the IE control and hook up to its DOM (see the
    cute Reflector from Lutz Roeder).

    Suboptimal, I know.

  4. No VB.NET support by Anonymous Coward · · Score: 5, Interesting
    I develop ASP.NET applications using VB.NET, and it's disappointing that the VB.NET development seems to be at a complete standstill. I've been tracking the mbas (Mono Basic) project since the beginning of the Mono project, and there's been virtually no activity on it. It appears to be the work of a single hacker in his non-existant spare time.

    Although the official reason that GnomeBasic was dropped was because of "stagnation", the real reason that it died was because Mono was supposed to take it's place.

    If that happened, I've seen no evidence of it.

    While you can write Mono code in Java, PHP, Logo, Oberon, Pascal, Forth and Lisp, VB is still unavailable.

    It's a pity such a popular language appears to be entirely ignored.

  5. Re:What applications are there by IamTheRealMike · · Score: 5, Interesting
    OK, so the fundamental issue here is one of toolkit quality.

    You said that if you don't use GTK# your app will run on Windows. This is wrong. GTK# apps can work on Windows, or MacOS X just fine.

    Understand this: the portability of an application is not defined by the type of machine (virtual or not) it's running on, it is by and large defined by the portability of the compilers and frameworks/libraries it relies upon.

    GTK+ is a portable widget toolkit, it works pretty well on Windows and MacOS. The Win32 widget toolkit is not very portable, mostly because the only open source implementation is the Wine implementation and Wine by policy only concentrates on application compatibility, not on having nice pretty widgets.

    So, if you are writing a .NET application you are best advised to use GTK# - this is true even if you are writing a program meant for Windows as in future if you wish to port things to another platform it will be a lot easier. There are a few other things to consider as well, such as the nicer API GTK has.

    As to the DotGNU approach vs the Mono approach, basically I think you'd have to be insane to want to reimplement what Wine has done. Nobody is going to use System.Windows.Forms on Linux because it blows goats, everybody will use GTK# or (maybe when it is mature) Qt# - therefore a SWF implementation is useful only for application compatibility.

    As to mapping S.W.F to Gnome/GTK, forget it. Back in the day (waaaaay back) Wine attempted to map the Win32 widget toolkit to Tk which was one of the better toolkits available back then. Didn't work. Widget toolkits differ too much to succesfully map between, and in particular the differential between a modern toolkit like GTK+ and Win32 is enormous - why do you think Microsoft are so keen to scrap it and start over with Avalon?