Rubénerd!

Parallels Desktop was one of the first pieces of software I discussed in detail on this blog back in 2006. Now five years later, I'm giving it another try!

I need a bigger hard drive

When I first got my new Intel MacBook Pro in 2006, I hurriedly installed the first betas of Parallels Desktop onto it to fuel my virtualisation obsession. I appreciated that the support team were so... supportive... of someone attempting to install and use FreeBSD of all OSs on their software, and were more than happy to help me out.

Several months later though, VMware announced their Fusion product and I made the move, mostly because I already had invested time and money in their Workstation product for Windows and liked that I could move things over. Businesses I do... business... with also tend to use VMware products, ditto my university.

I've also used VirtualBox, and more recently QEMU to run my bizarre mix of FreeBSD, Windows 2000, OS/2 and PC DOS 2000. All have worked fine, but each product has different problems with one of the aforementioned systems. VMware Fusion doesn't like some of my ancient DirectX games like Train Simulator. VirtualBox has issues with upper memory managers on DOS. QEMU doesn't have 3D acceleration at all, and can't boot OS/2.

The reality is, I'll most likely be keeping all four virtualisation applications on my Macs, but one day I'd love to have one to do it all.

Parallels 7

Installing Parallels Desktop on my Mac Pro on Thursday evening, I was struck by how much has changed. Unsurprising given the last time I used it was 2006, but the software fits right into Mac OS X Lion, complete with the dark patterned backgrounds that seem to be all the rage these days. I was a little disappointed at their icon change, but I suppose the Windows logo makes sense given its what most of their customers will use it for.

FreeBSD, Windows 2000 and PC DOS 2000 installed without incident, though I had a few issues installing the Parallels Tools in Windows 2000, a subject for a future post when I'm over this flu and am not typing blog posts at glacial speed.

The virtual machines generally felt more responsive than VMware Fusion, and substantially more so than VirtualBox. What set Parallels apart however was its ability to run all my classic DirectX games such as Midtown Madness, which VMware Fusion simply couldn't do, at least on my hardware. SimCity 3000 also ran stunningly well.

Another aspect where Parallels shone was the company's technical support. Despite being an unpaid, trial user, within hours of voicing my problems on Twitter, @ParallelsMac and @ParallelsCares had provided feedback. Others should learn from their example!

Overall, while Parallels is a different ecosystem to what I need for work and uni (which will necessitate me keeping VMware Fusion as well), for those Mac users looking for the simplest, slickest way to run virtual machines, I'm thoroughly impressed with Parallels. I'll be running out the 15 day trial, then registering a copy.

After eight years of continuous development, QEMU 1.0 came out on the first of December. After assembling our Christmas tree this afternoon, I set to work building it on my Mac :).

Screenshot of my venerable MacBook Pro running Windows 2000, Windows 3.11 for Workgroups under PC DOS 2000 and FreeBSD 8.2 in the all new QEMU 1.0 :). All fully licenced I might add, I don't run pirated software thank you very much!

My build environment

• I like to build my own sources in the default /usr/local like a good FreeBSD-heritage guy, its one of the reasons I went back to MacPorts from Homebrew. Use --build-target during the ./configure stage to change the default.

• To save myself time and only install what I need, I generally only build i386 and alpha. Don't specify any and you'll build them all by default.

• I can't get enough of that authentic retro adlib sound, so I build the optional support for this too, along with the widely supported (and also optional) AC97. You can safely ignore these and it will build with default Sound Blaster 16.

• If you're attempting to build QEMU on a case-insenstive file system, you may run into an error with softfloat.h. I've since written a post about how to fix this.

Installing from source

1. Log in as root (or the closest we can get to it on OS X):
   

   % sudo -s

2. Grab and extract the latest sources, in this case the glorious 1.0! I put mine in /usr/local/src to keep things tidy.

3. Configure with the options you want, for all the available options, use the --help flag. In my case:
   

   # ./configure \
   --enable-cocoa
   --target-list=i386-softmmu,alpha-softmmu \
   --audio-drv-list=coreaudio \
   --audio-card-list=ac97,adlib,sb16 \
   --disable-vnc

4. Now build:
   

   # make
   # make install
   # make clean distclean

All done

Huge amount of thanks to Fabrice Bellard and all the QEMU committers for their incredible amount of wok over these 8 years. I use your software on a daily basis for work and play.

Now all we need is isapc support back ;).

After much head scratching, I finally got retro MIDI sound working in Windows 3.11 and PC DOS 7 in QEMU! Wow, that was a mouthful. Here's how you do it, with a caveat.

Execution Summary

In its default ./configure-ation, QEMU emulates a Sound Blaster 16 card which can be detected and used in Windows 3.1 with the bundled Windows Sound Blaster 1.5 drivers. Unfortunately, with MPU401 disabled this means no MIDI support, on any guest OS. As of writing this post, there's no way around this.

Fortunately, QEMU also emulates Ad Lib, that early generation sound system that pre-dated SoundBlaster and has rudimentary MIDI support. Like SoundBlaster, Windows 3.11 can also use it out of the box without additional drivers.

As a caveat: if you install any drivers for Sound Blaster before or after doing this, Ad Lib apparently loses control of MIDI and subsequently you don't hear anything. I've yet to find a workaround for this, but as soon as I do, I'll post it here.

Building QEMU with Ad Lib support

For what I've been told are performance reasons, QEMU doesn't include Ad Lib support by default. Browsing the hundreds of pages of duplicated documentation online, I was told the solution to this was to build QEMU with the following option:

./configure --with-adlib

This no longer works. This does:

./configure --audio-card-list=sb16,adlib

I use QEMU exclusively for older OSs and have no need for the other sound cards it supports; if you want others you'll want to add them there.

Windows 3.1

This should be a blast from the past for those of you who did this back in 1992... I was 6 at the time! My earliest memories of our first home computer were with a Sound Blaster card, so this was new to me :).

1. Fire up your QEMU DOS VM (that's a lot of acronyms), then launch Windows 3.1. If you needed to be told that, how did you build your own custom version of QEMU?

2. Go to Control Panel, then Drivers.

3. Click Add..., choose Ad Lib from the List of Drivers, and hit OK. You'll be prompted for a Windows 3.1 install disk, or you can put in a different path. I tend to keep setup files on the virtual drive C for this purpose; it's not like I don't have space for it!

4. Quit Windows, then launch it again. Ah the days when rebooting your "OS" was that simple!

5. Go back to Control Panel and choose MIDI Mapper. Choose Ad Lib general from the Name list box, then hit Close.

All done! Now you can launch Media Player and play CANYON.MID in all its electronic, MIDI glory!

Why are you running Windows 3.1?

While its come in incredibly handy for a few paid jobs (spur of the moment things that earn some serious brownie points, then later more seriously!), our first family home computer ran Windows 3.0 and later 3.1.

My ultimate goal is to recreate that first system with all our classic software and games on my modern hardware. I've got all the original disks, made images of them, and am ready to go! I'm a sucker for nostalgia :')

Want to regularly emulate a guaranteed system crash or even a BSoD? Install VMware Fusion 3.1.2 build 332101 and follow me!

Windows 95

1. Create a new VM and install any version of Windows 95
2. Select Install VMware Tools from the Virtual Machine menu
3. Wait for the VMware Tools CD to automount and autostart
4. Budda boom! Kernel crash!

Windows NT

UPDATE: This issue has since been resolved in version 3.1.3, as I talked about here!

A simple crash dialogue box like that not enough? Well how about a fully blown kernel panic blue screen of death!

1. Create a new VM and install any version of Windows NT 4.0 and either the high or regular encryption version of SP6.
2. Select Install VMware Tools from the Virtual Machine menu
3. Install any combination of the available VMware Tools you'd like
4. Reboot, enjoy the show!

As I blogged about in 2007, I've been a paid VMware Fusion user since Version 1 and have bought all the upgrades. Glad to see these new features being introduced :).

Seriously though, it sucks that I have to have VirtualBox on my Macs to run OSs that a product from a premier company like VMware should be able to handle, but lately can't. Tested the same configuration on my Mac Pro, my MacBook Pro and my sister's MacBook with the same results. Oh well.

More out of interest sake than being under any illusion of practicality, I decided this evening to try running SpinRite in QEMU on my Mac Pro. The verdict: it works, if you have lots of spare time!

Notes before proceeding

I tested this on a Mac Pro, running SpinRite in QEMU on a non-system drive. I would assume if you booted Mac OS X off an external drive you could try this on your machine's system drive as well, but your mileage may vary.

QEMU is easy enough to build yourself, or its available on Homebrew, MacPorts, Fink and pkgsrc.

Finally, this action is allowing software raw access to your drive, so be extremely careful about getting the labels and identifiers right. Backup your stuff. Do at your own risk!

The procedure

1. Go into Disk Utility, click the drive you want to run SpinRite on, then go to File → Get Info. Under the "disk identifier" heading you should see a string called disk[number]. Make a note of it.

2. Use Disk Utility to unmount the drive. If it says the drive is busy but you're sure you're not doing anything with it, you can force eject it with its shell sibling:

% sudo hdiutil eject -force /Volumes/[label]

2. Temporarily assign yourself ownership of that volume:

% sudo chown [your username] /dev/disk[number]

3. Fire up a QEMU session:

% qemu -hda /dev/disk[X] -cdrom spinrite.iso -boot d

From here on in, its just like SpinRite on a regular machine... although an order of magnitude slower!

Don't forget when you're done to return permissions to root on the drive:

% sudo chown root /dev/disk[number]

Why go to all the trouble?

SpinRite is a preventative hard drive maintenance utility that is run off a bootable FreeDOS image burned either to a CD or run off a floppy disk. Unfortunately, while it boots on Intel Macs, the software requires BIOS level access to drives which EFI obviously fails to provide. As a consequence, the keyboard doesn't work and even if it did, the drives wouldn't be accessible.

One potential workaround is to physically remove internal drives from Macs, install them in a regular PC with a BIOS and perform SpinRite on it. While this works, its terribly clumsy and doesn't lend itself well to performing regular maintenance as Steve Gibson suggests we use it.

This got me thinking whether or not it can be virtualised. Provided the software had raw access to the drive, theoretically one could create a virtual machine, boot off the SpinRite ISO image and have it do its thing. I'd tried it using raw access in VirtualBox before, but it was complicated to configure and ran as slow as molasses.

Turns out, using QEMU to do this on a non-system drive is fairly simple, though just as slow. Oh well, you live and learn!

My full review of VirtualBox 4.x is coming, but for now I can confirm the upper memory bug for PC DOS still exists. Guess I'll be using VMWare Fusion and/or QEMU for proc-control stuff for a while yet :(

Conventional memory

Bill Gates infamously quipped that nobody would ever need more than 640KiB of memory, and that's exactly how DOS sees it. Regardless of how much RAM your computer has, many DOS applications will never see more than the first 640KiB. This area is referred to as Conventional Memory.

Over time power users worked around this limitation by using so-called expanded and extended memory managers which allowed applications and drivers (that supported it!) to load themselves "high" or above this 640KiB memory area. This means extra RAM in systems could be used, and it also kept as much Conventional Memory free for older software, games and drivers that demanded it.

Unfortunately, using UMB (upper memory blocks) was always a bit of a voodoo science, and even today some software has issues with it. QEMU, VMWare software and Connetix Virtual PC (RIP) allow full UMB access, however even the latest versions of VirtualBox still have severe stability issues when used with upper memory managers.

EMM386

The EMM386 expanded memory manager that was bundled with several DOS-based versions of Windows and later versions of DOS. If it is loaded in CONFIG.SYS in its default form like this:

DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE /VERBOSE

... it results in the following error upon boot:

WARNING Unable to set page frame based address--EMS unavailable

While undesirable, on machines where this capability is unavailable the NOEMS flag can be used:

DOS=HIGH,UMB
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE NOEMS /VERBOSE

This allows the machine to boot, and does allow drivers and applications I defined in AUTOEXEC.BAT and CONFIG.SYS to be loaded high.
Unfortunately, if you attempt to mount any CD-ROM or floppy disk images in the VirtualBox virtual machine, EMM386 halts the system with this same error.

EMM386 has detected error #13 in an application at memory address 0048:061F. To minimize the chance of data loss, EMM386 has halted your computer.

To restart your computer, press ENTER.

Needless to say, having a virtual machine that only partly works and only if no media is mounted is a deal breaker.

UMBPCI.SYS

Those of you who've kept up to date with DOS developments of late know about this brilliant alternative to EMM386 that was first featured in Germany's c't magazine and now lovingly maintained to this day by Uwe Sieber. The primary advantage UMBPCI.SYS it has over EMM386 is it uses a fraction of the memory, which is obviously A Good Thing.

Unfortunately, while UMBPCI.SYS plays brilliantly with QEMU and VMware, VirtualBox fails to load it at all upon boot if its defined in place of EMM386 in CONFIG.SYS

No unused memory block found

Conclusions

DOS is still a more commonly used system than I think many people appreciate, but I also acknowledge the limited resources a free software project like VirtualBox has to maintain support for so many different client OSs. I can appreciate that.

For now, if I want to run this DOS software l'll be continuing to use QEMU on my OS X, FreeBSD and Linux boxes for DOS. Which is a shame, because having a high performance cross-platform VM tool to rule them all would sure make my life easier.

Finally, people like to pick apart my posts as of late, so here are some points that before I wouldn't have bothered with ;). I am aware of DOSBox and FreeDOS. They do a great job. Unfortunately the software I need to run is not compatible with either one. PC DOS 2000 is still the most broadly compatible DOS distribution I've ever used, and have a lot of time invested in it. QEMU and VMware run it just fine, so I'll have to stick with them.

Oh and I'm aware that icon is of MS-DOS-Tan and NOT PC DOS, but one has to make do with the resources at hand ;).

One of my New Year resolutions was to do more with people's feedback here, so here I go making good on that promise! I got an email this morning from a reader wanting to know how to mount floppy disk images in VirtualBox virtual machines.

Le steps

VirtualBox has support for floppy disk images, but unlike optical and hard drives its associated controller isn't enabled in new VMs by default. Fortunately, that's easy enough to fix.

1. From the VirtualBox GUI, choose the VM you want to modify and hit Settings
2. Choose the Storage tab
3. Under the Storage Tree, click the second icon with a green plus and choose
   "Add Floppy Controller"

Now when you start that VM, there will be a floppy disk icon in the status bar which you can right click and mount floppy disk images with, without all those horrible noises and slow speeds of REAL floppy disks! Its magic, I tell you ^___^.

In the default open dialog box it will only let you choose standard RAW/img files, but I've been able to also use vfd files without problems.

While DOSBox is a great piece of kit, sometimes you may have more speciailised DOS needs that require the use of a VM. In my case, I use QEMU and so far things are working great.

Getting it

The first step, surprising though it may seem, is to grab QEMU. Fortunately it's well enough known that most package managers carry it, even MacPorts and Homebrew on OS X do. Its relatively small and builds quite fast.

Creating a disk image

For my needs, raw images work just fine, plus they have the added benefit that they can be easily mounted on the host to modify its contents later.

QEMU comes with the qemu-img utility for creating disk images. This line will create a 500MiB raw disk image:

% qemu-img create -f raw dos.img 500M

Booting a virtual machine

This will start qemu with an extravagent 8MiB of RAM, dos.img as the master drive on the first virtual IDE channel (as a regular machine would probably be configured) and with our bootable PCDOS.iso image in the virtual CD-ROM.

% qemu -m 8 -hda dos.img -cdrom pcdos.iso

From hereon in, its as if you're installing DOS on a regular machine. Relive the glory days of frequent system crashes, conventional memory ceilings, three finger salutes and those dark blue setup screens!

Mount the disk image on the host

You'll want to shut down QEMU first (no, really?), then as root mount the disk image to a mountpoint of your choosing. *nix systems would typically employ the loopback device for this.

# mount -o loop,offset=32256 dos.img /mnt

Now you can access and transfer your precious DOS files :)

Justification

Why use QEMU over VirtualBox or other souped up virtualisation software?

QEMU is simple, no messy GUIs to get in the way. It's portable, and the disk images it uses can be easily mounted on the host just like a regular drive without having to convert it first, even on machines that don't have QEMU. And finally, speed isn't really an issue with DOS, so I'd rather have the convenience ;)

Why do you run DOS Ruben?

I seem to always attract troll comments on posts such as this! One of the things I moonlight as is a DOS and CP/M guy, setting up VMs for clients so they can access data locked into obscure file formats and/or abandonware applications. Also for process control software that companies still depend upon but can't use natively on modern hardware. And finally, Commander Keen. HAPPY?

You can use a real, physical drive as a bootable hard disk in Sun Oracle VirtualBox using an undocumented feature, and it even works on Mac hosts!

First make sure the drive is unmounted (aka ejected), it won't cause errors if it's mounted when you attempt this, it simply won't work.

VBoxManage internalcommands createrawvmdk \
-filename [NEW DRIVE NAME].vmdk \
-rawdisk /dev/disk3

Replace the /dev/disk3 with the block identifier that represents the physical drive you want to access, in my case USB and FireWire drives. You can right click any drive in Disk Utility.app to find out what that is on Mac OS X or your fstab file.

This command essentially creates a pointer to the raw physical drive which you can then add to any virtual machine, just like any other virtual drive. As with creating it though, if it's mounted on the host it won't work. Also this command is undocumented and subject to change, so if the above syntax doesn't work they may have changed it since I wrote this up.

Because it enables raw file access, I'm assuming lower level tools like SpinRite can be used in a virtual machine this way, but I have to confirm this.

For more information, I found this VirtualBox forum topic insanely useful with plenty of relevant links.

Sometimes a short train trip late at night through the Marias Pass train route in northern Montana with the 2001 era DirectX graphics and sky is just what I need to relax just before going to sleep.

I first got Train Simulator in 2002, it was the first game I tried on my desktop at the time, the first game I tried running with Boot Camp with my then-new MacBook Pro in early 2006 (Windows gaming on a MacBook Pro), and is still one of the reasons I keep a copy of Windows XP lying around for the 3D acceleration in software like VMware Fusion.

For someone who moved around so much as a kid and could never have huge trainsets, this was the closest I ever got, and I still find it fun :).