Is Apple coding Leopard to run Windows apps natively?
Or just making life easier for Parallels and VMWare?
Is Apple covertly working on a direct Windows application compatibility for Mac OS X? Some observers have suggested that it may well be after it was discovered that Leopard will attempt to load Portable Executable (PE) files when asked and even try to find relevant Windows Dynamic Linked Libraries (DLLs).
Leopard's PE support was uncovered by one Stephen Edwards, who'd been working with Wine, the open source version of the Windows application programming interface (API). He found that Leopard's Dynamic Linker (Dyld) will try to load a PE file. Soon after, Leopard's hunt for DLLs referenced by the PE file appeared as further evidence that the presence of PE support may not simply be a hang over from Apple's use of the Extensible Firmware Interface (EFI)
PE is EFI's standard method for encoding executables. So what is PE? It's essentially a way of packaging an executable application, associated resources and code libraries into a single unit. Mac OS X already does something broadly similar with its applications, bundles and frameworks: stores them all in a well-defined folder structure that the user interface presents as a single entity, making it easy to move them around without losing key elements of code.
While the appearance of PE handling in Leopard and the OS' incorporation of EFI might simply be a co-incidence, it's been found that Tiger doesn't handle PE files the same way as Leopard does, indicating the behaviour incovered by Edwards and others is new to Mac OS X 10.5. Indeed, Wine forum posters have shown that Tiger emphatically rejects attempt to load PEs.
Still, it's a big leap to suggest that Leopard's behaviour is a sign of Windows support to come. Firstly, Leopard isn't a simple upgrade to Tiger - there's clearly been more work done under the hood this time round than between Tiger and Panther, and Panther and Jaguar before that. It's entirely plausible that Apple's coders didn't get round to disabling PE support in Leopard as they did in Tiger.
More likely, though, is that this is a tweak made to help the likes of Parallels and VMWare more tightly integrate their Windows-on-Mac tools with the host operating system. Parallels in particular tries to allow Mac users to run Windows apps as if they were native applcations rather than apps running on Windows running in a Mac OS X window.
Apple's keen on this approach. During his Worldwide Developers Conference keynote last July, Steve Jobs lauded Parallels' and VMWare's apps as improvements on Apple's own Boot Camp, which is more about running Windows on Mac hardware than running Windows apps within Mac OS X itself.
Boot Camp, Parallels Desktop and VMWare Fusion are all useful tools to persuade Windows users to switch to Apple hardware, particularly in the business world. It's a strategy that may not succeed, of course, but it's not one that's hard to implement - virtualisation's part of the Intel chips Apple is using these days - but may just pay dividends.
The downside with virtualisation is that it limits the CPU resources available to host and guest operating system, though as processors gain more cores, that will increasingly become less of a problem.
The question becomes, is it better for Apple to improve Mac OS X's support for third-party virtualisation apps in the meantime or go the whole hog and implement the Windows API - or, rather, an API that's compatible with it - into the operating system?
COMMENTS
Cringely's Thoughts
Remember Steve Jobs' first days back at Apple in 1997 as Interim-CEO-for-Life? Trying to save the company, Steve got Bill Gates to invest $150 million in Apple and promise to keep Mac Office going for a few more years in exchange for a five-year patent cross-licensing agreement? The idea in everyone's mind, of course, was that Microsoft would grab lots of Apple technology, which they probably did, and it quite specifically ended an Apple patent infringement suit against Microsoft. But I'm told that the exchange wasn't totally one-way, that Apple, in turn, got some legal right to the Windows API.
That agreement ran for five years, from August, 1997 to August 2002. Even though it has since expired, the rights it conferred at the time still lie with the respective companies. Whatever Microsoft grabbed from Apple they can still use, they just aren't able to grab anything developed since August 2002. Same for Apple using Microsoft technology like that in Office X. But Windows XP shipped October 25, 2001: 10 months before the agreement expired.
I'm told Apple has long had this running in the Cupertino lab -- Intel Macs running OS X while mixing Apple and XP applications. This is not a guess or a rumor, this something that has been demonstrated and observed by people who have since reported to me.
http://www.pbs.org/cringely/pulpit/2006/pulpit_20060420_000893.html
.net
it's more likely to allow the use of .net code on the platform - allowing developers to use C# makes *good* business sense. Allowing native windows apps to run on OS X would make *no* business sense: good-bye all non-apple os x native software of any importance.
@amanfromMars
Ok, that's it! Where's the real amanfromMars, and what have you done with him??!
-dZ.
drawing parallels
"Parallels in particular tries to allow Mac users to run Windows apps as if they were native applcations rather than apps running on Windows running in a Mac OS X window."
Umm, why Parallels in particular?
The Unity mode in VMWare Fusion seems to do a pretty good job to me of making the Windows apps in my Dock just run as another app.
Re: Karl
Thanks for the answer.
IMHO I think Apple has proven well enough that they are a decent open source citizen. Not the best, not the worst, but certainly not deserving of the description "ripping off the good will of the open source community"...
