New Mono 1.2 Now Supports WinForms

smbarbour writes "The Mono project (the open-source .NET compatibility library acquired by Novell when Ximian was purchased) has released version 1.2. They are now including support for WinForms. Ars Technica has a detailed rundown on the new release. The Mono project supports Visual Basic.NET as well, so developers that use VB.NET now have the possibility of directly porting applications to Linux." From the article: "Relatively high memory consumption and performance bottlenecks are commonly perceived as being amongst Mono's most significant weaknesses. Some critics frequently refer to various performance issues to support arguments against broader adoption of Mono technology in open source projects, most notably within the GNOME community. The performance improvements in Mono 1.2 could potentially address such criticisms, but it is likely that a lot more work will be required before the problems are completely resolved."

Comments

Very good!

[Orion Blastar]

I want to be able to develop applications in both Windows and Linux. VS.Net and Mono allow me to use the same code with very little tweaking between platforms and keep using my Visual BASIC skills I learned over a decade ago.

Windows Forums means I don't have to rewrite part of the program that uses forms for Linux.

I hope this gets more VS.Net developers porting over to Linux using Mono. Linux can really use more easy to use and easy to develop applications without having to learn kernel hacking and methods that exist only for Linux. This is a good thing and maybe the corporations will decide to have some Linux workstations if they can develop VB.Net applications for them the same way they develop them for Windows.

Indeed.

[Shados]

This is a pretty cool project, and its coming along nicely. I really want to see it succeed, because that would allow me to spread my skills to a wider array of customers. Unfortunately, in its current state, MONO is only a partial implementation of .NET 1. And honestly: .NET 1 was garbage, and the vast majority of software that had the unfortunate badluck of being developped under it have been upgraded to the excellent .NET 2 by now (it is rare that apps get updated that quickly, for example between different java version.).

And now with .NET 3 out (which is only an extension of .NET 2, not an actual new version of the framework...dumbass marketing idiots at microsoft), .NET 2 is even more important.

Re:Great, even more ways for MS to kill it

[segedunum]

The .NET Framework is divided in two parts: the ECMA/ISO covered technologies and the other technologies developed on top of it like ADO.NET, ASP.NET and Windows.Forms.

NO. Microsoft has made it abundantly clear that when you implement the the ECMA stuff, and your own CLR, you are entering into a RAND agreement with Microsoft, and they have patents essential to the running of it:

http://techupdate.zdnet.com/techupdate/stories/mai n/0,14179,2887217,00.html

This was pointed out years ago. No, how long does this agreement last? The answer is, as long as Microsoft wants it to. Should Microsoft revoke this agreement, or initiate a revocation, then the worst that will happen is that the ECMA standards will be revoked. The ECMA wording on this is pathetically weak and under no circumstances gives a legally binding long-term guarantee. This is why we had all that rubbish about a 'letter from Microsoft' that didn't materialise some time back:

http://www.ecma-international.org/memento/codeofco nduct.htm

The whole 'ECMA is safe' thing is what the Mono people would have you believe. It isn't. The RAND stuff is double speak, because Microsoft do have patents that are specific to implementing .Net, CLR, the ECMA stuff etc. Not Java or anything else - just .Net. The e-mail quoted above basically means nothing.

It's actually more likely that the Microsoft specific stuff like ADO.Net, ASP.Net and Windows.Forms are safer since these are only namespaces in an API, although their patents basically say that if you're implementing .Net stuff and running it in a CLR then it applies. Fairly clever actually. They're saying that if you want to implement some of the stuff in a JVM or something, then that's OK, but if you're cloning a Microsoft compatible .Net then it applies to you.