On .NET and portability

Jeff posted on portability of Java vs .NET code in an article.

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.

Porting an application from the real .NET to Mono is a relatively simple exercise in most cases (path separators and filename casing). A situation that I would like to fix on upcoming versions of Mono to simplify the porting (with some kind of configuration flag).

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. I want to take advantage of what my desktop has to offer: Gtk# (when using Linux), Cairo, OpenGL, Cocoa# (when using the Mac), GConf, Gnome Printing, and access to Posix.

If my software uses all of the above libraries, will it be easily portable? Most likely not.

Consider what the iFolder team is doing: they are writing the core libraries as a cross platform reusable component. This component is called "Simias" and provides the basic synchronization and replication services. Simias works unchanged on Linux, MacOS, Windows and Solaris. Like every other cross platform software, it must be tested on each platform, and bugs on each platform must be debugged.

This is not different than doing any other kind of cross platform development.

Then they integrate with each operating system natively at the user interface level. Windows.Forms and COM on Windows; Gtk# on Linux and in the future Cocoa# on the Mac.

Although Gtk# looks and feels like Windows.Forms on Windows, the problem that they were facing is that Gtk# was an extra download for people using iFolder, and they chose to keep things simple for the end user.

Mono as a new Wine?

Although Jeff's post is fairly naive and not that interesting I do have a problem with his follow up: Mono is not just a `Wine-like' technology to emulate an API.

Mono is a complete development stack, with a standard core from ECMA and ISO. Jeff has obviously not written any code with Mono, or he would know that it is quite an enjoyable standalone development platform as oppposed to just a runtime.

Mono is also not limited to run the .NET code, thanks to IKVM: a Java VM written entirely in C# and .NET, we can run Java code just as well as .NET on the same virtual machine, and have them happily talking to each other.