De Tout Et De Rien

Some people have noticied that the new major release of Monobjc was lacking of OpenGL support. I am currently working on it and have finalized the new bindings. There will be more complete and flexible, and I expect to provide several sample applications (NSTimer based or Display-Link based) to demonstrate the bindings. I have also started to port the NeHe lessons.

It is been a while since I blogged about Monobjc. Some people may have thought that the project was in sleep (or worst dead), but it is not.

I work on Monobjc on my spare time, which means that the project does not go as fast as I would. And as the last six months have been quite harsh for me on the business side, I spent very few hours on the Monobjc project. But, now that the situation is back to normal, I can dedicate more resources to the project.

In this post, I will try to summarize the current state and the future of the project.

I am working on the next iteration of the Monobjc project now for eight months. It can be considered a very long time, but the current design has proven to reach its limits when I was working on two new main features: categories and 64 bits support.

As for now, the Monobjc project is lacking on the following points:

• The support for PowerPC architectures is broken since Mono 2.6. I spent a lot of time to figure why Monobjc crashes on Mono 2.6 when it was working perfectly on Mono 2.4. Note that this issue is bound to PowerPC only.
• The support for 64 bits systems. Now that experimental build of Mono can be built, it would be great to have access to the power of 64 bits architecture in Monobjc applications.
• The support for categories is missing. Even so it does not seem important, I think it is a really handy feature to add to subclassing and composition. It works the same way as extension methods in .NET.
• The support for blocks. This addition from Mac OS X 10.6 is used extensivly in the new APIs.
• A proper set of tools, including a decent MonoDevelop plugin set.

A New Design

The PowerPC issue and the 64bits support are part of the same approach. The current design, mostly managed code, is too hard to debug or to alter in order to support a new architecture properly. So I sat down and though about the most efficient architecture that would allow a transparent support of 32/64 bits architectures and maybe solve the PowerPC support issue. I came to the conclusion that the managed side of the bridge was too clumsy.

The design I came to will be based on a custom Mono runtime, containing the Monobjc extensions (messaging, bridging, class registration, etc). It is close to what you can find in others Cocoa/XXX bridges like RubyCocoa or PyObjc. With that design, the managed code of the bridge is greatly reduces as well as the manipulation of the native structures. The diagram below summarized the idea:

What does it means for every developpers ? Well, almost nothing. The tooling part of Monobjc will take care of the custom runtime and the changes are minor. This leads to a painless migration when transitionning to the new design.

More Unit Tests

While working on the categories, I realized that the Monobjc project was not tooled enough for regression and unit testing. The current state of the unit tests is pretty awful, so the next iteration of the project will focused on a better support for unit and regression testings.

Flexible Wrapper Generation

For almost three years, I used several tools to generate the Cocoa wrappers, which involves scapping sources, fixing it by hand to have a decent result. But when dealing with new classes, it is not sustainable anymore. That why I decide to rethink entirely the wrapper generation. This is an ongoing work, but the result can be seen by cloning and building the monobjc-generator project on GitHub.

MonoDevelop Integration

The current state of MonoDevelop integration is pretty light. The plugin set was created by Eric Butler but its maintenance requires a lot of work, and the project is now considered D.O.A. Speaking of proper tools, the MonoDevelop plugin set will be of course part of it.

What about MonoMac ?

As stated in this post, the choices will favor developers. The Monobjc project remains dedicated into providing the best .NET/Objective-C bridge, along with a proper tooling. What is important to me is to provide a complete toolchain that enable developers to focus on their application instead of the development process.

Conclusion

That is all for now. I hope that my fellow readers will find this information useful. I am eager to get some feedback on that and on the Monobjc project in general.

Monobjc 2.0.313.0 was released on December 2008, the 17th. One major addition in Monobjc is the support of Sparkle update engine. Sparkle is one of the most used framework in the Cocoa world, as it makes updating an application a breeze. The main problem with Sparkle in Monobjc was the private framework embedding. With Sparkle, updating a Monobjc application has never been so simple. Check out the tutorial for Monobjc and Sparkle.

Many people want to package their .NET application for Mac OS X. And above all, they want the experience to be painless, which means that they want to ship an application that runs, whether Mono is installed or not.

The process of packaging a .NET application for Mac OS X basically follows 4 steps:

• Getting .NET dependencies of the .NET executable
• Generating a native loader that will embed all the .NET assemblies (.NET executable and .NET dependencies)
• Getting native dependencies of the native executable
• Relocating all the stuff so library loading goes well

The process can be even more complicated if you are using reflection, dynamically discovered library and so on. So let's keep thing simple.

Getting .NET dependencies

This is the easy part. You just have to find recursively all the .NET dependencies of the .NET executable. As every .NET assembly contains its references, it is trivial.

Generating a native loader

The native loader generation is simplified by the fact that Mono allows .NET assemblies to be loaded from embedded binary streams. So for every .NET assembly, we generate a binary array and use the magical functions of Mono. If there are configuration files to embed, the process is the same.

Getting native dependencies

Once the native loader is compiled, the otool command can give us all the native dependencies. So we gather all the native library needed to run our application. But on Mac OS X, the dynamic loading is based on paths recorded in each native library. This is the point of the next step.

Relocating all the stuff

This is the tougher part of the packaging. Now that you have all the native dependencies, you must be sure that you only have unique dependencies. Why, because we you gather dependencies, you can find either specific version of a library or compatibility version of a library. Failing to make these reference unique can lead to unexpected behavior (mostly cryptic crashes). That where the otool command is useful as the first line always contains the specific version of a library, even if run against a compatibility version symbolic link. Then the install_name is used to change absolute path to relative path containing the macro @executable_path.

Packaging made easy

All this steps can be tedious and error prone. That's why, in the Monobjc, the packaging is done by a NAnt task: <mkbundle/> (you can find its options on this page). This task can handle most of the need for .NET application packaging in a truly simple way. And as a bonus, this task is not linked to the Monobjc bridge, so you can use it even if you don't use the Monobjc bridge.