DevExpress products and Mono (part 1 - WinForms)

02 October 2009

Recently I took it upon myself to do some testing with our products and Mono. We've been asked often in the past about Mono compatibility, and given the recent release of — and excitement about — MonoTouch, the number of these questions have increased.

The first trial I did was with our WinForms controls, because I was fairly certain it would be a fairly simple conclusion and as it happened my experiment validated my guess.

First things first, though. Although Mono does have complete support for creating WinForms applications, there is a big issue in my view, especially when you consider third-party controls. Suppose you're targeting Mac OSX and by happenstance our WinForms controls work in Mono. You write a WinForms app with XtraGrid and XtraBars and the rest, deploy it, and... it just looks like a Windows app running on a Mac. It looks wrong, it doesn't fit in. You might get away with it in the corporate environment but, for the wider Mac audience, you'd be laughed out of court. Far better would be to have a set of WinForms controls that look like native Mac controls. And that, of course, we don't have (although you could get close with our McSkin I suppose Smile).

Onto the actual test. The Mono Project have this nifty program that analyzes your application and assemblies for possible problems when running under Mono. It's called MoMA, the Mono Migration Analyzer. I downloaded it and ran it on our big demo for XtraGrid, in the belief that I might as well go for broke. That's me all over: put it all on red.

image

Firstly, cool, everything we use in .NET is present in Mono and I'm particularly glad we don't have any methods that throw NotImplementedException. Obviously, we provide you with fully implemented classes in our products. That's a relief.

The second item there is the warning I was most definitely expecting: the P/Invoke problem. This particular application (and the assemblies it uses) uses 23 P/Invokes.

A reminder. A P/Invoke (Platform Invoke) is the .NET term for a routine in a native DLL that you call from within managed code. The DLL, in most cases, is part of native Windows: we don't go for writing our own native DLLs for our .NET products. Here's a couple of examples of such a routine (taken from XtraBars):

[DllImport("user32.dll", CharSet = CharSet.Auto, ExactSpelling = true)]
public static extern IntPtr GetFocus();
[DllImport("user32.dll", CharSet = CharSet.Auto, ExactSpelling = true)]
public static extern IntPtr SetFocus(HandleRef hWnd);

Here the P/Invokes are getting references to the GetFocus() and SetFocus() routines from user32.dll, a pretty important DLL in Windows.

The issue with P/Invokes and Mono is that these native Windows system DLLs do not exist in other operating systems. Sure, other OSes are likely to have something functionally similar, but they won't be in a DLL called user32.dll, and even if they had similar names, they might have different signatures. We'll come back to this in a moment.

Let's take a look at the P/Invokes in this particular application:

image

I'd have to say there's nothing particularly out of the ordinary here. Most of the P/Invokes we use are out of user32.dll and deal with the keyboard and mouse.

Actually I suppose you could argue that we've got references to certain Windows routines all over the place, and that we should aggregate them into some DXNativeWindows assembly and reuse that. I won't argue, and in fact, if we were to fully support Mono, that's essentially what we would have to do. Once we'd done that, it should be then be easier to implement and provide DXNativeMacOSX and DXNativeLinux assemblies as well, for deployment on those platforms.

For interest, here's the detail for the final warning item:

image

Some of these might be cause for concern ("useEmbeddedColorManagement isn't supported"? Qué?), but I admit to not having done too much research on them as yet so I don't know how difficult they'd be to work around. The P/Invokes are a bigger problem to my mind.

Now we're at the end of this particular post, I'd have to say, given my results, our providing WinForms Mono support for every possible platform is going to be very low priority. Providing WinForms Mono for a specific platform (say, Mac OSX) is more of a possibility, apart from the problem I mentioned early on: Our controls were designed and implemented to look good on Windows. I'm going to guess we would have a fairly heavy-duty bit of design work to make them look good on the Mac, and that's before we factor in the work we need to do to research and implement the Mac OSX equivalents to the Windows routines we're using.

Unfortunately, given the other opportunities we have to tackle on our main platform, it's unlikely we'd be devoting resources to this project in the near to middle future. The opportunity cost is just too high at the present time.

Next time: ASP.NET.

Tags
21 comment(s)
TheCodeMonk

While I haven't done it yet, the ASP.Net test should be much different. That shouldn't be an issue....

2 October, 2009
Julian Bucknall (DevExpress)

Aaron: Indeed, as you will see in part 2. However there are other issues to consider. Oh, the joys...

Cheers, Julian

2 October, 2009
Glen Germaine

Excellent post Julian. A disappointing conclusion but not at all unexpected.

I guess the upside is that it makes the path to Silverlight look even brighter.

Cheers.

2 October, 2009
Neal

You have to ask yourself "Why" use Mono and not just use VMWare Fusion, Parallels, Bootcamp and all the options for a person to actually run your .NET DX app on a MAC.  But the thing these people using MAC's want to be as far away from as possible is Microsoft and of course Windows.  That's the big reason they are there.  It's not security, there are articles on how Snow Leopard is less secure than Vista.  It's not software availability, we all know the MAC market is far slimmer on application choices.  And it's certainly not cheaper anyway you look at it.

So...long story longer, they just don't want anything to do with Windows and if you choose VMWare Fusion, Parallels, or Bootcamp, they still have to buy a Windows license and still feel like they are in Windows again, which they don't want.  So this is where MONO comes in, just run my app on MAC natively so I can get Windows out of the equation.

If we instead focused on the iPhone, which is the real bridge for people to cross the border of Windows vs. MAC, then I'd think we'd see more sticking around with Windows.  In comes MonoTouch.  There's still a lot to learn (for me) on MonoTouch and I'm always hoping the Visual Basic support isn't far off.  I read it's not a complicated task, it's just the time needed to do it.

So anyways, when you ask yourself "Why not just use VMWare Fusion, etc." it's because they want Windows out of the loop.

3 October, 2009
Ludo Vandenbempt

Excellent article.  Maybe it's possible to get help from your clients.  They are all developers and some of them have also Mac and/or Linux Skills.  Probably some of them would like to help out to provide an implementation per platform of the required Windows dependant functions.  So for DevExpress the work can be limited by externalizing, like explained in the article, the OS dependant functions into a seperate DLL.

3 October, 2009
Samuel Mukoti

Nice article, I've been crossing my fingers for a longtime and would can't wait for XtraGrid and family to come to Linux and mac! I read ago that some devs did look at doing at Gtk# port but found many things missing on the Gtk painiting engine, I've been using Qt# lately "Qyoto" it's very nice.  All it is, is .Net binging for the popular Qt framework (Now owned by Nokia) the advantage with it is it looks native on windows, Linux and Mac, if you wanted to push out some mono specific controls then your mac, Linux and windows customer could use the very same control! I really wish Qt was the default windowing toolkit for mono as it seems to be light years ahead interms of functionality.  Please don't loose heart.

Lastly might I digest that if your budget for time & resources is tight please push the work that u need to the open source world, I'm even sure Novell would be willing to put a team to work on the DLLs u might needs just so we can have the awesomeness that we've come to know and love from the Devexpess team!

Just my 2cents

3 October, 2009
Yianni Bourkelis

There is also WineHQ.

In the AppDB, NET Framework 2.0 has a GOLD status.

appdb.winehq.org/objectManager.php

It might be easier to run net framework 2.0 applications with P/Invoke calls on WineHQ, because WineHQ implements many windows native dlls for every supported platform (linux/unix/macosx)

3 October, 2009
Karl Rostock_2

Hi,

I have 3 macs and each has bootcamp, 2 with vista 1 with Win7 and they all work great, Apple have tried immensley hard to ensure if a customer wants to use windows aswell as a mac os they not only allow you to do this but they practically do it for you with bootcamp and also providing all the drivers you need to get there hardware running on windows its a fantastic marketting strategy and i for one am very glad of the 24" imac performance its outstanding (but so is the price :-()

Thanks

Karl

4 October, 2009
Jeff Weir

A couple of questions:

You ran Moma tbe big XtraGrid demo. How many DevEx products does that demo include? Are all the P/Invokes listed related to the XtraGrid control?

7 October, 2009
Nathan

There's a lot of 'chicken or the egg' here.  The fact is that we developers control much of our end users choices.  The problem is that so many developers have been singularly focused around how they can get the greatest return on investment in their deep knowledge of one operating system, that they entirely forget the fact that choice is what makes things better.  We even use terms like 'religious' arguments about platforms, but really they are self-serving arguments supporting the developers perception of their own ego.  So Windows developers want Windows customers.  Mac developers want Mac customers.  Linux developers want Linux customers, etc.

Ultimately no one other than the big corps who own these technologies win from these arguments.  But ultimately if we all want to see technology evolve into newer and better places, and take us along with it, we need to ensure that our customers have choices.  Choices create competition in the free-market and that competition results in greater inventiveness.  If you think back 7 years to the dawn of Windows XP and then compare it with Win7 coming out, its a bit of an embarrassment to us computer scientists that in 7 years this is all we could come up with?

I don't care if you are a Windows, Mac or Linux fanboy.  The truth though is that if you care about evolving technology, you have to develop in such a way that your end users have the most choices.  Mono, IMHO, is not the answer.  The Linux community are considering it a risk to freedom, and are Stallman just last week has gone gunning for anyone associated with it.  FreePascal/Lazarus might be a better option for cross compatible development from what I've experienced.

7 October, 2009
George Raby

Julian,

With regards to your "Firstly, cool, everything we use in .NET is present in Mono and I'm particularly glad we don't have any methods that throw NotImplementedException. Obviously, we provide you with fully implemented classes in our products. That's a relief." comment;

Although I'm guessing, the check for "NotImplementedException" I believe is mainly to test for the exception being thrown in Mono library code. Where a Mono library isn't 100% implemented some methods may be stubbed this way. The compatibility tester would look for these occurrences. If you are lucky you can still get away with using a non-100% Mono library as long as you aren't calling any of the obscure methods that haven't been implemented.

7 October, 2009
antimonio

I wonder if you can change all those P/Invokes to Win32 DLLs with P/Invokes to a cross-platform library which provides the same functionality. The one I know about is gdk. As it's open source, you could grab gdk sources for the Windows platform to look for the functions you're calling, to find out what gdk functions call them, so you can call those functions instead.

7 October, 2009
Chris Shouts

I agree with Ludo - why not open source this effort? This is exactly the type of project where open source shines.

7 October, 2009
Pedro Alves

I know a member of the development team of Mono.

They is interested in helping companies who want to make their applications compatible. You should contact Novell.

It would be a great plus for the DevExpress. The Telerik already announced support for ASP.NET controls in Mono.

7 October, 2009
Andreas Grabmüller

My personal opinion: Getting those WinForms UI controls to work with Mono on Linux and Mac OS X makes no sense, they would look completely wrong.

However, there are components where it would make much sense: XPO for example, and XtraReports and also XtraCharts. When developing a cross platform application, you would probably code a native interface for those platforms, but you should be able to use the same data acces and business layers and use the same reports on every platform...

7 October, 2009
Scott Ahten

As someone who primarily works on Mac OS X and uses Ruby on Rails, Winforms support isn't high on my priority list. Most of my web projects are developed in Ruby on Rails. However, I occasionally work on ASP.NET applications for clients who specifically request it.

Currently, I use Parallels with Windows XP (soon to be replaced with Windows 7) and Visual Studio. But I would be interested in moving to Mono Develop if it could be used interchangeably with VS for web development.

As for the desktop, I haven't had any requests for porting existing Winforms apps to the Mac. I use XCode and Obj-c / Cocoa for building Mac desktop and iPhone applications.

7 October, 2009
Ian Kemp

Please strongly consider modifying your ASP.NET controls so that they run on Linux. Although WinForms controls would also be nice, it would be easier to port the ASPx controls (as websites are platform agnostic) and of course, the controls are skinnable so designers can make them look however they want.

It would be great if I could develop my ASP.NET applications using DevX controls in Visual Studio, then simply copy the app and all its associated DLLs onto a Linux + Mono box and have everything just work.

As already stated in a forum post, I would be happy to help with this effort, if possible.

8 October, 2009
Jason

If you did make everything use a native dll that doesn't comply with mono directly, why not open source that dll and let other people worry about implementing the platform support that they need for mono?  Since I completely agree getting your components to work on all platforms and supporting that also making sure they look good is a lot of support for a small demand.

8 October, 2009
Nicolas COUSSEMACQ_1

You should definitely put all P/Invoke code in separate DLLs and give the opportunity for the open source community to do the work, if possible.

I really would take some time to participate in this if it could make my software run on Linux and MacOS.

12 October, 2009
Richard Adams

I'd also be up for helping with this.  I'm in the process moving some of our internal tools over to Linux / Mono and I'd dearly love to keep my DevExpress interface in place.

24 December, 2010
Stefan Zschocke

Where is part 2? Still interested in Mono for Aspx article

23 October, 2012

Please login or register to post comments.