Tag Archive for 'Mono'

Running xLim with latest Mono: XPO, autofac and binary compatibility

This is the update to the previous R&D post on running xLim (XPO+Autofac) under Mono 1.2.6.

Short summary:

  • Latest autofac code passes all tests with the latest mono sources
  • The dictionary issue (the one that required patching XPO sources) is fixed in the latest mono code
  • Binary remoting does not work for XPO purposes.

The reason for the last problem is simple: Mono and .NET implementations of the DateTime object are completely different. Serialized Mono DateTime uses more bytes than .NET implementation. The first one does not implement ISerializable, while the last one - does. That could make some difference.

Miguel de Icaza has pointed to the topic in Mono FAQ on the subject of binary compatibility between .NET and Mono. It turns out that the DateTime is not one of these compatible types. I wonder if there are other incompatible primitives or widely-used classes.

Running xLim under Mono 1.2.6

There’s a small update to the last post on xLim portability. The situation is a bit better than it seemed to be.

XPO + Mono (SUSE SLED)

XPO runs under Mono. It can’t work with the the Microsoft SQL Provider since the MS SQL support under Mono is far from perfect for obvious reasons. MySQL provider does work but, as developers have found out, you’d need to change

string[] strArray = (string[])new ArrayList(dictionary.Keys).
  ToArray(typeof(string));

to

string[] strArray = new string[dictionary.Keys.Count];
dictionary.Keys.CopyTo(strArray, 0);

in the XPO sources in order for the distributed caching to work. That’s because dictionaries in Mono do not have full support yet.

Autofac + Mono (SUSE SLED)

There are 6 unit test failures:

BugFixture.IncorrectExceptionThrown1
Builder.ConcreteRegistrarFixture.RegisterThreeServices
Builder.ConcreteRegistrarFixture.
  RegisterTypeAsSupportedAndUnsupportedService
Component.Registration.ContextAwareDelegateRegistrationFixture.
  CreateFromStrongFactory
ContainerFixture.IntegrationTest
DisposerFixture.ReferenceNotHeld

Additionally there is an issue while using binary remoting across the platforms (from SLED+Mono to .NET Windows and vice versa). DateTime cannot get through, for some reason.

Theoretically, Autofac, XPO and the design with the portability in mind is all you need in order to create xLim server and engine functionality that works on Mono. So we’re in good shape here for the xLim 3 server prototypes by summer.

Web UI has got some chance of being implemented quite soon in a performant manner as well (Silverlight grid, as stated in “DevExperience Roadmap 2008″, could be delivered on summer). Additionally there is some chance that existing ASP.NET controls would work under Mono as well.

The picture for the xLim Desktop UI under Mono so far is still the same - there are no DevExpress controls any time soon, unless Silverlight grid would be capable of running on desktop. But that’s just a tiny fraction of the required UI bits.

xLim portability issues

As you know, one of the long-term “nice-to-have”s of the xLim 2 architecture is the ability to run web/server/desktop/engine pieces under the Mono environment (and this would open new OSes as targetable platforms).

Given the dependencies of the current xLim version, efficient desktop cross-platform compatibility for desktop client apps is yet out of the reach:

  • DevExperience WinForms components are never to run under Mono (heavy PInvoke dependencies are the payment for the beautiful UI). Try running MoMA to see that yourself. Although I would really miss only the XtraGrids piece (and these have a decent chance of being re-implemented under Silverlight).
  • Pure GTK# and WinForms client apps could do the trick but they neither feel nor they are efficient to use.
  • The best long-shot would be the WPF-based architecture with the cross-platform support for the Silverlight (or full-blown WPF) UI, but this is yet to come (and there’s still some uncertainty with that)

So we have web/server/engine pieces that could be made Mono-compatible in the mid-term. The situation is good with these. Mono web servers successfully host ASP.NET starter kits and different web services. And if DevExperience.Web has some portability issues, then it could be ditched. The only piece that I would really miss is the grid again (and there’s that “Silverlight-to-the-rescue” thing again).

Services and remoting do work under Mono with some quirks (binary compatibility for the cross-platform remoting is there also), although GC for now might be far from being perfect.

There are two major obstacles on this way (and they come from the major dependencies):

  • Autofac IoC compatibility with Mono
  • XPO compatibility with Mono

Luckily autofac is almost there (there are just some tests that fail under Mono).

XPO is in worse shape. It does not run at all. Luckily Mono Migration analyzer does not have a lot of arguments with the XPO code (some of these could be completely ignored).

Well, we’ll see. The good thing with the “nice-to-haves” is that they deal with the future probabilities and thus their effect on the present architecture is rather flexible.

PS: If you are interested about the reasoning behind the business need for cross-platform support xLim, then you might want to check these posts:

Windows vs. Linux from the developer’s point of view - Part 2

I want to wrap up the politics discussion started in this post and get back to the development. So here we go.

I doubt that the Linux will become more popular commercial solution than the Windows OS any time soon. Microsoft has too much inertia and resources to be easily beaten (however it is a bit helpless against political regulations in the countries outside USA, since the governments make the rules and the businesses have to follow them – but that’s the different story).

But the Linux will definitely keep on increasing its presence on the market. Especially if Microsoft keeps on embedding some suspicious random number algorithms that could have NSA backdoors (remember the recent story with the Dual_EC-DRBG in Vista SP1?). Even this suspicion is enough to push some users away from Microsoft – some organizations just can not take such risks (I’m talking about military, big financial institutions, nuclear power plants, national security and infrastructure organizations of different countries). So the governments and nationally critical organizations around the world is the first piece of market where Linux could steal get some share from the Windows.

Another one piece of market for the Linux to capture is in the countries that have lower living standards (when compared to the USA or EU). There the high-tech labor force is relatively cheap and thus the total cost of ownership for Linux is lower. That means there are more organizations where the advantages of running Linux outweigh its disadvantages (and in general organizations tend to stick to the efficient behavior in this world). 

And then just imagine, what would happen if some organization has released the compelling replacement for the Windows (and bundled with it all the common enterprise software) that just costs the fraction of the Microsoft’s price for the year subscription (with the support) and is quite easy to manage and use. All these organizations that have been saying “I would’ve ditched Windows if I had some cheap and easy-to-manage replacement that can do [here goes the list of your everyday office tasks]” could consider buying such a subscription.

Well, Novell is already trying to do that by delivering SUSE Linux Enterprise Desktop (with the help from Microsoft). This would definitely have some positive impact on the market share captured by Linux systems.

So if you couple these arguments with the facts from this post, then it does become a bit more obvious that Windows desktops are going to lose some market share to Linux systems, does not it?

This “some” market share actually has quite some money in it. In FY06 Microsoft had revenue of $13 billions just from the Client operating segment. Even a tiny fraction of that (Linux environment is still not really good at being commercial) could open up interesting possibilities to the ISV companies that will be able to jump into this niche as it gradually expands.

One of the ways of doing that – is to use development tools, principles and resources that are capable of efficiently delivering cross-platform solutions. Obviously these technologies should be supported by some solid experience, reputation and the energy.

Who’s the primary market driver in the Linux vs. Windows competition? Microsoft.

Does it care about Linux? Yes.

What’s its favorite development technology? .NET

Can .NET work on Linux? Yes.

Does the mentioned primary market driver care about making his favorite development technology better and more popular in Linux systems? Yes.

So it’ll be.

Phew, that should do it with the politics. Back to the development world I can return.

.NET and Mono development could repeat the “browser wars” story

As I’ve said in the previous post, Windows is gradually loosing the market to Linux systems. Such thing would obviously lead to the increased demand in software development for the Linux world.

NB: I’ll be talking right now about the desktop applications with the feature-rich UI and capabilities. That’s the Smart Clients. Web applications are partially immune to the problem of Windows-to-Linux transition (plus the efficient delivery and the maintenance of the feature rich UI is not something they are extremely good at).

Here are things that could possibly matter in the future for the desktop applications:

1. SUSE Linux Enterprise Desktop (SLED) is going to be one of the frontier points in the Windows-to-Linux migration, since it is supported by both Novell and Microsoft. This Linux system is also the most friendly to the Windows refugees (I’ve experienced that) and is supported by the major PC vendors (see the previous post).

2. The only rich and efficient development technology that is supported by Microsoft and Novel is .NET. It works natively under the Windows and with some limitations it could run under Linux or Mac systems via the Mono (see the list of the supported platforms). And Mono is the Novell’s project.

By the way, if you are deep into this new Silverlight thing – do you know that Microsoft has “announced a deal with Novell to have Mono provide Silverlight support for non-Microsoft platforms”? That statement delivers some message about Microsoft’s expectations on the future importance of Linux and Mono. And this company should have some qualified analytics.

Consequences:

  • There will be demand for the developers/teams that could efficiently deliver solutions capable of running in two worlds (or in three, if you count Mac). That’s not a trivial task, since every operating systems has its own quirks (remember the consequences of the browser wars?).
  • The market supply of the experienced development resources in this area is quite limited (and the entire knowledge area itself is quite specific and young) so the prices will be quite interesting (means “high”).
  • The applications blocks and other recipes being delivered by the Microsoft patterns & practices group will favor solutions that add more flexibility to existing .NET solutions and simplify .NET-to-Mono transition. Novell would do the similar thing.
  • Desktop applications will start using the “Mono compliant” logo and it will bear the same message as the “W3C valid” image.
  • One of the big differences between .NET and Mono is in the UI. Currently developers could easily get astonishing UI by using components that hack deeply into the Windows API (P/Invokes and such). Unfortunately this experience is not easily portable to Mono. So there’s likely to be an effort to create some high level unified UI abstraction layer capable of rendering great UI on any OS (Windows Presentation Foundation?!). I just hope there will be no analogue for the ActiveX technology.

3. The most productive tool for the .NET development is Microsoft Visual Studio. Yet it is not ready for the Mono development. And #develop along with MonoDevelop still feel quite immature (and there is nothing like Resharper there). So the Novell and Microsoft could be delivering some solid Visual Studio Mono packages. They should let developers become more efficient in developing Mono-compatible applications (or porting the existing ones). I’m talking not just about the “Execute under the Mono VMWare image” button, but rather about code analyzers (some that bring MoMA capabilities to the new level), guidance packages and reference implementations.

Consequences:

  • Virtualization technology is going to stay popular these years.
  • Development machines will obviously require quite a number of hardware upgrades to support virtualization. This will corellate with the new FSBs getting higher, processors getting more cores,  DDR3 and hybrid memory becoming more popular.
  • The actual development is going to get even more complicated (yes, the “quirks” factor again). So in addition to the simple unit tests, there will be more of testing of interactions:
    • Functional testing.
    • It will be a common thing for the integration servers have nightly runs of functional tests on multiple virtual machines.
    • Diagnostics and configuration validation modules will be more common in complex solutions.
  • There’ll be new component packages and development solutions that promise to make Mono development as simple as drawing a couple of boxes and assembling these together (these always do show up on any frontier).

4. There’s also the psychological factor – people will be more willing to invest in the software solutions that work in the both worlds or enable existing solutions to do that.

So the next years are going to be fun. Do you see here the opportunities of turning these consequences to your advantage?

If interested, stay tuned as I’ll be talking more about the LIM architecture of Landor and the changes we plan to make in order to simplify its transition to Mono.