Jeff Dillon

« What a great idea | Main | Blogged on Ongoing... »

09 Jun · Wed 2004

.NET and Mono: The libraries
I have been playing with .NET and Mono on my own time recently. Java the language and C# are so similar that saying one is any better than the other is waste of time. As a Java developer who likes Java, I really like this similarity. This means that I can write java-like "native" windows code to do windows specific things. I always hated C++/COM and C#/.NET is exactly like Java with system dependent libraries. This is great if I need to do windows development.

Where this starts to fall apart is with the .NET and Mono libraries. The Java API writers have always been very careful not to introduce an API which does not make sense on all platforms. This makes Java extremely portable at the cost of not being able to do native system programming in pure Java. With .NET, Microsoft went ahead and wrote all kinds of APIs for accessing the registry, accessing COM objects, changing NTFS file permissions, and other very windows specific tasks. In my mind, this immediately eliminates .NET or Mono from ever being a purely system independent platform. Yes, it is possible to implement some sort of Windows Registry Proxy that would run on Unix. Would it always work? Of course not. But, more importantly, is this a good idea?

I think some of this stems back to the issue that many people still do not see the difference between Java the language and Java the platform. The Mono C# compiler is a great piece of work. In my mind, C# the language is absolutely superior to C++. However, with C++ we learned the lesson that STL had portability problems. The .NET and Mono libraries are no solution to the libraries that are used with C++.

It's the libraries stupid.

@ 10:42 AM PDT

Comments:

I have used both Java and C# extensively. I would say that the .net libraries are more usable and lead to a noticeably higher productivity rate. I think the reason is that .net is quite new and is a coherent system designed from scratch. The Java JDK has accreted cruft over the years. Is .net ever going to be a solution for Unix? I doubt it. 　.net is for Windows. Are you willing to accept a Windows only solution? Perhaps doubling your prductivity will tempt you.

Posted by David Knight on June 10, 2004 at 04:42 AM PDT #

In Java you couldn't really choose not to write a portable program. Obviously this won't be the case in C#, but it doesn't mean you can't write a portable program. And I don't think that requires an emulation layer either (like a Windows Registry Proxy). I think portability works best at a higher level than the basic language libraries. If you are saving configuration values, you save them differently depending on platform, so the portability layer goes in the configuration library. But that library doesn't have to be part of the language. And if that portability layer was part of the language, you would annoy a third-party configuration library author, because they wouldn't be able to tweak the system based on the platform. Being able to pierce a compatibility layer can be very important to creating a robust, usable application. The best situation, IMHO, is where the applications can be written in a portable way, but all the libraries have the option to do platform-specific things. (Blast this comment form for not letting me separate this into paragraphs!)

Posted by Ian Bicking on June 10, 2004 at 10:10 AM PDT #

Sorry, you'll have to do better than that. Look carefully at the namespaces of the libraries you are complaining about. You'll note that all purely Windows specific features are in namespaces which start "Microsoft.Win32" (which totals nine (9!) classes). All of the code in the "System.*" namespace tree (several thousand classes) is platform independant. So, to write a program that cross-platform capable, just avoid the Microsoft.Win32 namespace. Note, that in the dozens of C# apps I've written (which include console, windows, ASP.NET, and PocketPC), I don't believe I've ever needed to use anything from the namespace.

Posted by James Curran on June 10, 2004 at 12:40 PM PDT #

I tried to get a ping and trackback to do this automatically. I replied in the form of my own posting: http://dotnetjunkies.com/WebLog/mlevison/archive/2004/06/10/16114.aspx

Posted by Mark Levison on June 10, 2004 at 01:11 PM PDT #

PingBack: http://www.hanselman.com/blog/PermaLink.aspx?guid=947abc44-2c7c-4fb2-90d9-8e280911a5ee

Posted by Scott Hanselman on June 10, 2004 at 07:13 PM PDT #

You must not have looked at them very closely. There are a few windows specific API made available and these are clearly segregated from the rest of the libs. I have been writing .net code every day for over a year now (b4 that I wrote java code every day for 4 years) and I have never used any of those windows specific libs except when interacting with older applications which had windows specific requirments. Having covered the obvious errors in your post let I would also like to say that the .net libraries are much more well structured then the java libs. I hope I never have to go back to writing code against the JDK. Yes, it is the libraries stupid!

Posted by David on June 10, 2004 at 09:02 PM PDT #

I don't understand why you'd want to develop .net on anything other than Windows.

Posted by pb on June 10, 2004 at 09:14 PM PDT #

While I like both C# and Java, some posters here mentioned that Microsoft-specific APIs of the .NET FCL are segregated in the seperate Microsoft.* namespace. While partially true, I'd argue that System.Windows and System.Drawing namespaces are rather deeply tied to Microsoft Windows operating systems with GDI+ support and a WndProc message pump. That said, obviously those two ares can be implemented by 3rd party CLI providers (i.e. Mono, DotGNU) in a more platform-independent manner by using cross platform toolkits like Gtk#.

Posted by Judah Himango on June 11, 2004 at 03:07 PM PDT #

Jeff, There are a very small number of hooks into Win32 in the System.* namespaces. But if you look at the main libs: System.Web (nothing there), System.Collections, System.Text, System.IO, System.Windows.Forms, there is really almost nothing. Sure, there is the ability to hook into the WndProc message pump in windows forms, but how many corporate developers do you really think have ever used that. For the ones who have, it is an insult to them to think they do not know they are building a less portable component. BTW: As of MONO where it stands today, all my companies apps built with .NET in the last 2 years work "prefectly" on MONO. So at a practical level there is no problem.

Posted by David Taylor on June 11, 2004 at 06:21 PM PDT #

This portability issue is really a non-issue for programmers. None of the platforms are the same, at least their directory hierarchy is always different. When I write a software, I write it for a particular platform, not all platforms. So with java, portability doesn't make sense, doesn't have any particular use, except few cases. When it make sense, it is great, but it doesn't, it sucks. In these cases, C# wil dominate the market. The threat for Java is that, with C# you can write portable code. That means, if you want to run your code in both Linux and Windows, you can do that, there is nothing that stops you to do that. If you think about this from this perspective, you conclude that with Java, you can't write platform specific code, you can only write platform independent code. With C# you can do both. So that's why Java is more likely to lose in the future, not in the near future though, since there are enough number of people who know Java.

Posted by Daniel on June 13, 2004 at 11:51 AM PDT #

We'd probably all care more about writing platform independent code if there weren't a single platform most programmers write for, but three or four distinct platforms with significant shares apiece. Java was probably ahead of its time, and C# may still be. With Windows owning 91% of the Operating System market (according to Google zeitgeist), most developers don't really care about a product being truly cross-platform. Platform independence is an afterthought, because most customers are Windows users. As a result of that, developers also want to use the latest-and-greatest Windows-specific technologies to make them more productive and make the program faster, etc. This locks the code in even more (at least in Linux native programming, code is still portable, a la GTK). Now, think about if 20% of users ran Mac OS X, 10% ran Linux, 50% Windows and 10% something else (BeOS, Solaris, whatever). Suddenly being a cross-platform programmer becomes a bit more important, doesn't it? It means the difference between a market of one size and a market nearly twice that size for your products. Suddenly it's something to think about, and running programs in a JVM (or some other fast virtual machine) seems like the only way to go. The great benefit with Java and with .NET in its pure, non-Microsoft form (if one can say that of .NET! :-)) is that people should be able to choose their operating system based on its merits and still have the same selection of software. But when there's only one dominant choice in operating systems, who cares? I just wish we had more OS diversity... don't you?

Posted by pixelmonkey on June 13, 2004 at 11:10 PM PDT #

[Trackback] I doubt that there is ever a way to prevent platform dependency (name your degree of dependence) using practical general-purpose development platforms. For me the debate comes down to how does one want to arrive at a disciplined way of providing for p...

Posted by Numbering Peano on June 14, 2004 at 08:36 PM PDT #

To partially reiterate earlier comments, you seem to take as as given that platform independence is important, and it isn't. 90% of the world runs Windows, and while the portion of the world's software that *only* needs to run on Windows isn't that high, it's still the majority. And even if platform independence were an important goal, it still isn't clear that it would be in Microsoft's best interests to help foster it.

Posted by Joe Ganley on June 17, 2004 at 09:15 AM PDT #

Judah, Your comment about implementing the .Net libraries using GTK shows a misunderstanding of the concept of cross-platform. Basically, a "cross-platform" library is merely an interface. It's in completely impossible to create a cross-platform implementation, because, at some level, the implementation must address the machine's hardware. GTK works on multiple platforms, merely because, in addition to the cross-platform interface, it ships with several different platform-specific implementation. .Net has a cross-platform interface, but ships with only a single implementation. If some other OS vendor wishes that .Net program run on their OS, all they need do is create a CLR which maps the .NET classes to their API. Granted, the .NET classes map more neatly to the Win32 API than to the Linux API. But then, the Java JVM class map more neatly to the SUN OS API then they did to the Win32 API. And I imagine that the same could be said about GTK and the Linux API vs Win32 API. P.S. Is there any way to convince this editor to start a new paragraph?

Posted by James Curran on June 18, 2004 at 01:18 PM PDT #

I think you misunderstood my post; I mentioned that some of the graphical libraries in Microsoft's .NET could be made more portable by using an already-existing cross platform library, such as GTK.

Posted by Judah Himango on July 18, 2004 at 02:15 AM PDT #

That's where you are wrong :?P Most .NET libraries (other than the syntax, threads & file handling libraries) are not part of ECMA (hence, may contain m$oft intellectual properties). Which ultimately means, developpers using C# on other platforms, will never resort to these APIs. So, it's back to 3rd party GUI bindings like GTK# & QT#. Now, it's no better than any other command-line interpreted languages like Perl, Python, etc. I am citing GUI as an example, but other API might just as well applies. Now because there is not standardized GUI bindings for C#, GTK# may be ported to say X number of platforms & QT# may be ported to Y number of platforms due to fragmentation of developers' efforts. Hence, on some platforms, these bindings are buggy, incomplete, etc. Whereas with Java Platform, if you can get your hands on a ported JavaTM virtual machine, chances are the GUI gets ported along with it. Otherwise it cannot bears the trademark name Java if it dont pass the compatibility test. Even better, Swing is built on small native code (AWT subset) making it easier to port Java GUI on many platform. End-users (esp. windows users) will expect a single all-inclusive big-bundled binary on all their platform, they are not gonna be bothered with spending time tracking depandencies. When a user uses a couple of .NET apps & realizes that some apps need GTK# & some needs QT#, they are gonna freak out. On some platform, they will have to compile these big GUI bindings... yeah right. As for not having platform specuific APIs, that is not so bad. Because it is platform specific, developpers can develop them using native interface. Since it only works on one platform, there is no need for standards :?)

Posted by Caffeinated BEANS on July 19, 2004 at 08:46 AM PDT #

Sun	Mon	Tue	Wed	Thu	Fri	Sat
« July 2009
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

Today