Advancing Software Reuse of Linux, Windows Code on the Mac
December 17th, 2007
Daniel Eran Dilger
Apple appears to be following up its successful strategy of enabling code reuse of software designed for Unix/Linux through work on new efforts to sample existing code tied to Windows. Here’s what’s involved.
The Open and Shut Case of Mac OS X.
Over the last decade, Apple reinvented the classic Mac OS into a new platform that leverages open commonality with other Unix-like operating systems, while also offering specialized software interfaces for delivering custom Mac software. The result is that Mac OS X supports three classes of software:
- Fully open and/or interoperable software, such as POSIX code and 100% Java.
- completely original software developed with Apple’s proprietary Cocoa and Carbon libraries.
- a hybrid of the two, leveraging available open code libraries with a sophisticated Mac interface.
While it is becoming an increasingly smaller problem, not all of the world’s useful code happens to be available as an open source library. Lots of proprietary code is still developed only for Windows, including specialized drivers for certain hardware devices and other utilities and tools that have no open support from their makers.
Currently, tapping into software which is neither natively Mac compatible nor available as open source typically requires booting a Mac into Windows or launching an environment such as Parallels Desktop. Either alternative involves some significant drawbacks.
Red Box Rumblings.
In addressing the discussion about Mac OS X 10.5 Leopard’s somewhat mysterious new support for the Windows PE executable format, I attributed Apple’s work to support for Intel’s EFI firmware rather than evidence of an impending Red Box rapture that would result in converting Mac OS X into an alternative way to run Windows applications.
This idea of Mac OS X being a temporary host for the eggs of a new Windows parasite is popular among Windows Enthusiasts, who assume that the root of every problem in the world is “not enough Microsoft.” This thinking is so pervasive that it even trickles into the Mac-centric media on occasion, particularly when Mac sites need to generate a spark of Dvorak-style, “correct me if I’m wrong, and you know I am” link baiting controversy.
A parallel software issue exists for users of Linux: despite having access to a large portion of the world’s best code, Linux users, just like Mac users, often have need for running software or using devices that were only ever designed to work with Windows. The growth of the Mac hardware platform is making that problem less critical for Mac users, but it still exists.
One DIY solution on Linux is to use Wine, which is neither simple nor broadly capable of running everything, but can be very useful for certain applications in the hands of knowledgeable users with tempered expectations. The more consumer-oriented audience of Mac users is less likely to be happy with the current state of Wine; nobody could argue that Mac users have “tempered expectations.”
PE U: The Mac OS X Leopard Windows API Myth
Windows DLL Sharing?
Responding to my comments in “PE U: The Mac OS X Leopard Windows API Myth” some developers wrote to suggest the idea that Apple may be building tools to appropriate portions of closed Windows code in the same way Mac OS X can make use of Unix/POSIX libraries.
In Windows, code is often delivered as a series of dynamically linked libraries called DLLs. These provide building blocks of functionality that in some cases could be drawn upon to build native Mac versions of Windows utilities and drivers, considerably simplifying the efforts third parties would need to do to deliver Mac ports of their software, and also enabling third parties to port some tools without any direct support.
If this is the case, it would expand the Mac software library and provide additional options to users who work with obscure hardware that currently only works under Windows. It would also skirt around the impossibly complex barriers in front of the Red Box.
Solving the Red Box Issues.
Building support for executing Windows code within DLLs doesn’t require full emulation of the entire, unwieldily “Windows API,” which is changing and will continue to evolve under the direction of Microsoft.
It also wouldn’t require anything near the development or support resources involved in delivering the Red Box, because it wouldn’t have to meet the unreasonable requirements of being able to run anything one could dig up. The Red Box is a product idea that would find it extremely difficult to please anyone, no matter how close to perfect it became.
Enabling Windows code reuse by developers also wouldn’t put existing Windows environment software out of business, sparing Apple from the contempt of angry users upset about the immediate obsolescence a Red Box would throw in the path of the developers of Fusion, Parallels Desktop, and similar products.
It would also prevent any sort of “OS/2 Effect” from occurring. With the presence of a hypothetical Red Box, that might happen if Windows developers decided they might as well just deliver their same Windows apps on the Mac rather than delivering ports that actually took advantage of Mac features.
By enabling portability of core Windows code, developers could contain their porting efforts to creating a familiar, custom Mac interface that took full advantage of Mac features. This would make little difference to end users; Mac apps are Mac apps, regardless of whether their core code were based on open source libraries, custom written Mac routines, or Windows DLLs.
In Cider the Apple.
Similar code sharing efforts have long been commonplace on a different scale by third party developers such as Microsoft and Adobe, who deliver Office and Creative Suite cross platform using their own custom engines wrapped up in a native interface on both platforms.
A newer development on a larger scale is happening in video games. Products like TransGaming’s Cider libraries allow game developers to port Windows games to the Mac with minimal code changes. This has been criticized by some as a shortcut that will virtually ensure natively developed games never appear for the Mac; I have a different outlook that I’ll put in an upcoming article.
But first, what prospects are there for incorporating Windows code into Mac applications on the scale suggested by Leopard’s new support of the Windows executable format? Take a look at Apple’s cooperative yet competitive position in open source development. Apple does more to benefit open source efforts than most people recognize, as the next article describes.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!