Qemu disk image conversion

I see that there is some confusion over how to convert disk images from various popular emulators, and I thought I’d try to clear some of this up. Without a doubt, the best free tool available for this is qemu-img. And it’s free! Currently as I write this, that makes Qemu 0.14.0 the current version. I’ll cover the common ones that I use.

For the most part for Qemu I used the qcow2 format. Naturally you can use any of these formats in Qemu… While others are limited.

Converting from..

Virtual PC source image..
To convert to a qcow2:

qemu-img convert source.vhd -O qcow2 destination.qcow2

To convert to VMDK for VMWare:

qemu-img convert source.vhd -O vmdk destination.vmdk

And to convert to a raw image, suitable for BOCHS.

qemu-img convert source.vhd -O raw destination.raw

And of couese you can mix and match from there… Say take your qcow2 and convert it for VPC like this:

qemu-img convert source.qcow2 -O vpc destination.vpc

Or convert a Virtual PC/Virtual Server/Hyper-V vhd (as long as the hyper-v image is consolodated) and convert it to VMWare like this:

qemu-img convert source.vhd -O vmdk destination.vmdk

Note that these VMWare VMDK’s are not for ESX/ESXi, they use more of a raw partition set… But of course you can always convert them to RAW then dd them into the target partition… But I’ll leave that exercise to you. Honestly that vmware converter thing is much easier as it’ll inject the needed drivers.

Speaking of which, this only converts image formats, don’t forget about pre-loading the needed drivers!

I hope this helps out anyone trying to move disk images around.


So while looking for some Win32s nonsense, I stumbled onto RGB Classic Games, and they have this interesting thing to run dos games online. A quick glimmer of the DOSBox logo flashes by.. So I fire up doom and quickly exit and…

Yes it’s DOSBox.

But in my browser.. A little tearing it apart, and it’s actually a port of DOSBox to JAVA!

Seeing it can run 80386 code, namely DOS4G/W, I figured it’d be interesting to see how it’d handle Microsoft PowerStation Fortran & PharLap TNT.

You can try it if you feel inclined here.

Recording QEMU’s VNC output to a flash file

First off it doesn’t do sound… I’ll have to search further for something that will let me do something more.. involved, but for now, this works well enough.

First I’m going to use Qemu 0.14.0 for this, earlier ones will work, but if it’s too old, there isn’t any support for VNC output. I figured I’d start with something simple, Lemmings, from the Win32s demo a while back. Now VNC doesn’t like it when you change resolutions, so I find it’s best to start out in the video mode you plan on recording. So once the VM is fired up I go ahead and load Windows. Qemu can support multiple outputs so I’m going to specify that it listens on the default VNC port (TCP 5900), and bind it to my IPv4 loopback. I’m also going to open up the SDL Window, because I like to see what I’m doing. If you want to get more sophisticated, you can even use a multiplexer program like VNC Reflector which will allow multiple people (or programs) to connect to the VNC port.

qemu -L pc-bios -m 32 -hda win31.qcow2 -vnc -sdl -soundhw sb16,adlib

Now a minor word about audio.. I am currently having issues aligning this up.. no doubt I’m doing something wrong, or I should just break down and use some proper editing tools but it kind of works for now. Also to get a ‘clean’ capture of the audio from the VM, I use Virtual Audio Cable. By simply changing my default sound device to a VAC, and my default Mic to the same VAC I don’t have to worry about background noises, or anything else. Not to mention in Vista or Windows 7, you can mute other programs so you won’t have instant pestering bleeding into it.

I’m using the awesome program vnc2flv to record this. Now it is a python program, but thankfully us windows users don’t have to go through too much hell to run this, I just downloaded it from ‘RT’s Free Software‘.

I just kick it off like this:

flvrec -C 640×480+0+0 -o video.flv

And it’ll start recording. I then kicked off sox to record the audio like this:

sox -4 -b 16 -d audio.wav

Then once I’m done doing what I’m going to record, kill both programs.

While sox can record mp3’s if you find libmad, or build it yourself, I found it was just easier to use lame.

lame -r -x -s 44.1 –bitwidth 16 audio.wav

And yes, you *DO* need to output at 44100Hz or 44.1Khz for the audio. Any other level and you can’t combine the flv & audio. Yes I tried and tried, but don’t fight it, and thank me for finding the flags to pass to lame.

Then use flvaddmp3 to combine the audio and the flv video into a final.flv.

flvaddmp3.exe video.flv audio.wav.mp3 final.flv

Now you can upload it to youtube, and from there embed or share it as you wish.

I had originally used pyvnc2swf, which will create a flash file directly, however it doesn’t deal that well with screen refreshes. But if anyone wants to use it, remember the default VNC port is 5900, and you must pick a file to ‘save as’ first then you can start the recording. Also in things like windows, I found having notepad open to full screen then minimizing it was a good way to force a screen redraw.

The first appearance of Windows NT

As mentioned in the great book Showstopper!, the first public demonstration of Windows NT was at the 1991 Fall Comdex.

And apparently it must have been quite a show.. In retrospect, but for stuff written down at the time there isn’t a heck of a lot to go on. I do find snip its like this after the fact:

“At the COMDEX show, Microsoft gives the first public demonstration of Windows NT. [909.232]”

But how about a good review? How about someone to kick the tires? I guess it was just too far fetched? Anyways I did find this ONE writeup in Infoworld:

Windows NT looks real at Comdex.


And it is just gushing about SMP support. But if you think about it, SMP support around 1991 was almost non existent. It either fell into people who took UNIX and tried to make it more SMP friendly (ie giant spinlocks) or people who offloaded specific tasks to different CPU’s (Novell Netware). NT was like Mach in that it was going to be something totally different written for SMP hardware in mind, and presenting a personality much like an old trusty OS, be it POSIX, Win32 or the NTVDM running other stuff. The other thing the article mentions is that 300 of these developer discs were made.

So with some luck, someone actually sent me an installed copy of this historic version of Windows, so let’s take a look shall we?

The only thing I really can compare this to is the later December 1991 release, but here goes.


So first here we are booting up. Not surprisingly, like all version of Windows NT we start with a blue screen. And here we know it’s the official “32-Bit Development Kit October 1991.” version. I wonder if they even sold/gave these out at Comdex to some selected people… But I’d imagine they didn’t.

And here we are at the login screen. Just like the December 1991 version there is no passwords, and you can even login as SYSTEM. The background & color scheme was set in the image, I bet changing them is trivial.

Here we are at the desktop. It feels more like Windows 3.0 then 3.1, it may very well be mixed in with the beta Windows 3.1 program manager for all I know.

Here is the command prompt. It looks very OS/2 like with the square brackets around the prompt. Just like December.

So I figured, let’s search through ntoskrnl.exe for any trace of OS/2…

And here it is!

Buried in the binary is the true name of Windows NT, NT OS/2. Not that it matters. Also notice all the NT api calls. It looks like these early kernels weren’t to scared to share their interface names..

Now this is a big deal, look at all the multitasking! In 1991 getting this kind of tasking out of Windows 3.0 was an impossibility! I’ve got 6 copies of WinBez open, along with Winshap bounding around minimized. I’ve got a command prompt open, and I compile some code, and it keeps on going.

But really pictures don’t speak words for it, here is it in action!


I know it’s small, it’s blogspot’s formatting, but you can always view the direct video on youtube here. And you too can watch me compile & kill a troll. Very exciting!

I’ll have to write up later how I did this….

Zork on Windows NT 3.1 Pre-Release

So I’ve had a few pre-releases, and I’ve not ported anything to it as yet so it’s been kind of silly. So at any rate I figured I’d clean up dungeon to run. So I managed to get the source onto the drive under qemu (-hdb fat:\temp\zork), and from there I got it to compile, and it crashed out.


Well that was painful!

So I took a que from the sample directory, and saw how it built a simple hello world, and took notice of the ‘cvtomf’ process… No doubt this early pre-release stuff is not anywhere near as stable as what NT was when it was around late 1992 or when it shipped in 1993. So spending some 30 minutes with the makefiles I got an exe that didn’t bluescreen the OS…

But still crashed. If only I had a debugger… Oh wait, what is this? Some kind of built in debugger?

I’ve never used NTSD, or the “NT Symbolic Debugger” before. It’s like debug from MS-DOS days, just with far more bells and whistles… Although the pre-release versions are lacking a lot of these features, I did manage to find the #1 thing I end up using, and that is the callstack, it’s bt in gdb speak, but it’s nice to see who called who before it exploded.

Here you can see how the program flowed from the mainCRTStartup which then catapults into main, then we see it calling sigcatch & signal, then it dies. Well I’m pretty sure that Zork doesn’t need signals, and that Windows NT around 1991 was far from feature complete and I bet emulating Unix signals wasn’t exactly high on the priority list.. If anything they were going nuts about meeting some kind of Comdex show deadline, and trying to bring the MIPS port up to parity with the i386. So I did the logical thing, which was to remove the signal portions from f2c & libf2c, and recompile.

So here we go, All the hallmarks of 1991 and Windows, we’ve got solitare, reversi and Zork (Dungeon) translated from fortran into C, and actually running!

So here is October of 1991, and December of 1991. Both needed long filenames to compile, I just used a HPFS slave disk. I just used Windows NT 3.51 to transfer stuff in & out as it’s got TCP/IP to make it easy, as it’ll also read HPFS. I guess you could use the MS-DOS pkunzip and fix the filenames yourself but I’ll leave that to the reader. The source trees ought to be identical, I left the object files & executables in there.. Naturally the December pre-reelase won’t run the October executable… Or link correctly with it’s object files.

I’d also imagine it’ll work on any version of NT that ships with a cl386 SDK… and probably any modern one by fixing the reference to cl386 in the makefile.