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?