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.