Become a fan of Slashdot on Facebook


Forgot your password?

New Mono 1.2 Now Supports WinForms 304

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."
This discussion has been archived. No new comments can be posted.

New Mono 1.2 Now Supports WinForms

Comments Filter:
  • Re:Indeed. (Score:3, Informative)

    by Shados ( 741919 ) on Friday November 10, 2006 @06:31PM (#16799648)
    Ok, before someone wacks me with a stick. Seems like Mono after all does have partial .NET 2 features. They should be careful though...I see on their roadmap ASP.NET 2.0... while C# and such are under ECMA standards (I beleive), ASP.NET technologies are partially patented and not given out as a standard for anyone to play with. Playing with fire there.
  • by Anonymous Coward on Friday November 10, 2006 @06:35PM (#16799694)
    Could patents be used to completely disable Mono?

    First some background information.

    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.

    Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms.

    The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI, or for example as an embedded runtime in Apache).

    The core of the .NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent): 218.html [].

    Basically a grant is given to anyone who want to implement those components for free and for any purpose.

    The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. Those are convenient for people who need full compatibility with the Windows platform, but are not required for the open source Mono platform, nor integration with today's Mono's rich support of Linux.

    The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.

    Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.

    The patents do not apply in countries where software patents are not allowed.

    For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration.

    With the new Novell/Microsoft agreement, will the patent policy change?

    Mono is a community project, and as such, we will continue to implement the policy of not integrating knowingly infringing code into Mono.

    And we will continue to follow the steps outlined in the previous topic if code that potentially infringes is found: finding prior art, finding different implementation techniques, or if none of those are possible, removing the code from Mono.
  • Re:Very good! (Score:2, Informative)

    by SanityInAnarchy ( 655584 ) <> on Friday November 10, 2006 @06:57PM (#16799900) Journal

    "Windows Forums"?

    You know, this has been my major concern with Mono -- moronic Visual Basic programmers migrating to Linux. And if spelling isn't enough:

    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.

    Most software I use can be compiled with very little modification between Linux or OS X (using X11). I'm a Linux developer and I rarely touch kernel code, and then, only for fun. We have a local radio station that's running entirely on Ubuntu, without touching the kernel.

    Implying that Linux development requires kernel hacking is worse than moronic -- it's infectiously moronic. You're spreading FUD, intentionally or not.

    And may I ask, what is it that's stopped you from doing exactly what you described, but with Java instead of Mono/.NET?

    Oh well, there's always the decent stuff: Beagle.

  • by kelk1 ( 660671 ) on Friday November 10, 2006 @07:18PM (#16800120)
    From mono 1.20 release notes:

    ADO.NET, ASP.NET, System.Configuration, and Windows.Forms only contain partial support for 2.0 APIs, full support will only be available in Mono 2.0.

    How partial is that support?

    First try:

    $ mono Test.exe

    ** (Test.exe:6411): WARNING **: Missing method System.Windows.Forms.ToolStripItem::set_ImageTrans parentColor(Color) in assembly /usr/lib/mono/gac/System.Windows.Forms/ 7a5c561934e089/System.Windows.Forms.dll, referenced in assembly /path/to/Test.exe

    Unhandled Exception: System.MissingMethodException: Method not found: 'System.Windows.Forms.ToolStripItem.set_ImageTrans parentColor'.
        at kk1.Test.Test..ctor () [0x00000]
        at (wrapper remoting-invoke-with-check) kk1.Test.Test:.ctor ()
        at kk1.Test.Program.Main () [0x00000]

    Second try:

    $ mono /mnt/win/Program\ Files/kk1/anotherprog.exe
    Segmentation fault (core dumped)

    So it seems that the header should really be "Mono now PARTIALLY supports WinForms".

    Appropriately enough, the confirmation word is "roughly"
  • by Shados ( 741919 ) on Friday November 10, 2006 @07:52PM (#16800478)
    legacy ASP can run on Linux using third party tools. However, Mono, as far as I can tell, is unrelated to it. ASP and ASP.NET are about as close to each other as Java is to Javascript.
  • by Ash-Fox ( 726320 ) on Friday November 10, 2006 @07:57PM (#16800540) Journal
    It uses less memory than Mono and has very mature gui compoenents in swing and awt that just work across platforms.
    I still have problems with awt under Mac OS X's Java framework. So many years and still the same problems exist.

    I don't care if the code is aged, I want it to work.
  • by Tony ( 765 ) on Friday November 10, 2006 @07:58PM (#16800552) Journal
    Don't get me started on java, the most resource hungry platform I've ever seen in my life.

    You obviously haven't used .Net, then, nor Mono, which is worse.

    Java is a tiny little resource-miser compared to .Net, and Mono is worse than .Net for resources.

    But you are right. Java is no slim jim compared to even C++ or Objective-C, let alone pure C.

  • by oohshiny ( 998054 ) on Friday November 10, 2006 @07:59PM (#16800568)
    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.
  • Re:Sharp Develop (Score:5, Informative)

    by miguel ( 7116 ) on Friday November 10, 2006 @08:20PM (#16800716) Homepage
    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.
  • by miguel ( 7116 ) on Friday November 10, 2006 @08:23PM (#16800750) Homepage
    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/ 7a5c561934e089/System.Windows.Forms.dll, referenced in assembly /path/to/Test.exe

  • by metamatic ( 202216 ) on Friday November 10, 2006 @09:48PM (#16801568) Homepage Journal
    The benchmarks at the shootout [] suggest otherwise. C# and Mono beats Java for memory usage in just about every case, usually by a factor of 2.

    I program in Java and wouldn't touch Mono with a 10' pole, but Java really is a bloated pig at runtime.
  • Purging Mono (Score:3, Informative)

    by metamatic ( 202216 ) on Friday November 10, 2006 @09:51PM (#16801602) Homepage Journal
    There's basically no way to remove Mono from SLES without breaking YaST2... or at least, breaking it more than it is anyway, ho hum.

    I dislike the situation too, but since the software I need to run on some servers only works on SLES or RHEL, I don't have many options. I certainly wouldn't run SuSE otherwise.

    You can remove Mono from Ubuntu fairly easily, and I do. apt-get --purge remove mono-common will do the trick. You lose a couple of GNOME applications. I expect GNOME to become more infected in future releases following the Microsoft/Novell deal, in which case I'll probably go back to KDE.
  • Why not Java indeed! (Score:3, Informative)

    by Latent Heat ( 558884 ) on Friday November 10, 2006 @09:52PM (#16801610)
    My requirements for leaving Win32 and GDI are 1) hardware-assisted scrolling, 2) fast blit of memory frame buffer where I can set the pixels, and 3) vertical sync-locked screen updates. Java Swing can do 1) with Graphics.copyArea(), 2) with BufferedImage, VolatileImage, and while Swing only offers BufferStrategy on full-screen Windows, I have written a Linux-X11-OpenGLX vertical sync checker and access it with JNI. Furthermore, the heretofore pokey horizontal scrolls and partial screen updates in X11 are now hardware accelerated using OpenGL in Linux Java 1.5. These Win32 capabilities (ScrollWindowEx(), CreateDIBSection(), IDirectDraw::WaitforVerticalRetrace()) that got removed, crippled, or marked as "unsafe code" in WinForms are available in Java and portable between Windows and Linux. Now that Sun is claiming to be open-sourcing the Java VM, and WinForms is supposed to get replaced by who-knows-what-Aero-in-Vista, and Netbeans has a GUI form designer indistinguishable from VB, I say why not Java indeed!
  • Re:So what? (Score:3, Informative)

    by EvanED ( 569694 ) <[moc.liamg] [ta] [denave]> on Friday November 10, 2006 @09:55PM (#16801632)
    Java will have those incorporated in short order, i'm sure.

    The point is that, IMO, Java trails .Net in terms of design. I know of nothing that I would consider an advantage in language design to Java over C#, and many advantages to C#. Some are at the level of syntactic sugar (like properties or operator overloading), some are much deeper (like delegates).

    Getter/Setter methods are easy to generate and offer the exact same functionality.

    At the cost of (arguably) reduced readability in many cases.
  • Re:So what? (Score:4, Informative)

    by aled ( 228417 ) on Friday November 10, 2006 @11:44PM (#16802350)
    Java (much like Flash) is being horribly misused. It is not meant for every other fancy visual GUI application and, hopefully, it never will be.

    FUD. There are some good graphical java apps. Look at Swing Sighting [] for examples.
    Azureus is a well known app on SWT.

    It lacks support of DLLs (or other such libraries)

    More FUD. You can use JNI api to make native calls, thought it is not automatic like calling a DLL from Visual Basic. You have to code the calls in C/C++.

    the chances of seeing a Java application whose GUI actually blends in the slightest with the OS upon which it runs are slim to none

    FUDfest. Java 6 will have some desktop support. Apple had a Java implementations that blends with its desktop very well for years (I haven't seen this myself).

    and of course: it is slow

    That is like open the gates of flames. Slow in which context, on which hardware, what app, what the load, to what are you comparing?

    I could go on about how JRE annoys the heck out of me; For example, I couldn't properly uninstall an old version of Eclipse because it wanted an extremely old version of JRE (?!!).

    What do you mean? Eclipse is distributed as a zip on Windows. Doesn't even has an installer. You just unzip to install, and delete the dir to uninstall.

    For text-based cataloguing stuff, simple little GUIs and extremely cross-platform software, Java is truly a wonderful thing. I'm not saying it's bad; I'm just saying it's misused.

    You seem to not know that the most use of Java is actually in server side apps, like web apps, web services, enterprise server... and mobile phones of course.
  • Re:So what? (Score:2, Informative)

    by MassacrE ( 763 ) on Saturday November 11, 2006 @12:19AM (#16802534)
    In practice, the object typedness of java enumerators does not make up for the them being harder to map into native code (C enumerators and C# enumerators are almost identical) and being unable to be used as flags.

    Also in practice, a Set provides nothing that a Map with only keys and null values provides other than reduced memory utilization. Since the CLR already reduces memory utilization vs. Java, this isn't really a Java win.
  • Re:So what? (Score:4, Informative)

    by EvanED ( 569694 ) <[moc.liamg] [ta] [denave]> on Saturday November 11, 2006 @01:59AM (#16803018)
    ... 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)
  • by sveinungkv ( 793083 ) on Saturday November 11, 2006 @02:45AM (#16803186)

    You mean like this? []

  • Re:Very good! (Score:3, Informative)

    by pornflakes ( 945228 ) on Saturday November 11, 2006 @05:16AM (#16803662)
    Google Earth.
  • Re:So what? (Score:3, Informative)

    by baadger ( 764884 ) on Saturday November 11, 2006 @09:22AM (#16804676)
    GTK looks like whatever theme engine you apply to it. If it looks like crap it's because you have bad taste. If you mean it looks like crap from an API/programmer standpoint (C) then why not look into some bindings.

"For a male and female to live continuously together is... biologically speaking, an extremely unnatural condition." -- Robert Briffault