Thanks, VMWare!

For a while now, folks in the Mac world have been agog about Parallels Workstation, a tool that allows Intel-based Macs to run Windows in a virtual machine, thereby allowing Macs access to whatever Windows-only software they need to run, but in a protected environment where Windows malware can’t hurt the rest of the machine. It’s a good tool.

Eventually, VMWare released a competitor, and given their background in virtualization, Fusion quickly became a better (more stable, more efficient) tool than Parallels. We bought a copy with our new MacBook Pro.

Well, said MacBook Pro developed an early fault, so it had to be swapped. No problem; moving machines in the Mac world is dead easy. There’s no need to reinstall software packages from disks or disk images, since the proper way to handle apps on a Mac is to create an “application bundle” that looks and acts like an executable, but is in fact a special class of directory containing the app and all its support libraries, executables, etc. What doesn’t go in the bundle is any sort of configuration information; that gets stuck in either your home directory’s ~/Library folder (for user settings), or in the computer’s own /Library folder (for global settings). It’s a nice, neat system, and one that makes managing a given machine MUCH simpler than the morass of crap you deal with on a Windows box.

Well, comes now VMWare, who are apparently eager to fuck it all up. When we tried to fire up VMWare today for the first time on this new computer, it behaved as expected and requested we paste in our license again. Several apps have asked for this in the last few days because license codes and authentication are stuck in the computer’s /Library folder, which we didn’t bother carrying over — it just wasn’t worth the hassle, since we have all the codes handy anyway, and the standard Apple behavior is that anything missing in Library should be reconstituted from the application bundle. (Remember, we have our personal settings in our own ~/Library, so we didn’t walk away from those.)

Except plugging in the code didn’t work. VMWare just sat there, doing nothing — no error or anything. We called the support line and got a singularly clueless drone who knew zero about Macs despite working support for a Mac product; his first suggestion was that we uninstall and reinstall (how Windows! And ironic, considering what came later!). It was us, actually, who discovered the problem: in our Mac’s console log, we found VMWare errors complaining of a path not found.

2007-09-21 14:30:19.062 vmware[4078] launch path not accessible

Yup. VMWare apparently sticks things it can’t afford to lose in /Library, and standards be damned. The support drone also told us that — get this! — Fusion also sticks some executables in /Library, such as its uninstall routine and a few other goodies. “That’s just how we designed our software,” he says.

The mind boggles.

There are guides for this sort of thing, you know. It’s not just an oral tradition. There’s a right way and a wrong way, and VMWare, for whatever reason, chose poorly. We’re now waiting for the 160 megabyte download to finish so we can re-install the one package brain-dead enough to require it. Thanks, VMWare! Not even Microsoft screws up on the Mac this well!

Comments are closed.