Slashdot Mirror
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."
So now not only do we have to wait for submarine patents on C# and the runtime, now they can hit us on anything in their API as well. Especially with the Novell deal, people ought to realize that MS is just waiting for a chance to use their patents against open source. This is turning a bad idea worse. Just say no to Mono.
I still have more fans than freaks. WTF is wrong with you people?
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.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
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.).
.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.
And now with
One of the major points of the .NET framework is having multiple languages being able to compile to same bytecode. The implementation of Mono or .NET has nothing to do with which high-level languages utilize it, therefore dumping VB.NET over C# doesn't buy you anything. In fact, having more languages to choose from encourages development using Mono...and if you don't like VB or C# or managed C++, you can make your own language, as long as it can be described by the semantics of the CLR.
It uses less memory than Mono
I get a 22M RSS (280M total) for a Java application showing a single JButton in a JFrame; I get 7M RSS (22M total) for the same Gtk# application.
and has very mature gui compoenents in swing and awt that just work across platforms.
When I run a Swing application with Gtk LAF on my Linux box using Sun Java 5, it fails to pick up the Gtk theme I'm using, the menu buttons disappear when I click on them (because foreground/background seem to fail to pick up the right colors) and the menu shortcuts use the wrong font and wrong text. And that's just for starters. There is nothing "mature" about Java 5 on Linux, nor does it work in any form.
Java has its place in the world, and so does Mono, and they largely don't overlap.
SharpDevelop currently uses Windows.Forms 2.0, which Mono currently does not support.
We will start work on Winforms 2.0 soon, SharpDevelop should work when Mono 2.0 comes out.
The Winforms application that you tried to run is a 2.0 Winforms application, as the error reports: /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b7 7a5c561934e089/System.Windows.Forms.dll, referenced in assembly /path/to/Test.exe
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:
It doesn't matter what Microsoft "makes clear", they are simply spreading FUD, and so are you. You don't enter into agreements by implementing a public standard. You may be infringing on their patents, but given the vast amount of prior art, it seems unlikely that Mono is infringing on any claim that would hold up. And Microsoft's statement of terms may not be satisfying, but a court would take it into account if there ever were a lawsuit.
And what's the alternative? Sun has many patents on Java, has actively defended their intellectual property against FOSS projects, and open source implementations need to implement the entire Java platform in order to be useful.
Mono, in contrast, is a separate implementation, under an open source license, based largely on its own APIs and libraries. Also, Microsoft's patents have been scrutinized in detail.
The situation may not be very satisfying, but for anybody wanting something faster than Python and higher level than C++, the choices come down to Java and C#. Technically, I think C# is superior, and at least for now, the legal situation surrounding it is also better than Java.
... Yeah ... I am afraid we don't quite see eye to eye on this one.
;-)
I do think the former is easier to read. It's not a big difference, but it's still easier.
I also think that a + b is easier to read than a.add(b). If there were a language that didn't support = operators at all, even for primitives, what would you think of it? Just as easy to read as if you went through and changed a.set(b) to a=b everywhere?
The other advantage I see properties having is the following: they let you use standard fields and later change them to be properties without changing any other code. Direct language support. If you want to be able to change representations, do extra processing, everything that using accessor methods gets you in Java, you either need to write it with setters and getters right from the start (and have corresponding code blowup... you're essentially writing the same thing three times; if Java had macros I would regularily use something like #define SG_FIELD(type, name) type name; void set##name(type new##name) { name = new##name; } type get##name() { return name; } to avoid the nonsense of writing the same thing over and over and freaking over again) or you need to use a tool that will automatically refactor the uses of a field to use setters and getters. Incidentally, Eclipse provides such a tool. Eclipse is a wonderful IDE, and was the reason that the work I did with Java a while ago was one of the more plesant programming experiences I've had despite (as you might be able to tell) being a fairly-big anti-fan of Java.
The issue of delegates I agree with to some degree, as it is nice syntactic sugar, but one that is, again, easily done equivalently well through the use of listener interfaces
Not always "easily". If you use interfaces, you have to use the function name provided, you can't give an arbitrary "call this function" construct. You can get around this with inner (and perhaps anonymous) classes, but at the expense of quite a bit more code.
It's Java's lack of delegates that is the reason that they need the nonsense like "you can subclass Thread or implement Runnable", "subclass WindowAdapter or implement WindowListener (oh, which BTW you'll have to implement all 10 methods even if you're only interested in one)", etc.
And, while I am at it - C#'s lack of a "throws" clause on functions is just as annoying.
I'll grant this one to you. Personally, I don't know where I stand with regards to checked exceptions. I'll agree that it can be nice in certain cases, but at the same time, it can be a big pain in the butt in others. One of my friends is doing a class project where they're looking at extending the Java language with something (I don't know exactly what they're doing, but it's something that relates to ensuring that cleanup code is run), and was telling me about a project that someone else worked on where they did a compromise. Basically, they make functions that could be called cross-module (read: package) checked, so you had to declare all possible exceptions that could leave that code. However, private and protected methods do not have to declare the exceptions that could be thrown, so a change to what one function does doesn't necessarily propagate to a zillion others. This to me sounds like a very reasonable compromise.
Of course, then you have C++, where the exception specifications are perhaps the worst-designed feature of the "++" part.
Now, if you are purely in your own code this isn't absolutely terrible, as you can just start digging and figure it out. However, if you are using any microsoft stuff, or any third party dlls, you are pretty much screwed
Okay, third party tools I'll again give you some (maybe most) of the time, but MS stuff? It's documented in the API reference plain as day. It's far easier to find that out than it would be to go through your code! You could make the argument that you don't know for sure that's all you have to deal with, but considering that the MSDN documentation is second to none in terms of quality, I don't think you have much to worry about there.
(Though I'll point out that the Java extension I mentioned above would apparently go a long way to solving your qualms)