Slashdot Mirror
Mono Beta 2 Released
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."
Do we like this project, or hate it?
The mono C# compiler is a work of engineering genius.
It uses a program called TreeCC which goes beyond the Lex+Yacc model and provides an aspect-oriented tree programming model. This makes it very easy to write visitor patterns on your tree, and you can do syntax and semantic analysis with ease.
The resulting source code for a full working C# compiler is minute. TreeCC expands it into the real code.
Check it out!
It will be interesting to see what the performance comparisons of MSNET/MonoNET and MonoNet/LinJava. I would also like to see the CLI for Java project gain steam to take over some MS mkt share on the Winserver side (and allow seamless upgrades to Lin/Unix for those). Since C-pound is much like a C++/Java mutant it is not hard to transfer to the language.
I'm quite interested in seeing the first tools to take advantage of System.DirectoryServices, as this should enable us to manage a windows Active Directory natively from Linux.
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
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.
Does anyone know if M$ has gotten or is getting a patent for the way .NET works. If Mono is to close to something like that they could try and squash the whole project.
Evolution or ID?
I was under impression that mono has switched to a modern generational garbage collector, the Intel ORP GC. But the current beta uses the conservative boehm garbage collector.
A conservative GC is nice for a quick hack, but it really does not cut it for a modern VM.
So which one will it use in mono 1.0? Boehm or ORP? And if it is the boehm collector, what plans are there to switch to a modern GC?
By the way: the conservative garbage collector is the only real technical flaw of mono. Other than that it is quite a modern VM. Quite amazing for this short development time...
--
Private property is the central institution of a free society (David Friedman)
... let's see those windows.forms! By the release notes it sounds like progress is being made but they said what's shipping with 1.0 will be pre-alpha.
LilMikey.com... I'll stop doing it when you sto
Ive seen MonoDevelop and SharpDevelop and am not impressed with either. The day Novell is able to churn out an IDE like VS.NET for MONO is when Mono will be really able to make waves.
Read this
But... it this something that is a serious effort, or is it just an "If Microsoft can do it, Open Source can do it better" thing? Is there really a need / purpose / use for this other then to "one-up" the hated M$?
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
I agree that building on top of Wine is far from
ideal, but it has some benefits. For instance
we are able to support applications that want
to embed IE, or use Direct3D.
Miguel.
Miguel, have you guys been significantly more efficient developing MonoDevelop in C# using the Mono class libraries than you were writing Evolution in C? In other words, is all the work that has gone into Mono worth it in terms of application development?
I am biased, but I would say yes, we are more
efficient.
That being said, I recommend you ask the question
to third parties that are using Mono/Gtk#: gfax,
beagle/dashboard, MonoDevelop
That was the big showstopper and why my last project used java. Has it changed?
Additionally, Gnome GUI programming is much different, and SUPERIOUR to the Windows.Forms layout. Windows.Forms reflects that exactly, Windows. Absolutly positioned buttons, and loosely wrapped COM controls. GTK layout is vastly different, using theming engines, multilingual input methods, and automated layout and positioning. Additionally the font support in the Gnome stack can select glyphs from multiple fonts.
Windows.Forms is built for Windows... and thusly, running it under Wine is a perfect compromise.
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.
"Absolutly positioned buttons..."
... oh I wanna say Viewsonic, but I could be in error about which company it is. They were going to create a 300dpi LCD screen. The idea was that Longhorn would just get clearer and clearer as the resolution goes up, as opposed to the buttons getting smaller and smaller. I've seen interfaces made with Flash that do that. Fun stuff.
I'm looking forward to Longhorn's vector based UI. The static buttons problem goes away at that point. Within the last year or so, MS made a deal with
We got some cool stuff coming along in the next few years.
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.
I'm sure it is heresy to ask, but am I the only one who's confused by the Mono and DotGNU difference? I read the internetnews article, and the controversy is still pretty opaque. I don't use .NET, and don't have any imminent plans to do so, but if I did, why should I prefer one implementation over the other? Is it purely a religious issue?
To paraphrase Life of Brian: The only people we hate more than Microsoft are the f*ing Mono developers. Or the f*ing DotGNU developers. Take your pick.
Splitters!
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?
Is it just me or does Mono for linux sound like someone is trying to infect linux with a disease.
Rob
I have no arguments about your great work towards Mono on a technical basis.
.NET on Windows or having a 100% free gnu mono set like mingw on Windows with a free windows.form api?
.net.
I am worried with wine and about vendor lock in as well since the Windows version will always be better since MS would just set the standards. This is how MS beat Borland.
Have you ever thought about releasing gtk# to
THis might convince some developers to cross platform their apps rather then only focusing on Windows after standardizing on
I just get uncomfortable with all this Dcom, Direct3d, etc via wine since it would heavily favor Windows and keep the corps nervous about anything non MS.
http://saveie6.com/
Yeah, that's what I did for my project. From what I can tell, it's working, too - the libraries worked first time under Mono, and yet I still get to use the Windows I love. :-)
are the relevant ECMA standards 334 and 335 and just RAND, or are they really RAND and royalty free as miguel and others have claimed?
The standards are royalty free, however the standards only cover the CLR (the VM/JIT) and C# the language, not the Framework (all the classes that do stuff).
That's partially why the Mono folks are making two stacks -- the Microsoft-compatible stack, which may be patent encumbered (though Microsoft has never yet used a patent offensively); and the Mono stack, which isn't chained to Microsoft, and better supports Linux anyhow.
NO CARRIER
I too am fixing to being developing a new desktop gui app. I first thought 'Java' because I like cross platformness, however, working with Swing is a bitch. So, my idea so far is to take C#, develop on the logic and db access etc. in it (using the ado.net sqlite dll), slap it into a dll. All of a sudden all of brains of my app is crossplatform from Windows to Linux/OS X. Then, all one has todo is reference the dll and build a gui in Windows.Forms or GTK# etc. I will be doing a seperate gui in Windows.Forms and one in GTK# at a later date since windows support is needed first. The above solution would allow you to use Visual Studio to create apps that should run on mono without any problems (assuming you don't take advantage of any windows specific features in the logic dll).
Jisho - A Japanese English German Russian French Dictionary for the rest of us.
It's hard to guess what your issues might be - Java can supply either emulated cross-platform controls (via Swing) or native controls (via SWT). wxWidgets is a C++ library that supplies wrappers for native controls, although many other language bindings (Python, Java, JavaScript, Basic, etc.) are available.
I've used them both on open source projects, and while each has their own challanges, I've been quite happy with the results.
It sounds like you are dead-set on using the .NET framework with Mono - for reasons you haven't supplied - but simply want to avoid the Windows.Forms class. If that's the case, you might consider wx.NET. It provides just what the name implies - .NET assemblies to wxWidget controls.
Firstly, if you want to test Java for speed, use IBM's VM - it can be very much faster than Sun's.
Secondly, I just don't believe these results. Given equivalent code Java is usually quoted as being within 10%-20% of C++ speed (and IBM's VM is faster). I am highly suspicious that exactly equivalent code was not used. Was an Integer class implemented in C++?
Also, what about memory use? by default, the 1.4 VM allocates 64MB max heap. The test is allocating a million objects. I don't know how Integer is implemented, but if it involves even a few tens of bytes, there is going to be a lot of garbage collecting going on.
And I guess courtrooms are "churches", and lawyers are "priests" and cease'n'desists that force you to throw away most of the work you put into your business or software are "hymns".
.NET, I will use Windows (which I do for certain clients). Especially with Microsoft holding the patents.
Get real, how many SCOs does the world need until people realize THE LEGAL STUFF MATTERS for open source. The legal stuff is more important than the technical stuff.
RMS may seem like a wacko, but the FSF has had the right idea all along: contentrate on the licensing and legal details FIRST.
Mono may be interesting to some, but I'm just not going to depend on it. If I want
If Open Source starts winning more against Microsoft, these "religious" arguments will suddenly be viewed in a whole new light...
Maybe.
But it's even more like Microsoft was being practical.
If the toolkit doesn't map to the native widget set, not only does it tend to look crap, it also behaves wrongly (try bringing up a context menu in a GTK app ported to Windows and running on the second screen - the menu appears as an orphan on the primary screen). There are a thousand little things the emulation writers get wrong and don't even realise it.
A random collection of other things you miss with a non-native widget set:
- Things like system speech extensions usually don't work
- Screen movie capture systems do a sub-par job
- Remote desktop performance suffers
- Things like system themes and ClearType often don't work
This took me years of banging my head against Swing's crappy Windows L&F to understand - it looks perfect in a demo, but is filled with so many buglets it gives me a headache thinking about it. After switching to SWT I breathed a sigh of relief that at least I wouldn't have to apologise for things like menus popping up under the toolbar (or on the wrong screen).--- All I ask is a chance to prove that money can't make me happy.