In .NET and Mono: The libraries Jeff Dillon says:
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'm not sure that you're fundamental point is right. If want to write a portable .NET application (that will run on Mono et al), then I must stay away from the clearly system specific calls. When its time to port (and is porting) our application to Mono then we just move all the windows specific stuff to a separate assembly and find the unix alternatives the same thing people have been doing for years when porting applications between the two platforms.
I think the real hard work will in getting WinForms (including the event model) right on Mono. I for one don't intend to rewrite our entire GUI layer ~100,000 loc for linux/unix.
As an aside I think its better that MS has managed code to access the registry and system bits than to use interop everywhere.
BTW sorry for the long silence - we've been getting our product out to beta and blogging has become a very low priority.