tgwbd.org

Home | Blog | Darwin | WOCompatibility

sign in

David Elliott

Welcome to my personal site. At the top you should see some basic section navigation. You may be interested in reading my blog or perhaps you are interested in my work on the Darwin/x86 bootloader or in the WOCompatibility hack for the WebObjects tools.

About Me

My life's work is computing with a primary focus on software development. For a short list of work accomplishments and objectives please see my short-form résumé.

My career as a software developer is defined by variety of work and depth of knowledge. I have been in many corporate work environments ranging from being the sole developer and deployer to being a member of a small information services team to being a member of a team responsible for one piece of a much larger environment. I have also had the opportunity to develop software and design solutions for clients. In every case I have worked with my clients to design software that exceeded what they had imagined.

In addition to my professional work I have taken an interest in a handful of open source projects. Many people know me for my work on the Darwin/x86 bootloader and other related projects and ideas. Other people know me as the creator of the wxCocoa port of the wxWidgets toolkit. I've also contributed code and ideas to various other open source projects as I saw fit.

My varied work history has required me to learn and know many programming languages and environments. Of these I am most fond of the Mac OS X platform and the Objective-C language paired with the Cocoa frameworks. In a twist of irony some of the most rewarding work I've done has involved standalone programming (i.e. boot code) where assembly code and processor registers and tables are the law of the land.

Personal Projects

Darwin/x86

Many people know me by my initials (dfe) as the original designer of the BIOS-to-EFI compatiblity portions of the Darwin/x86 bootloader (boot-132) which netkas later dubbed and marketed as the "EFI Emulator". To the best of my knowledge I was the first person to realize that the Darwin kernel could be made to run without modification on a non-EFI BIOS-based machine. This was only the first of many further ideas that eventually resulted in VMware Fusion supporting the installation and running of factory-sealed DVD copies of Mac OS X Server on Apple hardware.

Eventually the work I did for VMware begat an improved version involving SYSLINUX as a first-stage loader followed by integration of the disk image loading code into the main booter. The combination of the bootloader and other ideas provided a shining light leading the way to a modern OS X on x86 effort.

More information about my ongoing efforts can be found on my Darwin/x86 page.

wxCocoa

wxCocoa is, as the name implies, a port of the wxWidgets toolkit running on top of the Cocoa toolkit provided with Mac OS X. The wxWidgets toolkit is rather unique among cross-platform toolkits in that it is implemented in standard C++ and uses each platform's own controls instead of implementing cross-platform generic controls.

Although I haven't been able to work on wxCocoa for some time I still believe that wxWidgets and wxCocoa provide a unique and valuable cross-platform toolkit. Because of differences in user expectations no cross-platform toolkit can ever provide a proper Mac user experience unless the application developer writes some Mac-specific UI code. Attempting to write a Mac-like UI experience in any other toolkit but Cocoa's AppKit quickly becomes an exercise in frustration to anyone who has attempted it.

With wxCocoa you aren't forced between a rock and a hard place trying to either write Mac-like UI in a cross platform toolkit or to cross a language barrier like JNI so you can take advantage of the native Cocoa features. You especially aren't required to cede all control of the application to some cross-platform ideal that never quite manages to act correctly on Mac OS X.

For a truly Mac-like experience you can turn the normal cross-platform design around. Start with an Xcode template for a native Cocoa app then use wxCocoa to pull in your cross-platform UI elements. You can even use wxCocoa in somebody else's app. If the app supports Cocoa plugins then you can use wxCocoa in your plugin to take advantage of cross platform UI code. It is known to work in Cocoa Print Dialog Extensions in both 32-bit and 64-bit mode allowing cross-platform UI to control printer features. You may have already used a UI developed with wxCocoa without ever having known it. Other good examples are Preference Panes for the System Preferences application and plugins for Photoshop CS5.

All of this and more is possible with wxCocoa. Once you build it and link it into your pure-Cocoa app or plugin you may call into wxCocoa and embed your wxCocoa controls and forms inside pure Cocoa views simply by changing the file from Objective-C (.m) to Objective-C++ (.mm). There is no language barrier to cross. Mix and match platform-native and cross-platform UI with ease.

If you are interested in wxCocoa I suggest you visit wxwidgets.org and join the wx-users mailing list. I'm not actively seeking any work on wxCocoa but if you have a need do not hesitate to contact me at dfe@tgwbd.org.

WOCompatibility

Out of frustration with earlier versions of the Eclipse-based WOLips tools I attempted to make the legacy EOModeler and WebObjects Builder applications work on Leopard and then Snow Leopard. With Leopard, Apple removed some undocumented code from libSystem that only legacy NeXT apps like the WebObjects tools were using. Fortunately this code had been open sourced so it wasn't too difficult to figure out a way to rebuild it and force WebObjects Builder and EOModeler to link with it. With Snow Leopard Apple removed some extremely undocumented code so even with WOCompatibility, WebObjects Builder cannot work.

You can still visit the WOCompatibility page but it isn't really going to do you much good anymore. The Eclipse-based WOLips tools have improved somewhat. It's still Eclipse, not Xcode, but what can you do?

About this site

The site navigation is provided by a custom WebObjects-based app I wrote. It involves some unusual coding, including a custom request handler. I wrote a 3-part series of blog entries on it called "The Duke of URL" if you are interested.