By Ruben(nerd) Schade, a UTS university student and IT guy in Sydney and Singapore. c.2004
To drastically improve virtual drive performance of qemu guests, create images with metadata preallocation:
% qemu-img create -f qcow2 -o size=2147483648,preallocate=metadata disk.qcow2
Then if you're on Linux, use fallocate to preallocate space:
% fallocate -l 2147483648 disk.qcow2
Passing this on for what it may be worth, they both saved me a lot of time copying files this morning. :)
If QEMU 1.0 fails to build on Mac OS X (as I described on Sunday), you may be attempting to do it on a case-insensitive file system, like I just tried to do!
If you're installing QEMU on a case-insensitive file system, you'll need to modify the ./fpu/softfloat.h header file. Apply the patch from here, or simply open the file and add the following lines:
56 typedef uint8_t flag;
57 typedef uint8_t uint8;
58 typedef int8_t int8;
59 #ifndef _AIX
60 #if !(defined(__APPLE__) && defined(_UINT16))
61 typedef int uint16;
62 #endif
63 typedef int int16;
64 #endif
It should build without problems now, you unsigned integer you.
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!
/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.
% sudo -s
/usr/local/src to keep things tidy.
--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
# make
# make install
# make clean distclean
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 ;).
I had feedback from a reader of my QEMU Ad Lib MIDI in Windows 3.1x post asking how I got Sound Blaster working in it. I give people what they want! ^_^
Creative and Sound Blaster are from Singapore, I've been to their offices! I always liked their 1990s-tech logo :). But I digress.
QEMU has Sound Blaster support in its default configuration, and Windows 3.1 has drivers that can be used by default, which makes our lives much easier.
You can download drivers from the Sound Blaster support website which will give you a mixer, but I'm a fan of minimalism and I didn't notice any real performance or quality benefit from doing so. If you elect to use these drivers instead, remember the installer needs to be run from DOS BEFORE you launch Windows.
As a caveat, as I mentioned in my Ad Lib post, I've yet to find a way to allow both emulated sound cards to coexist in Windows 3.1. When Sound Blaster drivers are installed before or after Ad Lib, Sound Blaster assumes the roll of MIDI, which isn't supported in QEMU (hence the use of Ad Lib in the first place). As soon as I know a solution to this, I'll post about it.
1. Fire up your QEMU DOS VM and start Windows 3.1. Launch Control Panel and choose Drivers. Have a sudden urge to play Wii golf. No wait, it would have to be Microsoft Golf 2.0 MME ;). Why do I bother blogging about anything else other than retro stuff? I missed my calling.
2. Click Add..., choose Creative Labs Sound Blaster 1.5, and hit OK. You'll be prompted for your Windows 3.1 setup files.
3. In the Sound Blaster Setup window, choose Port 220 and Interrupt 5.
4. Windows will tell you the driver is installed, however we should "contact Creative Labs for a driver specific to your card". Just hit OK. How did people live without the WWW?! I suppose one could have got drivers from a BBS, right?
Now you can go into Sound in Control Panel or launch Sound Recorder and play all the chiming chord dings that you want! :)
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.
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.
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.
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!
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 :')
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!
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!
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]
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!
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.
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.
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
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!
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 :)
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 ;)
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?
Q running retro Windows NT 4.0, FreeDOS with OpenGEM and MS-DOS 6.22 with Windows 3.11
Due to some silly distractions I had to postpone my reviews of Mac virtualisation software. Today's review is for Q.app, a free and open source native Mac port of the QEMU processor emulator.
Q.app can be described in one word: svelte! In a download that weighs in at under 10MiB, this tiny application can create and run fully contained virtual machines; it's very impressive! It's also clear a lot of care and attention has been put into the interface: because it's a native Cocoa port the interface feels like a real Mac application and the guests you create are bundled into native OS X packages.
ASIDE: As a matter of disclosure, I am not affiliated with the Q.app project or QEMU, nor was I given a financial incentive to positively review their application, though now it's after the fact I would be more than happy to accept such payments. Thank you.
Because Q.app uses QEMU it doesn't have the sophisticated performance or graphics of much heavier (and far more expensive) apps like VMware Fusion which I've previously blogged about, but apps that require those kinds of resources aren't the intended use of it anyway.
Provided you use more modest operating systems instead of trying to shoehorn Windows 7 or Ubuntu with Gnome into it, it's very usable. Windows 2000, the BSDs and lighter distributions of GNU/Linux run just fine. Windows 95 and DOS (including the latest FreeDOS) absolutely scream! As with any VM software, the key is finding the oldest OS that can run the software you need, unless you intend on using the Internet in it for security reasons.
Windows 2000 and FreeBSD 7.1-R also run just fine.
I have had some stability issues with Q on my first generation Core Duo MacBook Pro, and the Q drivers to enable a Samba share between my Windows 2000 guest and my Mac stubbornly refuse to work, but I'm willing to chalk both these problems up to a problem with the operator not necessarily the software! My iBook G3 was obviously slower, but didn't have either of these issues.
If you need to run a application written for another OS (or with caveats perhaps even another processor!) and you don't have time or inclination to register for and download a huge product like Fusion or Parallels, or if you're like me and just want to run a ton of older OSs for silly nostalgic reasons, you can't go wrong with Q.app. The folks behind this app have done a great job.