Slashdot Mirror

Well, use mono then

I just can't see Java overcoming C# once the latter takes off.

What about a free implementation of the C# language, virtual machine, and standard libraries?

Well, that would be sorta perfect for Ximian's mono! And if that "Liberty" thing is really open, what are the advantages of using Microsoft? People claimed that Mono was bad because it would force people into using passport - now if this Liberty thing works out, and somebody makes it work with Mono...

Great idea! :)

(i.e. selling support or t-shirts, etc. is not a solution)

Or is it that you're just morally opposed to paying for development of free software through support contracts?

Ximian will not be able to taken on the whole project on its own. Mono will be a free software/open source community project, that is the only way we can hope to implement something of this size. You can contribute to this effort.

Question 57: How can you expect Mono to compete with Microsoft, wont this require an effort too large?

You are right. Mono will never become a reality without the help of other contributors. Ximian is a small company that can not finish Mono alone. We will be working with members of the community to deliver the product.

And remain ignorant... From it's inception .NET by its definition is an open architecture... it is designed to be cross platform on the server and client side

Have we forgotten Mono by Ximian ?

ASP.NET is designed to function within any browser from Netscape 3.0 upwards... The core artchitecture of .NET is based on XML... which is about as open a standard as you will ever find.

So.... please tell me how is it someone developing on .NET may find themselves locked into a Gatesian world ?

As for waiting for a standards body.... the core architecture .NET platform is based on open standards much of which is administered by the W3C organisation.

As for the the moderator scoring these comments.... I guess your scoring method is based on 99% anti-MS sentiment, 0.5% for its intelligence and another 0.5% for how informed it is.

one already is

in fact, one such port seems to be coming along very nicely.

SourceForge (not SourceForge.net) is a collaborative software development platform.

SourceForge.net is a service provided freely to Open Source software development projects.

The new name SourceForge.net, and the logo with an enlarged dot and a "net" bigger in point size than the "FORGE", remind me too much of Microsoft .NET. Are you porting it to Mono or something? I would have called the code SourceForge Engine and the site SourceForge Projects in keeping with the general policy of following trademarks with a generic noun.

Microsoft compiles output from C# and J# to an intermediate code that is given, in turn to a JIT compiler. There is no virtual machine, but what the code is allowed to do is well defined (you can only make certain defined calls to a special environment. You can not self modify the code or execute data so calls outside the box are prevented.

There is no particular advantage to this approach as opposed to the JVM/JIT compiler combinations used for Java except that the execution environment is a lot friendlier to Windows type programs.

J# is just a way to lever Java code onto .NET, the same with COBOL# and FORTRAN#. As the C# language spec, the intermediate code and the execution envionmrnt spec is being passed to ECMA, I begin to feel more comfortable about this side of .NET (see also the Mono project). Hailstorm sucks big, but that is just BillG's normal attempt at world domination. The architecture doesn't need Hailstorm and some OS developers like what they see.

Of course, the reason behind .NET was to fight SUN, however, SUN openned themselves up to this by not properly opening up Java quickly enough. Frankly, SUN doesn't have the muscle to run the Java project by itself (having lived with the bleeding edge of Java betas, I see that). MS is no better but by giving it to ECMA, the standards are under public control/scrutiny so it is difficult for them to embrace/extend.

I think you are confused.

There are people working on C# compilers and runtimes for non-Windows platforms. Mono and Portable.NET are both working on the problem.

C# is actually a very good object oriented language. There is a complete type unification in C#. In C# structures and basic data types (like int, char, double) can be treated as objects with no hacks attached (I am not familiar with the Java hacks, but those who know claim that Java has some kind of difference between int and integer, or something like that).

C# is very much like Java, with a few extensions: properties, events, delegates and contains support for attributes (arbitrary metadata you can attach to language elements).
\

It may come from Microsoft, but much of the team behind it are Borland and just because MS is behind it isn't a kiss of death. Personally, I stopped getting religious about languages afer Algol was shoved down my throat at Uni. They all have their pluses and minuses. Java is under the thumb of Sun whereas MS want to get C# adopted by a standard's body. For me, that is a big plus.

A free C# compiler is in development now. It can't bootstrap itself yet, but it is getting there, however it is being built on Linux and should be out soonish. MS don't support the effort, of course but if they make a language public, it will get adopted. Miguel de Icaza, the lead developer of Mono doesn't seem to worry about MS.

People seem not to have noticed Ximian's rival project called Mono. It's a Good Thing they're doing there, imho - even if it is miles away from being a .net rival at the moment...

Mong.

I see things like this, and my first reaction is that it confirms my biases that Miguel de Icaza et al. have gone completely off their rocker by thinking that they can work with Microsoft and support .NET using Mono or anything else developed as true free or open source software.

Mono has nothing to do with .NET My Services a.k.a. Hailstorm. Miguel said as much when I interviewed him for Slashdot and the same thing is on the Mono FAQ page.

Mono is a development platform, .NET My Services are web services provided by Microsoft. What exactly makes you thing there is any relationship at all?

No, they just stole the graphics and ideas from Winamp. It's pretty much in the traditional of many, many, many open source projects.

Spotted this on the GNOME Weekly Summary:

Hello World in C# using the GTK toolkit :)
The syntax does look pretty clean.

It's not quite up to Java GNOME functionality yet, which is now compilable to native binaries, with gcc3 (For those of us who couldn't care less about platform independence but really like Java as a modern language). More choice is always good however.

And for the ten millionth time, Mono != .Net. .Net is an umbrella term for a whole slew of technologies, including the CLI, Passport, Hailstorm, and whatever else. Mono is a free implementation of the CLI (the virtual machine), the class libraries, and the compiler. Once that work is done, Mono should be generally useful regardless of what Microsoft does with .Net and its API. Granted, it will be more useful if Microsoft sticks to the standard they created and published... But I even recall reading an article somewhere where Miguel spoke of "embracing and extending" .Net! :)

We believe in writing as much code as possible in C# i
nstead of C, because we believe we can write more code, more robust code which in the end could be reusable as a components if we use C# instead of C for pieces like the compiler and its associated tools.

This seems to contradict what we have in our web page about the class-library. The class library is being built in a way that would allow the GUI toolkit to be plugged.

It is also plain FUD that we do not want to make Mono work with other desktops (hey, even GNOME works on other desktops).

You do not want to get a Gtk+ toolkit on MacOS, nor on Windows. You want to get a native interface, from http://www.go-mono.com/class-library.html:

For classes that might differ more (for example, the implementation of Windows.Forms), we might have different directories altogether:
System.Windows.Forms/Win32,
System.Windows.Forms/Gtk+ and
System.Windows.Forms/Cocoa.

You downloaded the runtime. The .NET classes are C#. The latest snapshot can be grabbed here.

Yes, it's subjective. I was stating my opinion of the platform.

They are using OO style programming in C to implement Mono for godsakes!

Actually, Mono is being implemented in C#. Download the code. In some cases, existing GNOME libraries will be used to implement specific parts of Mono such as the GUI elements or database access. The actual .NET classes themselves are being implemented in C#. Your point about OO programming in C seems orthogonal--Once you learn the semantics and conventions of OO programming in C, or any other language, it's not so strange looking. C++ was originally just a set of preprocessor macros built on top of C, e.g. But I digress...

You have a really slanted view of how free software in business works. There are two reasons (at least) why Ximian began the Mono project. The first is that Miguel, Nat, and some other folks looked carefully at the .NET development platform and found it be a very well architected software development platform for which there was no free software implementation. The second reason is that the .NET development platform is well-suited to the direction Ximian is moving in and will aid them in developing the next generation of their applications and services. Yes, of course they want developer support from outside the company. This is no secret. This has never been a secret of open source/free software business models. Bob Young of Red Hat fame has said on numerous occasions that a company as small as Red Hat could never produce an entire operating system, documentation, support, and everything else that is Red Hat. They harness the power of open source. Ximian is no exception. Most of the GNOME developers do not work for Ximian. Most of the .NET developers working on Mono do not work for Ximian. Most of the Linux kernel developers do not work for any Linux distribution company. So yes, Ximian wants involvement and they've gotten it, and they'll get more. Why? Because there are a lot of developers that have been using .NET or at least looking at the architecture, and want a free software implementation.

This gained support from the free software purists. Now Ximian is attempting to get free software coders on the Mono bandwagon by spewing crap about how technically superior it is.Compared to what, Miguel?

Compared to conventional means of developing software. Read the Mono FAQ

Nothing EXISTS that is comparable to this system.

Precisely. I couldn't have said it better myself, nor could Ximian marketing people. Nothing in itself is particularly innovative about .NET--what makes it interesting is how it all fits together. It's a good, clean development platform that allows for a whole lot of interoperability.

.NET is not vapourware. People who claim that .NET is vapour do not understand the .NET development platform or have a curious definition of vapourware. And the Mono project is a very real, though new project, to implement the .NET development platform as free software. If you check the mono mailing list archives (I can only assume you aren't currently on the list), you'll see how quickly the project has gained developers who have implemented over 230 classes in a remarkably short period of time.

How *much* do we have to read about Mono, a project that only exists in name and hype? If Mono is so good, shut up and show us the code.

okay: here it is.

There should be an anonymous CVS server available soon, too.

Assumption 1: Mono will have good performance

I am labeling this as an "assumption", because for some strange reason Mono's expected performance is not discussed here, even though there are multitudes of people consistently bashing Java for being slow.

Since the CLR is essentially identical to a Java VM in terms of high-level design, the execution of CLI code would be performed by using much the same approaches that are used for executing Java bytecode. If you look at Ximian's CLR implementation roadmap, you will see that it follows exactly the same path that the Java implementations took, except that it stops short before the last step -- runtime optimization. (Just to note that this last step is the most difficult one, but it is exactly what allowed Java to get close to C/C++ in terms of performance. JIT helps, but it simply does not cut it -- it is not enough).

Now, it took more than 5 years of intensive work for the JVMs to reach their current level of performance. How long will it take for Ximian's CLR impelementation to become fast enough and not be branded by the people on /. as slow? Obviously they can benefit from some of the Java work, but personally I feel that it would be very unlikely if that happens within less than 3 years. (although it would be nice if it did)

Assumption 2: .NET is standardized, so we can do multi-platform development

By now we all know that C# and the CLR have been submitted for ECMA standartization. What is important to realize is that while the C# language may be standardized, most of its libraries would not be. if you look at the list of libraries that are submitted for standartization, you can count 257 entities (classes, interfaces, delegates, etc.) defined in there. On the other hand, if you count the entities provided by the libraries in .NET beta1, and exclude the server-specific stuff, the OS-specific stuff, and even WinForms, you will get a number that is very close to 2000. So in effect Microsoft is standardizing at most 13% of the libraries it provides to Windows developers (the figure would be even lower if we include WinForms and other libs that might also be of interest).

What are the implications of this fact? The standardized libraries might allow OSS developers to build more extensive libraries base on pure CLI (w/o native code) and thus create an environment for multi-platform development. The suggestion to use the .NET libraries for this purpose, however, would fly in the face of everything that we have learned about Microsoft in the past -- as long as they have a monopoly, they will play games with the API, and will turn the whole endevour into a perpetual tail chasing.

It seems to me that Ximian do recognize this fact, but I am not very clear how they plan to counter the problem. In the article Nat said "I hope it doesn't happen" in reference to Microsoft changing the API, and that an open source version would "reduce the chance that Microsoft will be able to do that". If that is their strategy, well... good luck.

Assumption 3: You need .NET (Mono) to implement or use Web services

This is one of the reasons given in the article as to why Mono is necessary, and I am sorry to say this, but it is complete bull. The Web services that MS is advocating are based almost entirely on SOAP and XML, which are completely platform-agnostic and language-agnostic -- that's what MS has been touting as an advantage all along. You can communicate to a Web service using C and a set of SOAP libraries if you want to. If Ximian wanted to have a safe development environment to implement and use Web services, there is already a very mature one in existence that provides superb SOAP and XML support -- Java.

There is only one objective reason that I see for selecting .NET over Java, and it is not mentioned in the article at all: the CLR is designed to support multiple languages, unlike the JVM. The catch here is that the JVM already supports a hell of a lot of languages other than Java and that languages have to be bastardized to be used on the CLR, but still, I guess it does hold some marginal advantage.

Finally, as you can see above, the whole supposed licensing advantage of .NET vs. Java is a complete red herring. In fact, Java holds some practical advantages in that respect: In Java concrete specifications are provided not only the main libraries, but also for many optional ones. Changes in the Java API must be approved via a fairly democratic process as part of the Java Community Process, of which OSS groups such as the Apache foundation are also members, and is open to entry by others as well. All this has allowed a lot of implementations of the various Java libraries by a lot of independent vendors. Will this happen with .NET? Anyone willing to bet money on that one?

It is not the fault of any of you to do so, but it would be Petreley's duty to do a little research before writing from an uninformed point of view.

I remember I was once sitting in a panel with another famous pundit. The panel was on `Open Source' and they had brought the `experts' on Open Source to talk about it.

Such pundit said a minute before the panel begun to us `I do not see the difference between Peer to Perr and Open Source, to me they are the same thing'.

In Market speak .NET is a Microsoft-wide company initiative. To humans this means that a vision has been set at Microsoft, and every bit of the company is moving towards making that goal happen.

Now, this .NET "vision" encompasses many different areas, let me list some of them for you:

• The Development Platform.
• The Passport/Hailstorm Initiative.
• Their enterprise servers.
• Web Services in general.

People are confused between two elements: The development platform and Passport. People who claim that Mono is related to passport are making statements that are similar to `Excel is Turbo Pascal'.

The Mono Project is a project that Ximian has launched and is devoting resources to bring the benefits of a new, fresh and powerful development platform to Unix. Why we are doing this? Because we need those tools to bring you the next generation end-user applications. We could do this with C, C++ or Python, but it would take us longer, and we would waste our engineering time.

Passport is a completely different beast. Many people are confused, and asked me `How is Mono related to Passport'? The answer is: it is not related in any way. I have written a document that highlights the problems on Passport, you can get it here: http://www.go-mono.com/passport.html. This has nothing to do with Mono, but people are still confused.

Even worse, some people claim that `Mono will bring Passport to Linux'. Those people have not been paying attention. Passport is already available to be ran on Linux servers. Just go to http://www.passport.com, and download the Linux toolkit.

This bears repetition: Mono is not related to passport.

If you want to have an informed opinion on Mono, please read our FAQ: http://www.go-mono.com/faq.html

miguel.

It is not the fault of any of you to do so, but it would be Petreley's duty to do a little research before writing from an uninformed point of view.

I remember I was once sitting in a panel with another famous pundit. The panel was on `Open Source' and they had brought the `experts' on Open Source to talk about it.

Such pundit said a minute before the panel begun to us `I do not see the difference between Peer to Perr and Open Source, to me they are the same thing'.

In Market speak .NET is a Microsoft-wide company initiative. To humans this means that a vision has been set at Microsoft, and every bit of the company is moving towards making that goal happen.

Now, this .NET "vision" encompasses many different areas, let me list some of them for you:

• The Development Platform.
• The Passport/Hailstorm Initiative.
• Their enterprise servers.
• Web Services in general.

People are confused between two elements: The development platform and Passport. People who claim that Mono is related to passport are making statements that are similar to `Excel is Turbo Pascal'.

The Mono Project is a project that Ximian has launched and is devoting resources to bring the benefits of a new, fresh and powerful development platform to Unix. Why we are doing this? Because we need those tools to bring you the next generation end-user applications. We could do this with C, C++ or Python, but it would take us longer, and we would waste our engineering time.

Passport is a completely different beast. Many people are confused, and asked me `How is Mono related to Passport'? The answer is: it is not related in any way. I have written a document that highlights the problems on Passport, you can get it here: http://www.go-mono.com/passport.html. This has nothing to do with Mono, but people are still confused.

Even worse, some people claim that `Mono will bring Passport to Linux'. Those people have not been paying attention. Passport is already available to be ran on Linux servers. Just go to http://www.passport.com, and download the Linux toolkit.

This bears repetition: Mono is not related to passport.

If you want to have an informed opinion on Mono, please read our FAQ: http://www.go-mono.com/faq.html

miguel.

It is not the fault of any of you to do so, but it would be Petreley's duty to do a little research before writing from an uninformed point of view.

I remember I was once sitting in a panel with another famous pundit. The panel was on `Open Source' and they had brought the `experts' on Open Source to talk about it.

Such pundit said a minute before the panel begun to us `I do not see the difference between Peer to Perr and Open Source, to me they are the same thing'.

In Market speak .NET is a Microsoft-wide company initiative. To humans this means that a vision has been set at Microsoft, and every bit of the company is moving towards making that goal happen.

Now, this .NET "vision" encompasses many different areas, let me list some of them for you:

• The Development Platform.
• The Passport/Hailstorm Initiative.
• Their enterprise servers.
• Web Services in general.

People are confused between two elements: The development platform and Passport. People who claim that Mono is related to passport are making statements that are similar to `Excel is Turbo Pascal'.

The Mono Project is a project that Ximian has launched and is devoting resources to bring the benefits of a new, fresh and powerful development platform to Unix. Why we are doing this? Because we need those tools to bring you the next generation end-user applications. We could do this with C, C++ or Python, but it would take us longer, and we would waste our engineering time.

Passport is a completely different beast. Many people are confused, and asked me `How is Mono related to Passport'? The answer is: it is not related in any way. I have written a document that highlights the problems on Passport, you can get it here: http://www.go-mono.com/passport.html. This has nothing to do with Mono, but people are still confused.

Even worse, some people claim that `Mono will bring Passport to Linux'. Those people have not been paying attention. Passport is already available to be ran on Linux servers. Just go to http://www.passport.com, and download the Linux toolkit.

This bears repetition: Mono is not related to passport.

If you want to have an informed opinion on Mono, please read our FAQ: http://www.go-mono.com/faq.html

miguel.

If you want one of those, take a look at dotgnu, but even there the strategy is to be a REPLACEMENT, not a plug compatible Microsoft clone.

Try the Mono FAQ .

Miguel Icaza have just post this at mono-list:

Hello guys!

I made a presetation at the O'Reilly Open Source conference on the Mono project, shortly after David Stutz talked about the Shared Source implementation of the ECMA C# and CLI that they will be releasing.

Interesting things from David's talk:

* The terms of that shared source license are still not ready, and will likely be different than those from Windows CE.

* They expect to have something by the middle of next year.

* He confirmed that it will just be the core of the system, and will contain a JIT.

He made my life easier by explaining to the audience what the CLI was, which was helpful as I did not have to go into too much detail on the remaining time.

We had a good talk about the CLI afterwards.

The slides for my talk are available on the Mono site (I believe I already sent a mail about this) but in case I didn't, just go to http://www.go-mono.com, and you will find the link to the talk slides.

There were some good questions, like how we will avoid patents if there are any on the ECMA specification. Our answer is that we will stick to use old technologies: things that have been documented or written about in the past in the various areas where the CLI and C# matter: intermediate languages, standards for type systems, traditional optimization, garbage collection in the ways that Java has done for multi-threaded operation, traditional compiler instruction selection.

For those cases where we incur in a speed penalty, we will research alternative ways to implement things to not infringe on their patents. This is particularly useful for those of you who are studying and need to write a thesis, as we have a research project you can work on.

I also got a chance to talk face to face to Sam, and we discussed a bit about possible ways of improving the runtime. One thing that came to mind is that it would be possible for someone to work on a number of projects: retargetting an existing Java compiler (I am familiar with Guavac, and seems good enough) to generate CIL instead of JVM byte codes.

I am now flying to Ottawa for the Linux Symposium. I will try to make releases of the runtime, the class libraries and the compiler on Sunday or Monday when I get back to Boston.

Best wishes,
Miguel.

useful links

• slide presentation
• mono home
• OSCON

Miguel Icaza have just post this at mono-list:

Hello guys!

I made a presetation at the O'Reilly Open Source conference on the Mono project, shortly after David Stutz talked about the Shared Source implementation of the ECMA C# and CLI that they will be releasing.

Interesting things from David's talk:

* The terms of that shared source license are still not ready, and will likely be different than those from Windows CE.

* They expect to have something by the middle of next year.

* He confirmed that it will just be the core of the system, and will contain a JIT.

He made my life easier by explaining to the audience what the CLI was, which was helpful as I did not have to go into too much detail on the remaining time.

We had a good talk about the CLI afterwards.

The slides for my talk are available on the Mono site (I believe I already sent a mail about this) but in case I didn't, just go to http://www.go-mono.com, and you will find the link to the talk slides.

There were some good questions, like how we will avoid patents if there are any on the ECMA specification. Our answer is that we will stick to use old technologies: things that have been documented or written about in the past in the various areas where the CLI and C# matter: intermediate languages, standards for type systems, traditional optimization, garbage collection in the ways that Java has done for multi-threaded operation, traditional compiler instruction selection.

For those cases where we incur in a speed penalty, we will research alternative ways to implement things to not infringe on their patents. This is particularly useful for those of you who are studying and need to write a thesis, as we have a research project you can work on.

I also got a chance to talk face to face to Sam, and we discussed a bit about possible ways of improving the runtime. One thing that came to mind is that it would be possible for someone to work on a number of projects: retargetting an existing Java compiler (I am familiar with Guavac, and seems good enough) to generate CIL instead of JVM byte codes.

I am now flying to Ottawa for the Linux Symposium. I will try to make releases of the runtime, the class libraries and the compiler on Sunday or Monday when I get back to Boston.

Best wishes,
Miguel.

useful links

• slide presentation
• mono home
• OSCON

Miguel Icaza have just post this at mono-list:

Hello guys!

I made a presetation at the O'Reilly Open Source conference on the Mono project, shortly after David Stutz talked about the Shared Source implementation of the ECMA C# and CLI that they will be releasing.

Interesting things from David's talk:

* The terms of that shared source license are still not ready, and will likely be different than those from Windows CE.

* They expect to have something by the middle of next year.

* He confirmed that it will just be the core of the system, and will contain a JIT.

He made my life easier by explaining to the audience what the CLI was, which was helpful as I did not have to go into too much detail on the remaining time.

We had a good talk about the CLI afterwards.

The slides for my talk are available on the Mono site (I believe I already sent a mail about this) but in case I didn't, just go to http://www.go-mono.com, and you will find the link to the talk slides.

There were some good questions, like how we will avoid patents if there are any on the ECMA specification. Our answer is that we will stick to use old technologies: things that have been documented or written about in the past in the various areas where the CLI and C# matter: intermediate languages, standards for type systems, traditional optimization, garbage collection in the ways that Java has done for multi-threaded operation, traditional compiler instruction selection.

For those cases where we incur in a speed penalty, we will research alternative ways to implement things to not infringe on their patents. This is particularly useful for those of you who are studying and need to write a thesis, as we have a research project you can work on.

I also got a chance to talk face to face to Sam, and we discussed a bit about possible ways of improving the runtime. One thing that came to mind is that it would be possible for someone to work on a number of projects: retargetting an existing Java compiler (I am familiar with Guavac, and seems good enough) to generate CIL instead of JVM byte codes.

I am now flying to Ottawa for the Linux Symposium. I will try to make releases of the runtime, the class libraries and the compiler on Sunday or Monday when I get back to Boston.

Best wishes,
Miguel.

useful links

• slide presentation
• mono home
• OSCON

I just realized that made me sound like a dick. I really like evolution, it's an awesome program, and I thank Miguel for working on it. Along with his work on mono, whcih I would like to get involved with some day. I just have problems with red-carpet right now (not philosophical problems, just weirdness with trying to install software). Anyways, sorry.

I truely believe that KDE will slowly take over as the defacto desktop environment, interviews like these reaffirm my thoughts on the issue. We know where we stand with KDE what their goals are and how they plan on getting from A to B without getting sidetracked by C. They're proving themselves to have excellent vision and product execution. Congrats to The Kompany, I'm sure I'll be buying some of your products in the future.

It is amazing how many Slashdot readers will slam things without understanding them. I suggest you read Mono's .NET FAQ and see if there is anything in there that would lead to "Lost Privacy. Stupid Security bugs. Pay-to-play software."

The very first two questions address your concerns.

However, Mono aims to duplicate these APIs using already existing (and modified) Gnome libraries. From the FAQ:

Question 25: How is this related to GNOME?

In a number of ways: Mono will use existing components that have been developed for GNOME when it makes sense. For example on X systems, we will use Gtk+ and Libart to implement Winforms and the Drawing2D API. For database access, we will use LibGDA (not really depending on GNOME, but related to).

Also, Mono will embrace and extend .NET:

Question 40: Would you allow other classes other than those in the specification?

Yes. The Microsoft class collection is very big, but it is by no means complete. It would be nice to have a port of `Camel' (the Mail API used by Evolution inspired by Java Mail) for Mono applications.You might also want to look into implementing CORBA for Mono. Not only because it would be useful, but because it sounds like a fun thing to do, given the fact that the CLI is such a type rich system.

However, Mono aims to duplicate these APIs using already existing (and modified) Gnome libraries. From the FAQ:

Question 25: How is this related to GNOME?

In a number of ways: Mono will use existing components that have been developed for GNOME when it makes sense. For example on X systems, we will use Gtk+ and Libart to implement Winforms and the Drawing2D API. For database access, we will use LibGDA (not really depending on GNOME, but related to).

Also, Mono will embrace and extend .NET:

Question 40: Would you allow other classes other than those in the specification?

Yes. The Microsoft class collection is very big, but it is by no means complete. It would be nice to have a port of `Camel' (the Mail API used by Evolution inspired by Java Mail) for Mono applications.You might also want to look into implementing CORBA for Mono. Not only because it would be useful, but because it sounds like a fun thing to do, given the fact that the CLI is such a type rich system.