Beware of differences between .NET and Mono

First, for those who don't know of what I'm talking about here, Mono is an open source implementation of .NET, and Moonlight (built on Mono) is an open source implementation of Silverlight. Though being (I bet it's not by accident) unclear about the legal situation of those who use Mono or Moonlight (two Novell products), Microsoft push Mono and Moonlight because it shows that .NET can work out of the box on Linux. Great.

Let's look at this a little more. I just read the last post from Jimmy Schementi's blog, a Microsoft developer who participate in the building of IronRuby, a .NET implementation of Ruby. The Microsoft team only works on the Microsoft .NET stack, but when IronRuby followers signal them bugs on Mono or Moonlight, they try fix the bug. At the end IronRuby is more or less working on Mono and Moonlight, meaning that it is working on Linux too. But.

This is the impression you have at first. But not all is working out of the box, and not because IronRuby still is in its 0.9 version. There's things that work in .NET but won't in Mono (Microsoft is in .NET 4.0, but Mono currently tracks the 2.0 version, and some things can not be emulated in Mono because it is to much tied to Windows), there's things that work in Silverlight and not in Moonlight (Moonlight is an implementation of Silverlight 2, but Silverlight has already reached version 3).

The contrary is also true. Mono and Moonlight allow things that can not be done on the "regular" .NET framework.

So beware if you think that code written for .NET / Slverlight will work out of the box. It won't, except if you are extra careful of using only things that are also available on the open source re-implementation. It reminds me of the differences between the Microsoft Java implementation and Sun's Java. It could work, or it could not work, depending on the situation.

But in these days it was not legal. Now it is, Microsoft has the right to do what it wants with .NET. I'm OK with that, but I also have the right not to play with all these .NET goodies. Right ?

P.S.: I have nothing against Jimmy Schementi's article. My only concern is that separating what works on one, two, or both implementation is not very clear in his post.

Office 2007 rant

OK,OK, always wining I know. My company works with another which use Office 2007 extensively, but we still use Office 2003. Previously, our IT did not provide us any tool to convert from the .x formats to the old one (This has changed now).

However, we have at work a program which allows employees to buy Office Pro for their home for a very inexpensive price. I bought it (but did not installed the 207 versions of the apps) thinking it could be handy. And so it did. No more for the context.

So I installed Word, PowerPoint and Excel, and was able to open the .pptx file that I received at work. Fine.

Except that I never used the Ribbon before. The beginning were not easy, as nothing was in a place I was used for in the previous Office 2003 version (the one I use at work everyday). After a while I get used to it, but I still don't think it's entirely a good change:

• No more direct access to the old File menu, you have to go through the new oversized Office button to access to all File actions different from the simplest save (and you are not saved from numerous clicks to do what you want)


• Very difficult to customize what as replaced the toolbar. For example with Office 2003 if you often used at the same time basic editing tools (such as the brush to copy text attributes in word or PowerPoint), and revision features, it was very easy to have both at the same time; now you have to go through a tedious process of customizing the interface (which is absolutely not what you want to do) to achieve the same result. Bottom line is: yo don't do it and you switch a million of times from one tab to the other.


• Knowing where an action is is not always easy.


• And why, why designing such a huge cryptic Microsoft button for the File actions? It means that nobody will be able to stick to the same UI for the similar actions for accessing to File actions in their own apps. One more time, it seems that Microsoft did something only to erase every possible competition.

Remember this post: I talked about my two first open Source projects:

• MDIFramework aim to provide a ready-to-use desktop application infrastructure in Java. I mainly created this project because I always reused the same piece of code in my own work, so I wanted to have a generic library instead. I thought it was better to open source it, so that's what I've done.


• MDIUtilities is a utility library with various classes in the swing, IO, geometry, etc... fields. There's tons of other libraries in the open, but it is not always easy when all you want is a small library to provide utility classes. Sometimes you could end-up with tons of different libraries, for which you only use few classes.

Well these two projects have both been bumped to 0.3 version. In the hope it can be useful...

About MDIFramework, maybe you will say: Why not using Eclipse ? Well Eclipse is a huge framework. When you develop with Eclipse in mind, you are in the Eclipse ecosystem, and you end with a lot of Eclipse dependencies. That can be a good thing, but if you want to keep control on your work, and avoid to bear the burden of too many dependencies (or limit the size of your install), you should look elsewhere. Plus Eclipse does not handle everything for you.
But why not using appframework ? Unfortunately (for the moment) appframework does not manage several things that are handled by MDIFramework:

• Plugins


• dynamic menus


• storing / retrieving non GUI parameters between sessions


• managing FileTypes

...And MDIFramework was created before appframework even existed on the Web (2006).

Microsoft, what are you doing with .NET ?

It seems that the size of the .NET framework is increasing with every update. Last auto update seems to be at a bloated 250 MB !!!(RTM was approximately 200 MB, but remember it is only a SP1 update !!). It's funny that people keep criticizing Java for the size of its download, when Java 6 JRE is less than 15 MB. Plus you can download only the kernel (less than 5 MB), which is enough to play any Java applets, and if you need more, other parts of the JRE will be loaded as you need them.

It reminds me of Acrobat Reader, which is now more than 30 MB (only to be able to view PDF Files !!), it has become so bloated with unneeded options as time passes that opening a PDF document now takes ages, even with modern hardware !!! Adobe, what do you think ?

Steps to improve wikipedia

I have just been repeatedly insulted by a user on wikipedia with such terms as "you really are just talking gibberish now", "Your accusations of original research are pathetic", "I cannot believe I wasted my time on these arguments believing you to at least be rational", "you're a complete hypocrite", or "I am sorry you don't possess the intelligence...".

Well it's the first time it happens for me, and I'm really editing in wikipedia for some years now, so it's not such big deal (I'm sure it can / will happen to everyone after a while), but it made me think about things that could improve editing in this project. This will not change anything in cases like mine now (sadly there's people like that everywhere), but I'm trying to look more generally than just around my little problem):

• make it mandatory to register, so as it would really be possible to block vandals (again this is NOT related to my case, as the user insulted me, but he clearly is NOT a vandal). I remember a case when various IP addressed obviously coming from the same origin kept vandalizing various articles, but the address changed because it must have been an internet cafe or a school, so it was really impossible to block it, even using IP)


• allow to see the IP for any registered accounts (except in special cases of course, related to people wanting to be protected when posting, such as in some countries when posting on internet can be dangerous from their well-being). This would then be easier to detect people payed to post for various companies

XUL for Java: stucked (for the moment)

Remember This post: I just created a new java.net project to allow to use XUL declarative scripts out of the box with Java, and allow to bind them at will with Java code or even other scripting languages as well. The code comes from another project were it was working very well, but after extracting it from this project, I still have a big big problem with accessing some Javascript code from the XUL script (which makes the whole thing unusable of course for the moment). I know it's a trivial problem because the same use case works like a charm in the original implementation, I must have deleted the wrong line of code somewhere...

I still have a problem with the DLR

Microsoft's Dynamic Language Runtime shipped its first Beta a few days ago. For those who don't know, the DLR is Microsoft's effort to bring support for Dynamic Languages on top of the .NET Virtual Machine. Catch it ? Dynamic Languages are the rage today, and .NET and Java now want to catch the trend on their respective VMs. The DLR initially lived in the IronPython codebase (IronPython is the .NET implementation of Python), but it now seems to live on its own.

I expressed some concerns about the state of the ongoing work for the DLR some time ago, and some people from the DLR team tried to answer. These concerns were (in short):

• A lot of hard coded references to IronPython and IronRuby, the currently two Microsoft project heavily leveraging the DLR


• Compilation directives looking for Silverlight everywhere in the code

In short, my concern was that the DLR may be too tied to Microsoft implementations specificities, and not really language / or implementation agnostic. I know this is not what Microsoft folks want, but all this just adds complex interwoven ties between parts of Microsoft's offerings that should never meet explicitly ;-). People already encounter repeated problems when trying to build IronRuby under Mono, this can only make it worse.

And sadly, when looking through the code, I saw as many Silverlight directives as before. And now, some new LINQ references that were not there before. My problem is not that there are dependencies, it's the fact that they seem to be everywhere in the code. I would greatly prefer to see them limited to a specific module in the code, and I'm worried about these new LINQ dependencies. Plus why compilation directives ? Why is it not possible to limit Silverlight specificities to a separated assembly (preferably implementing an interface with a default implementation), and link to this assembly at runtime ? And why Silverlight is so different from the core .NET runtime ?

Update 6/12/2008: Since Bill Chiles comment, I downloaded the code (before I just browsed in the codebase through the web access), and here is what I discovered:

• 139 files with ifdefs for SILVERLIGHT in the code (that makes roughly 25% of the files), mostly in the Core package (71 files in Core and its subpackages), but widespreaded in the codebase.


• 4 files referencing IronRuby, and 12 referencing IronPython !!! Again these are not limited to a particular package in the code, and I really wonder why there are more references to IronPython than IronRuby. In short, I don't know how anybody would be able to use the DLR for a new scripting language without changing the core DLR code


• 302 files using Linq specific libraries and/or functions.

I'm sorry to say that it does not look to me as a well-designed code IMHO (for the moment). I would very much like to see:

• ALL specific references to IronRuby and IronPython removed.


• If it's not possible to avoid ifdefs for SILVERLIGHT (I hate ifdefs in general) at all, then limit them to a specific package in the code, and access these by a neutral interface


• I really don't think that the idea to put Linq there was very good to begin with, but at least I would prefer to see Linq references limited to a Linq-specific package

Update 2 (7/12/2008): About references to IronRuby and IronPython, I maybe was a tad too fast to criticize (I still stick to my previous point with Silverlight references). There's only one file with a real hard reference to IronPython, IronRuby, and JScript. I really don't know why the PlatformAdaptationLayer class needs to explicitly add assembly mappings for these implementations. Why not leaving it to each implementation to add its own mappings ? How a new scripting language will be able to add its own mappings without changing the PlatformAdaptationLayer code ?
But there's still a lot of comments about IronPython in the code, which makes me think that some of the DLR code is still tied to this implementation. However, this should improve in the future. Except that... I now saw another file with an explicit new compilation directive (argghhh !!) referencing IRONPYTHON_WINDOW. That looks bad to me.
And to show my point about the SILVERLIGHT references, let's use one simple example, again in the PlatformAdaptationLayer class. The code is:

public virtual bool DirectoryExists(string path) {
#if !SILVERLIGHT
   return Directory.Exists(path);
#else
   throw new NotImplementedException();
#endif
}

OK I think its because Silverlight impose limitations on access to the File system (sandboxing), so you may not access directories at will. I have no problem with that limitation, but... It would have been very easy to access to a platform-specific assembly here, instead of using these dreadful compilation directives. The Windows platform assembly would simply return Directory.Exists(path), the Silverlight assembly would return the NotImplementedException. This would have been way better IMHO.