I recently read a post by a Jeff Dillon (a Sun employee) entitled .NET and Mono: The libraries were he criticizes the fact that the .NET Framework has Windows specific APIs. Specifically he writes

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.

While I was still digesting his comments and considering a response I read an excellent followup by Miguel De Icaza in his post On .NET and portability where he writes

First lets state the obvious: you can write portable code with C# and .NET (duh). Our C# compiler uses plenty of .NET APIs and works just fine across Linux, Solaris, MacOS and Windows. Scott also pointed to nGallery 1.6.1 Mono-compliance post which has some nice portability rules.
It is also a matter of how much your application needs to integrate with the OS. Some applications needs this functionality, and some others do not.

If my choice is between a system that does not let me integrate with the OS easily or a system that does, I personally rather use the later and be responsible for any portability issues myself. That being said, I personally love to write software that takes advantage of the native platform am on, specially on the desktop.

At first I was confused by Jeff's post given that it assumes that the primary goal of the .NET Framework is to create a Write Once Run Anywhere platform. It's been fairly obvious from all the noise coming out of Redmond about WinFX that the primarily goal of the .NET Framework is to be the next generation Windows programming API which replaces Win32. By the way check out the WinFX overview API as JPG or WinFX API Overview as PDF.  Of course, this isn't to say that Microsoft isn't interested in creating an interoperable managed platform which is why there has been ECMA standardization of C#, the Common Language Infrastructure (CLI) and the Base Class Library (BCL). The parts of the .NET Framework that are explicitly intended to be interoperable across platforms are all parts of the ECMA standardization process. That way developers can have their cake and eat it too. A managed API that takes full advantage of their target platform and a subset of this API which is intended to be interoperable and is standardized through the ECMA process.

Now that I think about it I realize that folks like Jeff probably have no idea what is going on in .NET developer circles and assume that the goals of Microsoft with the .NET Framework are the same as that of Sun with Java. That explains why he positions what many see as a flaw of the Java platform as a benefit that Microsoft has erred in not repeating. I guess one man's meat is another man's poison.  


Monday, June 14, 2004 1:09:20 AM (GMT Daylight Time, UTC+01:00)
I think you are absolutely right - .NET and Java serve two purposes. Java is the Write once run anywhere platform, and .NET is the "VM-s are great idea why not use them" platform (didn't intend to be cynical here...).

But let us ask first how Jeff got confused. Granted, Jeff got confused because he thinks in "Java mode". But, I assume, Jeff is not stupid. Given enough clues, he probably could have figured the distinction out by himself.

So why didn't he figure it out? I believe the answer is - "because there were no clues": Microsoft, unfortunately, *does not* separate the core ECMA libraries and its own. Thus, a person going to the documentation will see System.String (which is part of ECMA) right besides System.Windows.Form (which isn't). Moreover, it seems like the whole WinFX API is going to sit in that namespace - the whole future Windows API, in the same namespace as the standard.

This small piece of namespacing is Microsoft saying to everybody - "yes, we standardized the CLI, but we're just paying lip service to standardization. In actual fact, we want to muddy the waters and make it very difficult for somebody to distinguish between ECMA and non-ECMA".

Actually, that sounds paranoid. I am sure that there was no real thought about that - it just came out that way because nobody thought of the consequences. But that's just validates the point even more - nobody in Microsoft is sensitive about this to make that distinction between ECMA CLI and Microsoft-specific extensions. They don't even think about it as extensions.

Another case in point? Microsoft makes _no_ distinction and _no_ reference between what is CLI 2.0 and what is "Microsoft Visual Studio 2005". Worse - they don't even distinguish anymore between their own CLR (a.k.a. .NET Framework) and their Visual Studio 2005.

And the reason they don't do that is that they don't notice that _their is_ a distinction - and an important architectural distinction at that!

Take a look at what Sun did - if Sun has an extension to Java that is Sun specific, they add it to the com.sun namespace. Only that which is JSR-committees created is allowed to go into java... namespaces.

And, while I am a big supporter of .NET and all the other CLI implementations, it bothers me. Because when such an important architectural distinction is not being made, then sometime in the future it will not be able to be made at all.
Monday, June 14, 2004 2:10:47 AM (GMT Daylight Time, UTC+01:00)
You're 100 percent right.
Saturday, June 19, 2004 2:42:33 AM (GMT Daylight Time, UTC+01:00)

Another issue is that the WORA-ability and intention of .NET is probably muddied somewhat by Microsoft's support for other platforms, and the third-party C#/.NET implementations, and the tendency to lump all .NET things together.

The people likely to be confused by this are probably people who are on the periphery of .NET and/or Java, especially those who are mostly interested in the competitive horse race between the platforms, rather than technical issues. ie, slashdot commenters and their ilk.

If, on the street, there's a misconception that .NET is (or will be) a WORA platform, it would probably be beneficial for Sun people to work at dispelling it.

Jeff might be responding to this sort of misconception.
Jon Hendry
Comments are closed.