Daniel Eran Dilger in San Francisco
Random header image... Refresh for more!

Advancing Software Reuse of Linux, Windows Code on the Mac

200712161906
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.”

 Wp-Content Uploads 2007 12 200712050332

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.

What do you think? I really like to hear from readers. Comment in the Forum or email me with your ideas.

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!

Technorati Tags: , , , , ,

19 comments

1 UNIX Coding School » Blog Archive » unix code [2007-12-17 07:26:27] { 12.17.07 at 4:34 am }

[...] Advancing Software Reuse of Linux, Windows Code on the Mac By danieleran 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. (more…) RoughlyDrafted Magazine – http://www.roughlydrafted.com [...]

2 brett_x { 12.17.07 at 11:07 am }

I’m a bit confused, I’m sure someone can clear this up. Daniel seems to be arguing against WINE, but for TransGaming’s solution. What is the difference? Is it that WINE’s goal is to try to translate all Windows API’s vs. the Cider solution is to build custom libraries based on the API’s that are already used by specific developers?

3 gus2000 { 12.17.07 at 12:20 pm }

Thanks for the article, Daniel. I think it’s important that Windows developers have a streamlined porting process for compiling OSX-native apps. Still, I dread the day when my Mac spits out the message “O32XLA17.DLL NOT FOUND. PLEASE INSERT INTO DISK A:”.

4 lmasanti { 12.17.07 at 1:11 pm }

When AppleScript was introduced loooong time ago, it was spotted as a “program to program interface” for applications.
In other words, a “good” application would have a clearly defined (and separated) UI and “send events and messages” to the processing units.
One interface would be windows and menus, the other AppleScript.

This “view” maybe is what it is trying Apple… Make a new user interface to a “[Windows] processing code”.

Insightful article. Thanks, Dan.

5 northernsoul { 12.17.07 at 1:59 pm }

brett_x, the difference for the purposes of this article I believe to be that of who the target audience for these products are. Without going into the history of what happened to make these separate products separate in the first place, Cedega is something that is sold and geared towards game studios who would like to port their software to OS X, while Wine is something meant to be run by end users.

6 Pascal { 12.17.07 at 2:27 pm }

“Similar code sharing efforts have long been commonplace on a different scale by third party developers such as Microsoft and Adobe”

Indeed they do and that was the beginning of a continuous quality fall for Adobe. From my experience with a graphics software like Illustrator I can date the downfall with version 5.0. I believe this is the version they ported from Windows instead of developping it for the Mac resulting in a slower, less stable, crappy, crash lover soft. Hell they lost what I considered their all time advantage against Freehand : snappy response, efficiency and and extremely readable details even in working mode display !

7 FloydThreepwood { 12.17.07 at 2:46 pm }

Don’t forget the example of OpenOffice for Mac wich still is Beta in a Cocoa look. And so OO doesn’t matter in the Mac world. I hate to think about what would happen if native Windows software seemlessly runs on every Mac. Still its the UI that diffenentiates us from the rest. If you followed the AppleInsider articles about Office 2008 and iWork 08 you can see how different the Interfaces realy are.

Using the Windows UI on a Mac feels wrong, because the behaviour is not common on OSX, so why should these Apps run on it? It would only alienate the os ro the Max. And still I think about the controversy about the different Graphical Skins from Metal to classic Aqua, wich finaly is resolved in Leopard. If that makes such a difference I don’ want any Windows app in my aqua bubble!

8 cgervais { 12.17.07 at 2:56 pm }

Located way in the bowels of Mac OS X (and it’s been around for awhile) is CFPlugInCom.h. Apple has shipped a standard method for calling into Windows DLLs for sometime. However, it’s not just a case of picking your favorite Windows DLL and calling functions from your app (that would require access to the broad Windows API). What it is (and was) useful for is libraries of independent code bundled as a DLL. In fact, I think this is how Apple integrated iChat with AIM initially, through code to use the OSCAR protocol in a DLL.

9 Pascal { 12.17.07 at 3:02 pm }

Dan, would it be possible for posters to edit their post since it’s obvious I’m a bit short in the proof reading department ?

10 johnnyapple { 12.17.07 at 7:02 pm }

I thought “Red Box” was similar to OpenStep in that it would theoretically install Cocoa libraries on Windows systems, not a compatibility environment to run native Windows code on OS X. Wasn’t that what the Red Box under Rhapsody was originally planned to do?

If Apple is working on ways for Windows developers to re-use much of their code to port applications to the Mac I assume they wouldn’t do so at the cost of system stability. If that’s the case, then sure, OK.

I’m looking forward to more in this series so I can better understand what this is all about. Interesting, I’ll have to be patient.

11 wordwarrior { 12.18.07 at 12:11 am }

“Fully open and/or interoperable software, such as POSIX code and 100% Java.”

100% Java?

Well, considering that Apple still hasn’t delivered Java 6 for OS X, despite it being available for Windows, Linux and Solaris (and FreeBSD Ports) since November 2006, not to mention the slew of GUI bugs introduced to Java 5 on Leopard (read the archives for java-dev@lists.apple.com if you don’t believe me), I would quantify Apple’s implementation of Java as totalling far less than 100%.

12 vanfruniken { 12.18.07 at 11:19 am }

Don’t overlook the fact that the application package format includes a subfolder called MacOS. This seems to be easily extended with a folder Windoze.

13 cgervais { 12.18.07 at 1:13 pm }

vanfrunike, that may be an artifact of the NeXTStep roots of Mac OS X. There used to be folders for HP-UX, Solaris, etc. I don’t know how Apple would translate their packaging format to Windows — why wouldn’t their build process just build a .EXE? Why would they ship a Windows binary within a Mac OS X package?

14 FloydThreepwood { 12.18.07 at 3:46 pm }

What has that to do with the article? Adding something to a convention of folder and package design is not the problem. Sure it’s easy to extend this, but extending OS X to run anything that could be hidden in a Windows folder is a whole other story.
I would like to see Microsoft and Apple to cooperate in Software buisiness as far as installing Windows XP (no Vista is only for Pro pc people from Dell and Lenovo) by default on new Systems und abandoning OS X. Zune rules, gray is the new white, and clumsy overtakes elegant!

15 danieleran { 12.18.07 at 5:31 pm }

@ johnnyapple: Red Box has always been related to Windows, although I’m not sure that Apple ever directly used the phrase, and I’m sure it never used it related to anything running on the Mac

Yellow Box was the NeXT+Cocoa environment (a superset of what is now considered Cocoa), intended to be portable. It was the same as the OpenStep specification.

It contrasted with Blue Box, which was the Classic Mac OS, or Carbon. Those definitions have blurred over the last ten years.

Red Box was only ever suggested as a possible way for PCs to run Windows programs alongside Yellow Box on Rhapsody. A Red Box was never released, and anyone who used OpenStep/Yellow Box in the late 90s typically was running the OS/YB layer on top of Windows NT, and getting their Windows compatibility “for free.”

@ wordwarrior: “100% Java” describes cross platform Java code that runs anywhere, as opposed to using the Java language to write Cocoa or Windows apps, for example, or using any libraries that are tied to a specific platform.

Despite all the noise about Java 6, it has almost no impact on the ability to run 100% Java code on the Mac. It is important for Java developers to have the latest tools from Sun (6 = version 1.6, rather than 1.5) in order to do certain kinds of work, but the vast majority of Java programs don’t require anything specific to the last two version of Java.

@vanfruniken: I believe the MacOS folder related to extending the existing Universal binary support inherited from NeXT in a way that made it straightforward to add to the classic Mac OS a way to launch Carbon apps in the form of bundles.

It would be unnecessary and impractical for Apple to create a bundle architecture for Windows (instead of delivering an exe like Quicktime, iTunes, Safari do), and the ability to run Windows DLLs on Mac OS X wouldn’t require any more than including them as library recourses, just as developers now do with FOSS based Mac apps.

16 johnnyapple { 12.18.07 at 5:53 pm }

Duh, ya, I’ve clearly got my colors mixed up. It was ten years ago ;-) I’ll have to search the archives for Yellow Box stuff and refresh tired brain.

17 wordwarrior { 12.18.07 at 9:48 pm }

Dan,

There are several significant API changes in Java 6:

http://java.sun.com/javase/6/webnotes/features.html

To make a long story short, there are API extensions to collections, JDBC , I/O, and Swing, among others.

This means that anybody writing code that makes use of the new Java 6 APIs will not be able to run that code on OS X.

Granted, the changes in Java 6 are much less reaching than those in Java 5. Also, unlike Java 5, there are no actual Java language changes in Java 6.

So you’re right that the changes aren’t far reaching, but they are significant. You can say Apple has implemented 95% of Java 6 APIs and 100% of Java 5 APIs. However, it would be extremely charitable to call it “100% Java”.

Also, some Swing and Applet functionality was broken by Apple’s Leopard Java 5 update, as described in the Java-Dev mailing list. I haven’t followed closely, but to my knowledge, there has not yet been an update to Leopard (as opposed to Tiger) Java 5 since the release of Leopard.

Also, don’t forget that Apple is well behind Sun on Java security fixes. IMO, security fixes are not discretionary, and should be pushed out ASAP.

[Yes, I'm not making excuses for why Apple hasn't shipped Java 6 support, I'm only clarifying that "100% Java" is not a measure of how much of the latest Java spec is currently implemented, but rather relates to Java apps that are not platform specific. - Dan]

18 WWDC 2008: Is Mac OS X 10.6 the Death of Carbon? — RoughlyDrafted Magazine { 06.07.08 at 8:59 pm }

[...] on Windows the next iTunes? Safari’s Controversial Potential as a New Yellow Box for Windows Advancing Software Reuse of Linux, Windows Code on the Mac Mac OS X 10.6 Snow Leopard, Carbon, and the Future. While Apple clearly wants developers to use [...]

19 Myths of Snow Leopard 5: No Carbon! — RoughlyDrafted Magazine { 06.24.08 at 9:18 am }

[...] Advancing Software Reuse of Linux, Windows Code on the Mac 64-bit Face Off: Carbon vs Cocoa. That also makes it more clear why Apple changed its tune on providing new 64-bit interface APIs in both Carbon and Cocoa. The original story was that Apple would advance both. Last year, however, Apple announced it would not be implementing a 64-bit Carbon interface. [...]

You must log in to post a comment.