Mono Progress In the Past Year

Eugenia writes "OSNews posted an article accounting the applications created in GTK# the past 8 months, since the release of Mono 1.0. While many of them are still in their infancy, it's clear that the platform had a healthy progress, with 'super-hits' like Tomboy, F-spot, MonoDevelop, Muine & Blam! and other, less known gems, like SportsTracker, PolarViewer, MooTag, GFax, GIB, Sonance and Bluefunk. The 2.0 version of Mono is expected around May, but the developers advised distros and users to upgrade to Mono 1.1.4 despite being a beta."

Beagle

[ultrabot]

Interestingly, the summary neglected to mention Beagle [gnomefiles.org], the one Mono application I actually plan on using and that has created some momentum for getting the Mono into various distros.

If Mono proves to be snappier than, say, Java, there might be some hope for it but the spectre of living under the mercy of MSFT is not easy to dodge. It's still there, however much people tried to not talk or think about it.

Re:Beagle

[Taladar]

This is why most smart people don't write open source software in Java nor in Mono.

Re:Is there a nice guide online to coding in Mono?

[Anonymous Coward]

1. Emerge monodevelop
2. Afaik there even is a plugin for Eclipse

From a mono developer..

[zbowling]

I just happen to be one of the few official developers for the mono project, just catching this artical early. Mono is quickly becoming better then ever. The biggest difference between Mono 1.0.x and Mono 1.1.x is the fact that our Just-In-Time compiler (or JIT) is getting more and more amazing every day. The 1.0.x series use a interprator capable of understanding things at the application start. One huge correction is that Mono will be called 1.2 in May not 2.0. While it is true that gtk-sharp-2.0 is moving to 2.0 from 1.0, the Mono runtime will remain at 1.2 as not to be confused with Microsoft.NET 2.0 (all though support for many of .NET 2.0 features will be included). Gtk# being based on Gtk+ 2.2 and Gtk# 2.0 being based on Gtk+ 2.4. Windows support is just as compatable with GTK# as it is on Linux, minus support for Gnome, VFS, GConf, GtkHtml 3 and DBus of course. Hope that helps!

Re:Question about GTK#

[zbowling]

GTK# works wonderful without even even being related to Mono in anyway. It runs under Microsoft.NET just as well as it does on Mono under windows.

My good friend Paco (Fransico Martieneze) has posted a installer for .NET SDK 1.1 and it includes documention for it and even some intergration with Visual Studio as well.

http://forge.novell.com/modules/xfmod/project/?g tk s-inst4win

Re:it's not reverse engineering

[idlake]

Those same applications will also run under Windows,

These are not .NET applications, they are Gtk+ applications written in C#. As a result, they don't run on Windows or .NET out of the box.

You can run them on Windows, but you can do that with lots of other Gnome and KDE apps as well.

Plus, they can sell MS Office.NET to Linux users too, as it can run on Linux.

I think this would be great for Linux. Unfortunately, Mono will likely never be compatible enough for that, and hell would freeze over before Microsoft would even contemplate such a thing.

Re:good

[grfpopl]

Wow, it's really too bad that people these days think that OO is about a language spec. It's not! OO is a design paradigm! (ugh. i hate that word, but that's what it is.) Your design is either OO or not OO, and the language that you implement it in is irrelevant. All that c++ does that c doesn't is do a few checks in the compiler. You can implement OO designs in C, Scheme, and plenty of other languages that don't have built-in checks for such things. (and yes, c++ does have a number of other features, but they are wholly unrelated to OO) OO doesn't fix buffer overflows either. Why would it? If you have crappy design/use the wrong functions for the wrong things, then you're going to end up with buffer overflows. C# goes quite a ways, as a language, to prevent this, but don't confuse it with OO.

Re:it's not reverse engineering

[Patoski]

I fear the day when Microsoft will come and snatch this out from under the Mono team,

There is nothing to "snatch": these are applications implemented in a non-Microsoft toolkit using an open language standard.

This isn't 100% accurate since there is also the issue of patents to consider. In order to implement some parts of the .NET standard there would be some "use" of MS patents (I'm talking about ASP.NET and ADO.NET in particular). MS has never said anything about letting people use these parts of .NET and could easily go after Mono over this issue. Even the Mono team acknowledges this as an issue [mono-project.com] but they promise they'll somehow code around the patent or they just won't implement parts of the standard. Certainly not an optimal solution.

I don't see how writing Gnome applications in C# benefits Microsoft any more than writing Gnome applications in C++ or Python.

MS gets to say that their solution (C#) is cross platform and usable on numerous platforms. In short, publicity.

Re:C# Rocks - go mono go.

[jdunn14]

If you're curious about that 64 client limit check out winnt.h and look for MAXIMUM_WAIT_OBJECTS (in mine it's on line 1354):
#define MAXIMUM_WAIT_OBJECTS 64 // Maximum number of wait objects

This is the limit on the number of objects that can be waited for in WaitForMultipleObjects calls. The same limit is enforced in winsock2 for select calls, I believe because in the end microsoft's select implementation is using WaitForMultipleObjects underneath. (Also note that the winnt.h header file is entirely too large for a single header (9170 lines), but hey, that's window's style for ya).

Re:C# is Better than Java(At least I think So)

[mattgreen]

This is slated for C# 2.0.

Re:Dashboard

[watchmaker1]

Dashboard was really just search, and is largely dead. The bones of Dashboard were used to build the framework for Beagle [gnome.org].

You can do dashboard and so much more with the functionality in Beagle. Any future Dashboard-like app would probably be from-scratch on top of a Beagle back end.

Re:Beagle

[LDoggg_]

Huh?
There are thousands of open source java projects.
Here's a few. [sourceforge.net]

Did you forget about wxNET?

[Spy der Mann]

These are not .NET applications, they are Gtk+ applications written in C#. As a result, they don't run on Windows or .NET out of the box.

That's because they keep thinking "Linux-only". It's not "I'm going to make a cross-platform app using C#", but "I like C#, I'll use it on Linux".

WAKE UP, GUYS!!!

If you want Mono apps to run in Windows, perhaps you should take a look at wx.NET [sourceforge.net].

From the link:

Cross-Platform, Multi-Runtime

Without any extra work on your part, your application will run on Linux, Mac OS X, and Windows using any of the following .NET runtimes: MS.NET, Mono [emphasis mine], or DotGNU Portable.NET.

Native UI, No Emulation

Unlike other toolkit approaches, wx.NET uses the native UI framework on each platform. Under Windows the WIN32 API is used to create buttons, checkboxes, etc. On Linux, GTK+ 2.0 is used (not really "native", but a look/feel users are familiar with). On the Mac, the full aqua look and feel is provided by using Quartz window compositing and HIView implementations for controls.

Other toolkits take the emulation route. This can cause look/feel inconsistencies to end users and slower executing interfaces.

(end of snip)

Take two very good cross-platform things (.NET/Mono, wxWidgets)... a powerful combination like this could jeopardize Microsoft's monopoly if you ask me. And that is always a good thing.

GoMono!

Re:From a mono developer..

[zbowling]

Well, there really isn't an issue.

IP issues have been solved a long time ago. While Microsoft didn't publicly comment on IP issues in Mono, the legal department at Novell feels that any action taken by Microsoft against mono would be in amazingly bad faith and for 90% of Mono would be impossible to impose.

The sections that were released under the EMCA filing are public and they will be ours forever. The issues that maybe questionable are parts that were not released on the EMCA but Microsoft has released the source for those under a shared common licence (very restrictive) but allow anyone to "learn" from them as long as the don't take anything tangable (copy and paste, rigth it down) so as much as you can remember while looking at it is yours. The even make the comment in the licence that its a almost needed tool for implimenting your own runtimes. Mono has a personal policy not except code from people who even looked at to avoid all chances of something slipping up in the mess.

Microsoft has communicated with us in the past on different things and we have communictated with them when we find a security flaw in the framework. They even use our code deep in the depths of Microsoft for regression tests (as much as I have heard) and the even demo with our software at conferences and online broadcasts on the power of the .NET Framework.

With all the positive support they have given towards it would be in bad interests to suddenly change on that and would be against anti-trust laws. We are also protected by the EMCA filling because it proves that Microsoft intented for .NET to be a standard and not propiatary. Any patent that Microsoft would try to file would be quickly shot down because of prior art clauses and the fact that Mono is mostly a wrapper (when it comes to the classes not the compiler or the runtime) for libraries that already exist in Linux (in most cases this is true) they would have to file against libraries that even Microsoft used as the basis for their products publicly.

I just don't see any issue. It was a consern when we started before we had time to investigate. :-)

Re:Driving developers to windows

[LnxAddct]

Fedora comes with gcj (gcc java compiler) and that compiles most swt and gnome applications jsut fine. Also there are a few very good open source JVMs, the first one off the top of my head is Blackdown, which I use to develop java3d on linux. I have yet to see blackdown not do something that Sun's can.
Regards,
Steve

Re:it's not reverse engineering

[idlake]

The catch is that C# and CLR are not open standards - they are just ECMA standards.

That is what an open standard is: something that is published by a recognized standards body and that anybody is free to implement.

Apparently it was a brilliant move by MSFT because now people will automatically believe CLR is somehow "open".

They believe that because it's true. .NET is not open, but ECMA C# is.

In fact, a while ago Novell was asking MSFT for a clear declaration that Mono does not infringe MSFT IP.

Yes, Novell did ask that. That question doesn't refer to ECMA C#, which is as open as any language standard, it refers to Mono's implementation of .NET.

It provides a hose that MSFT can step on to end the distribution of the appications.

Erroneous statements like that seem calculated to create unjustified fear, uncertainty, and doubt about C# in order to keep people from using it. ECMA C# is open. Microsoft can no more "step on its hose" than they can step on C++ or Python or Java (on which, incidentally, they may also hold related patents).

We should never become too dependent on Mono, or Java, or any other proprietary technology.

Mono is not proprietary technology: it's an open source project implementing a de-facto industry standard. As such, it is no different from Linux, for example. As such, Mono consists of two parts: a part that implements an open standard (ECMA C#), and a part that implements a proprietary set of APIs (the parts of .NET that are not in ECMA C#).

If you want to use purely open APIs, just use ECMA C# and Gtk# and don't use any of the non-standard .NET libraries that Mono happens to implement as well. That's what I do.

Re:C# is Better than Java(At least I think So)

[rabtech]

Funny story on that:

VB.NET originally supported this (different access on setter and getter) but since C# didn't support it they dropped it to be compatible... now that C# is gonna support it in the next version they are going back in and re-enabling the feature.

Why it wasn't in originally I don't know, it would seem to be an obvious feature.

Re:it's not reverse engineering

[lupus-slash]

Please tell us who whose people are so we can remove their code.
We don't decompile the MS libraries as a rule.

Re:it's not reverse engineering

[idlake]

This isn't 100% accurate since there is also the issue of patents to consider. In order to implement some parts of the .NET standard there would be some "use" of MS patents (I'm talking about ASP.NET and ADO.NET in particular)

Did you even bother to read what I wrote? These are mostly Gnome applications written in the C# language. They don't use ASP.NET or ADO.NET.

Even the Mono team acknowledges this as an issue but they promise they'll somehow code around the patent or they just won't implement parts of the standard. Certainly not an optimal solution.

My point was and is: the non-standardized parts of .NET are a red herring because open source applications simply don't use them. That's what this list of applications shows.

The non-standardized parts of .NET are only an issue if you use Mono to deploy your Windows-based ASP.NET or ADO.NET applications on Linux. Your risk and exposure to Microsoft IP results from your choice of using ASP.NET and ADO.NET in the first place; the existence of Mono, if anything, reduces your risk and exposure somewhat, but, of course, it can't completely eliminate it.

MS gets to say that their solution (C#) is cross platform and usable on numerous platforms. In short, publicity.

Good for them: they let the language undergo standardization by an independent standards body, and now people are creating third party implementations of it for other platforms. That is as it should be.

Contrast that with Sun, which promised to standardize Java, and then pulled out of standardization processes twice when they discovered that those bodies had requirements for intellectual property disclosure and withdrew twice. Sun now falsely gives the impression that Java is an open standard and that the JCP is an open process, when neither is anything of the sort. That is not as it should be.

MonoDevelop 0.5.1 and Mono 1.1.4

[Anonymous Coward]

Unfortunately, the latest stable release of MonoDevelop will not compile against Mono 1.1.4. If you need an IDE for your Mono work, you would have to check out the Mono sources from SVN. The SVN version of Mono also has its dependencies, many of which also would have to be checked out of SVN repositories. So, while Mono 1.1.4 is available, for the time being, I have to stick with 1.0.6 in order to continue working within an IDE framework.

Re:it's not reverse engineering

[miguel]

I would be very suspicious about such contribution,
because most of the remoting code was written by
Lluis (for all the high-level channels), Dietmar
(for all the low-level remoting bits), Patrik
(which filled a lot of the mid-level details).

All I can think of are stubs, which are not really
useful.

Those were either Novell/Ximian/Intel employees,
and in no case we did disassemble.

For the other pieces like Soap/Remoting, the code
was so broken that it could not have possibly
been copied/decompiled given how useless it was
until we fixed it in various iterations.

I very much doubt your statement, but if it
happens to be true, we have records for each
contribution going to the day zero of the
project and we can track it down.

Miguel.

Live Code Examples for Mono

[__aabjlj9081]

Zamples provides a facility for live code examples for C# [zamples.com] and and VB.NET [zamples.com] using Mono. Novell (sponsor of the Mono project) was kind enough to publish a news brief [novell.com] about us last month. Zamples [zamples.com] also provides a live code facility for Perl, Python, Java, Ruby, Haskell and various APIs. Learning by example is a fast way to learn, and Zamples is a good way for authors and software publishers to present their information interactively.

Disclaimer: I am the founder of Zamples, Inc. Go gently on our servers, they probably won't survive being slashdotted!

Re:it's not reverse engineering

[miguel]

Thanks for looking into this.

We are auditing the code, and the code that we have
in that area was either completely redone, or what
has not been redone is fairly broken.

I would be surprised if the implementation is
copied.

But if they decompiled to learn how it worked, we
will remove the code anyways.

Miguel.

Re:Mono Sucks!

[lupus-slash]

There are issues running Mono on FreeBSD because FreeBSD has broken thread libs. Some of the fixes are in the latests 5.x releases, but there may be still more issues.

Re:Did you forget about wxNET?

[Abcd1234]

Sounds like XUL, XAML, the Glade XML format, or Renaissance (an OpenStep GUI builder) to me... you express the GUI in some logical fashion, and ask the underlying OS toolkit (whatever that is... Gtk, KDE, etc) to render it.

Re:Which bit of Java isn't open ?

[Anonymous Coward]

Dude, you can join the JCP 20 times in a row, if it makes you feel better, it still doesn't give you any say in what goes in and out of Java 6. That works via expert committees, and these work via invitation only.

The general JCP membership can vote in a bunch of elections, and gets to see some drafts a bit earlier than the general public, and *that's about it*.

cheers,
dalibor topic,
Kaffe dev