Zac Bowling’s Blog

It has been a long time since I posted a real blog entry in a while on what I’ve been doing so here goes…

• GtkEmbedMoz + Gecko# for WIN32 -

  The patch is making its way into the Mozilla tree that makes this work and it might make it into the official upcoming Mozilla Suite 1.8 release (cross your fingers). Right now you can find the beta versions of the dlls required to make it work, a custom GRE (even though I have tested it with the official Mozilla 1.7.3 and 1.7.5 build, the official versions have a few bugs like disappearing scroll bars and control focus issues on web forms) and my patches to build yourself. The Gecko# dll is up there as well and I’m committing my fixes into the SVN later on to Gecko# so we should have this in the next WIN32 installer

• Monodoc using Gecko# and working on WIN32 -

  Miguel and Paco talked about it a little before. It’s nothing really to write home about except it brings it to Windows. I have the patch for using Gecko# instead of GtkHTML (which doesn’t work on WIN32) here if you want to play and a screenshot can be seen here.

• Tomboy on WIN32 -

  I got bored and decided to have some fun, so I ported Tomboy to WIN32. It was pretty easy. It only took me about 30 minutes. I think it really shows that rapid application cross platform development is really something that Mono can offer.
  

• SNMP.NET -

  I have a fully working lightweight SNMP library for .NET that I wrote using references from a few networking books I have. I included two little sample apps as well that can query a devices id and uptime and the other one can query for that machines MAC address. Provided of course you query an SNMP device that you have its community name for. Most routers and any *nix flavor box running an SNMP server. I don’t have any M.I.B. support so you have to use the UID directly to make this work. M.I.B. translation is a bit more work then I pulled off in the 250 lines of code in this. It uses pure sockets provided by System.Net so it works on Win32, Linux and Mac OSX I know for sure. Get it here: http://polystimulus.com/snmp.zip. (Side-note: I do have a fully library that does have full M.I.B. support written by this guy in England but its very complex and very resource intensive but it provides the ability to host SNMP, but it doesn’t currently work in Mono yet.)

• PHP&GTK - PHP & Mono & GTK#/SWF -

  I’ve been toying with this idea a bit and had some great success with it. It’s the one idea that when I mention it, people seem to always say, “I don’t know whether to be sick or socked and amazed.” I know a lot of people have tried and used PHP-GTK. You basically run PHP as a runtime on the client side and use it make GUI apps with GTK as the interface. Applications like Nova (a gnutella client for WIN32) do this and pull it off really quite well. The biggest issues though is that PHP+GTK is very slow on development and stuck in gtk 1.x right now and it doesn’t have a lot of interest as it started as more of a proof of concept. Part of the issue is that if you use it to wrap your existing code, you couldn’t render HTML in anyway so everything has to be rewritten with GTK.

  Well I have a much cooler solution. Thanks to the classes in PHP that allow you to load and access .NET/Mono assemblies in PHP, it is possible to take PHP, run it as a runtime, and call SWF/MWF or GTK# for your interface. Then thanks to Gecko# and GtkHTML you can render basic things like your tables and css styles inside your app without rewriting. Nothing working well enough to post about it.

Well that just about sums it all up. I’m also looking for a job if anyone is hiring in the Dallas area.

Showtime wants to cancel one of my favorite shows. Yes, I know it s a little corny but I really liked that show. Grr on you MGM + Showtime … http://www.deadlikeme.tv/

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..