Zac Bowling’s Blog

I’ve given this a lot of thought after staying up trying to port MonoDevelop to Win32 and explaining what I was doing to a friend who was relatively new to Mono but experienced with C#. He seen me adding conditional compile arguments similar to this below:

#if !WIN32
using Gnome;
using GnomeSharp;
#endif

I tried to explain it, before he interrupted me and said, “Isn’t mono suppose to support running the same .NET exe on all platforms?”, I replied “Yes, and it does, but this library isn’t on Windows.” He looked confused so I tried to explain, and while doing so, it hit me. We are doing something wrong in GTK#. Its something that many of us used to porting anything to anything else would over look, but in Mono shouldn’t really exist and something that Java seems to prevent in the first place. Let me explain.

We have the mono runtime and mcs C# compiler. The mono application being capable of running a .NET application or dll on any of its supported OSs, by reading the application at a CLI layer, and at the same time allowing us to run the same compiled application across all those platforms. The mcs tool allows us to compile .NET compatible EXEs and DLLs.

Now here is the kicker. When building or running a .NET application it is required that we have all the assemblies used in the application when we run or build (unless of course you are loading the assembly dynamically and using reflection apis). Even if the library is unused on a platform, its still required to run or build an application that might use these libraries in the application for a different platform. That is why I used conditional compile arguments to build on WIN32. Libraries that currently fall into that catagory are Gnome#, Gnome-vfs#, GtkHTML#, and a few others.

It looked correct at the time but now I think that mindset is wrong. Using compiler arguments to build for WIN32 works, but in the end it, it generates 2 different platform specific applications. The only way to have a single application is using late bound assemblies, which
totally sucks.

Now I’m not advocating that we drop libraries like Gnome# or try to port them all to all operating systems because that’s just silly. What I’m proposing is that we modify the gapi tools to support generating “fake” or “look-alike” code. These would be libraries that do nothing more then mimic the classes, interfaces, types, enums, etc, but when you try to use them they ether do nothing or return a “NotImplimenetedException” or something. This would alow you to use the library to build with on any platform, but if you call code with one of those libraries not available on for your platform it throws an exception. So you could test at runtime if its ok to run a library of another method for the current platform should be used.

Like, for example, instead of using the following and getting 2 different exes:

#if !WIN32
using Gnome
using GnomeSharp;
#endif

you could use something like this:

using Gnome;
using GnomeSharp;
using System;

namespace Test{
  public class TestPortablity(){
    public TestPortablity(){
      if (Gnome.IsReal == True)
        Gnome.DoWhateverInGnome();
      else
        DoSomethingForWin32Instead();
    }
  }
}

and it would work with a single exe on all platforms.

---

Update

Some people don’t understand what I’m saying, so I’m going to try and help you guys out a bit more.

One solution that has been voiced is to copy the dlls from a linux box to the windows box. Yes, this would work, if you had access to a linux box, or you hand compile just the .NET dll and not the glue library (if any) and you planed to distrubute the dll with the program. You would also have the issue of it failing in countless ways if you had code that sneaked through and managed to called it without you checking before hand. My method would throw an not implimented error the second a call was attempted. The only issue is that this would break with code written into the custom files that directly called a pinvoke internally.

Someone said that you could just use reflection. I’m guessing they didn’t read above what I said. I considered that, but why rewrite the functions I need from the base library for everything I want to call. Its the most ellegante solution next to my main one and to some people, the only acceptable/correct one. I would normally agree, but not for entire libraries.

Someone said that having it throw an error would be very taxing on the application. Not really. You should only get errors while porting, to show you where you have portablity issue. After they are fixed, you don’t have any more errors.

Someone said its not worth changing the tools to do it, but I believe this is the best, most ideal place. I’m thinking of something like adding a “–fake-interface” or something to the arguments to have gapi-codegen generate the fake interfaces based on the api xml. It wouldn’t effect anyone but people who need a “fake-interface”. It could be used in the future if we wanted to use a Win32 only dll and wanted to include it on linux and mac builds.

Similar to how j2me and .NET compact edition works across all the mobile devices. If that device can’t support something like double integers or floating integers or threading or whatever, they still have to maintain the api, but at runtime, thats when they throw the error..

Tags: Mono & .NET

This entry was posted on Tuesday, January 11th, 2005 at 3:33 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.