Virtualization: Extremes Of The Emulation Spectrum

This blog post references my cover story ‘Virtualization: Silicon And Software Salvation Or Technological Tower Of Babel?‘ in EDN’s October 3, 2008 edition. It’s one of a series of web addendums to the print writeup.

While virtualizing an entire operating system on top of another operating system (or a thinner hypervisor) compiled for the same CPU architecture is all well and good, it’s overkill in some situations. Say, for example, you want to just be able to run one or a few Windows applications on OS X; in that case, virtualizing an entire Windows build would far overshoot your needs. Alternatively, consider an application such as Wine (for "Wine is not an emulator"…akin to GNU aka ‘GNU’s not Unix’).

Wine’s developers claim that it’s not an emulator, and I suppose they’re right…at least in the strictest sense of the word ‘emulator’ (which I’ll get to next). Wine doesn’t emulate hardware; instead, it emulates (or if you prefer, translates) Windows APIs such that Windows applications can natively run on Unix-based O/Ss…including Linux and OS X. After 15 (no, that’s not a typo) years of development, Wine 1.0 was released in mid-June, just in time for my use in advance of the cover story’s publication. CodeWeavers’ various Crossover products are commercialized versions of Wine with additional ‘polish’ and support programs…analogous, for example, to Red Hat retail variants of Linux.

In my meeting a few weeks back with VMware, Fusion product marketing representative Peter Kazanjy accurately characterized the Wine developers’ battle with Microsoft as a cat-and-mouse game. Every time Wine’s backers reverse-engineer an API, Microsoft extends it or adds others, basing the latest versions of its (and partners’) applications on the newcomers. Peruse Wine’s Application Database and you’ll clearly see the end result. The Platinum (run flawlessly) and Gold (run flawlessly with some special configuration) lists are dominated by obscure or older programs, with newer (and therefore most desireable) applications relegated to Silver (minor issues) status…that is, if they’re supported at all.

I’m still using the 2003 version of Quicken Basic as my financial management package. When I run it virtualized via VMware Fusion, the regular (albeit brief) ’stutters’ I experience wreak havoc with the program; during data entry, they irritatingly cause the cursor to spuriously skip from cell to cell. I therefore endeavored to instead try running Quicken Basic 2003 on OS 10.4 via Wine. Specifically, I used v1.0 of Darwine, an OS X-tailored Wine variant (I also tried ‘unstable’ then-v1.1.3 but experienced an ‘unsupported device’ error message during Quicken installation).

The end result is sufficient for a power user, albeit nowhere close to ready for the general public. Initial installation completed successfully but, when I was subsequently prompted to register the program, the pop-up screen was blank. The same thing happened when I attempted to do an online update. Both windows, it seems, rely on HTML rendering, which I can’t get to work (the first time I tried to run Internet Explorer virtualized, I was prompted to download the Gecko rendering library, but although I accepted the invitation, the subsequent auto-install seems to be ineffective). Fortunately, I found another way to do the upgrade.

Quicken 2003 Basic runs noticeably faster under Darwine than it does virtualized via VMware Fusion. By mapping an appropriate drive letter in Darwine, and by ensuring that I have the relevant network drive partition already opened in OS X’s Finder before launching Quicken, I can even regularly back up the database to my NAS from within the program as has long been my fashion when running Quicken on Windows. Just don’t redefine the default ‘Z’ drive definition; the applications bundled with Darwine will subsequently refuse to run, and manually resetting the definition to its original value won’t restore the function. You’ll need to completely purge Darwine from your system and reinstall from scratch.

On the other end of the emulation spectrum, you might still own (as I do…two…) an older Power PC-based Mac on which you want to run Windows. The task is much more difficult in this case, since you’ll be virtualizing all aspects of the Windows-targeted hardware, notably the CPU. PowerPC and x86 instruction sets are completely different, of course, and endian issues for data accesses also require consideration. Whereas G4 and earlier versions of the PowerPC architecture included an x86-compatible ‘pseudo-little-endian’ mode, this capability was dropped from the PowerPC 970 (i.e. ‘G5′).

While my past experiences with Microsoft’s now-discontinued Virtual PC for Mac bear out the program’s functional robustness, the Windows XP-inclusive application certainly didn’t break any speed records…understandable, since it was doing on-the-fly instruction-by-instruction translation between x86 and PowerPC binaries. I’ve also used Rosetta, an application-level virtualization scheme that Apple licensed from Transitive and built into OS 10.4 and OS 10.5 (but not the upcoming x86-only OS 10.6 code-named ‘Snow Leopard’) as a means of enabling Apple customers to continue running their old PowerPC-compiled programs on new Intel-based hardware. Rosetta-assisted programs ran noticeably faster the second (and subsequent) times I launched them, suggesting that the Transitive-developed algorithms cache dynamically recompiled binaries for future use.

Followup: While on the topic of emulation and Microsoft, don’t forget about the frankly incredible job the company did getting a large number of x86- and Nvidia graphics-compiled (PC architecture, basically) first-generation Xbox titles to run (and at impressive frame rates, complete with resolution upscaling, to boot) on the Power PC- and ATI/AMD graphics-based Xbox 360. Both Virtual PC for Mac and (I suspect) this console emulator came from the same Connectix development group that Microsoft acquired back in 2003.