Previously in this blog I wrote an article about using STK Engine with mono (see here). At that time, mono supported running a purely analytical STK Engine application, but with some limitations. One of the limitations found was the lack of proper support for passing arrays as parameters to the STK Engine methods (i.e. marshalling of COM safearrays between managed and unmanaged code). Since then, I have contributed two patches (r136836 and r149817) to the mono code base that address these issues. The first patch made it into mono 2.6. The second patch just got incorporated last week into the mono trunk, which prompted this update.
In the initial article the second example (“Second console application”) was not working properly under mono. With these two patches it now works correctly (at the head of trunk), both on Windows and Linux. The code for that application is unchanged and was included in the initial article.
Here are the updated outputs, first when running this example under Linux/mono, then Windows/mono and Windows/Microsoft .NET.
Mono on Linux output:
STK Engine console application running under Mono on Linux
Mono/MS .Net on Windows output:
Same STK Engine Console Application running under MS .Net and mono on Windows
This is an important step for making it possible to use STK Engine with mono on Linux. However there are still some limitations:
- Events do not work (due to the lack of late binding support in mono).
- The globe and map controls are still an issue. ActiveX controls are not supported. I have an idea about adding this to mono. I have developed an early prototype. However a lot more work is needed before these changes could be incorporated to the mono code base (and, to be honest, that might never happen). As a teaser, here is a video showing a basic Windows Form application with a globe control running under mono on Linux:
I would love to see that proof of concept for the ActiveX control, we would like to make sure your software runs on Linux well.
What do you think prevents the code from being contributed to Mono?
Do you think that the Ax support would be too specific to your app?
If that is the case, perhaps just having a Mono/host as opposed to a full blown Activex control host would be a solution?
Miguel.
Comment by Miguel de Icaza — January 31, 2010 @ 1:27 pm
Miguel,
Thanks for your comment. Here are the answers to your questions.
Question 1: I would love to see that proof of concept for the ActiveX control.
Take a look at AxHost.cs. This is the implementation that I used to get the ActiveX control to work with mono (both on Windows and Linux). Basically it relies on the ActiveX hosting capabilities exposed by ATL.DLL. On Windows the Microsoft version of that DLL is used, while the equivalent Mainsoft/Mainwin library is used on Linux. We have successfully used a similar approach to expose our ActiveX controls to Java.
Question 2: What do you think prevents the code from being contributed to Mono?
At this point the implementation is probably not complete enough. This is just a proof of concept. More work is needed to make it generic enough for general availability in mono. Also I was not sure if the approach relying on ATL.DLL would be acceptable for mono (would it be?). Another option is to write a full ActiveX host, but that requires more effort.
A couple of other missing pieces to fully support ActiveX controls are the current lack of IDispatch and COM event support in mono (that’s also pretty involved).
So basically these missing features are workable. I might look at contributing some of them to mono, but they require some non negligible effort, which is why I mentioned in the blog that it might never happen…
Question 3: Do you think that the Ax support would be too specific to your app?
So far I have implemented only the strict minimum to get the example shown in the blog up and running. However what I did is not specific to our application. So that approach would work for any ActiveX control… It just needs to be implemented for the entire AxHost class.
Question 4: If that is the case, perhaps just having a Mono/host as opposed to a full blown Activex control host would be a solution?
That’s effectively an option. That would reduce the amount of testing to just our ActiveX control. Now it also means that we would need to maintain a separate Mono/host with each release of our Linux APIs. Also to be useful we would need the COM events to be available somehow. From our perspective it would be better if we could roll the ActiveX support into mono itself… That would also benefit the overall mono community.
What do you think?
Thanks,
Sylvain
Comment by Sylvain — February 1, 2010 @ 1:50 pm