Building Qemu 1.1.1-1 for Win32

I still can’t see how to build this for win64 … ūüôĀ

The first major stumbling block on Win32 is glib, and again going back to the MinGW wiki there is a good laundry list of how to bootstrap Glib on MinGW.

Things you’ll need:

Be sure to run ming-get install for the following:

  • gcc
  • g++
  • libiconv
  • zlib
  • libz
  • gettext
  • msys
  • msys-perl
  • msys-m4

Install Python.. Nothing to fancy from what I gather Qemu still requires you have a level 2 Python, not 3 …

Build libffi

This should be the usual dance of configure & make / make install… ¬†But sure to at least run configure like this:

./configure –prefix=/mingw

Build Glib without pkg-config

Be sure to add Python to your path..

PATH=/c/Python27:/c/Python27/DLLs:$PATH
export PATH

Glib is packed with something called ‘xz’ so hopefully you have xzcat .. Otherwise add it!

export LIBFFI_CFLAGS=’-I /mingw/lib/libffi-3.0.9/include’
export LIBFFI_LIBS=-lffi
export lt_cv_deplibs_check_method=”pass_all”
export CFLAGS=‚ÄĚ-O0 -g -pipe -Wall -march=i486 -mms-bitfields -mthreads‚ÄĚ
export CPPFLAGS=‚ÄĚ-DG_ATOMIC_OP_USE_GCC_BUILTINS=1‚ÄĚ
export LDFLAGS=‚ÄĚ-Wl,–enable-auto-image-base‚ÄĚ
configure –prefix=/mingw –with-pcre=internal –disable-static –disable-gtk-doc –enable-silent-rules

*¬†You may have some weird issue where when running configure it tells you it cannot create executables, or you get a bunch of weird errors trying to paste in the CFLAGS line.. For me the MinGW prompt was stripping the quotes and the leading – to the -O0 (disable optimization) bit. ¬†I don’t know what on earth its issue was, but I had to type that line in manually.

Then do the make/make install dance. This will take a WHILE. At least with -pipe it’ll run each stage of GCC on multiple processors… But yeah.. This is intense to build. ¬†Good thing we get to do it twice.

I also ran into some weird error in the GIO directory where it couldn’t find my Python, and was looking for python2.5 .. So I copied python.exe to python2.5.exe …

PYTHON = /usr/bin/env python2.5

pkg-config

Naturally pkg-config depends on Glib2, and pkg-config to build… Which of course is a circular problem, much like Glib2 requires pkg-config to build. ¬† So to configure it, it goes something like this now that we’ve built a Glib2 ..

export GLIB_CFLAGS=”-I/mingw/include/glib-2.0 -I/mingw/lib/glib-2.0/include”
export GLIB_LIBS=”-lglib-2.0″
configure –prefix=/mingw

At the same time I can’t help but wonder if this version of pkg-config can use it’s own Glib with the following config:

configure –prefix=/mingw –with-internal-glib

Anyways with any luck we can now build & install pkg-config.  This only takes a few seconds..

Glib2 (again)

From this point you should open a new MinGW prompt window, as you don’t want the old CFLAGS screwing things up. ¬†Re-eport the Python path/dll vars and now we can get on to building glib2 (again!) …

configure –prefix=/mingw;make;make install

 

SDL

This should be somewhat straightforward …

configure –prefix=/mingw;make;make install

In the old days we built zlib, but now we can just quickly add in the package (as we did way above) so we should.. now be ready for the main event!

 

And now we can finally build Qemu 1.1.1-1!!!

Now there is a few things I like to tweak, the first is in the configure script, I like to add in AdLib support.  Look for the line

audio_card_list=”ac97 es1370 sb16 hda”

and add adlib into the list

audio_card_list=”ac97 es1370 sb16 hda adlib”

Next I like to modify hw/pc.c and alter the ISA NE2000, as Qemu doesn’t like to share IRQ 9 with the card, so it is just easier to remove the 0x300/IRQ 9 definition.

static const int ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320, 0x340, 0x360,
0x280, 0x380 };
static const int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 };

to this:

static const int ne2000_io[NE2000_NB_MAX] = { 0x320, 0x340, 0x360,
0x280, 0x380 };
static const int ne2000_irq[NE2000_NB_MAX] = { 10, 11, 3, 4, 5 };

The next tweak deals with the ability to use older qcow2 disk images… I guess converting them to RAW with an older version of Qemu, then using the new version of Qemu to convert them back into qcow2’s may be a “good idea‚ĄĘ” but for now modifying the source is a quicker fix.

Comment out the “return -EINVAL;”¬† in block/qcow2.c

if (ext.len > end_offset – offset) {
error_report(“Header extension too large”);
//return -EINVAL;
}

Now one fun thing I’ve noticed is that building with the default O2 flags Qemu will crash out the moment you access a hard disk image. ¬†It appears that¬†coroutine-win32 is at issue (again?). ¬†So the “easy” way I address it is to first build qemu as normal, and verify that if you attach a hard disk image (any kind) and try to access it, partition it etc, it should crash. ¬†Next remove the file¬†coroutine-win32.o , and edit the file config-host.mak and change the CFLAGS that specify

CFLAGS=-O2 -g

to

CFLAGS=-O1 -g

Now run make again, and it *should* just rebuild¬†coroutine-win32.o with the lesser optimization flags, and relink all the exe’s. ¬†If I’ve done this right, you should now have a working Qemu.

You can go ahead and strip the binaries if you so please, but that should be it.

PHEW. ¬†For anyone who wants my build, but doesn’t want to go through this ‘exciting’ process, you can find the Win32 i386 build here.

Weird scaling in action .. Control+ALT+u kind of undoes it, but it just doesn’t look right and it is far too slow.

In preliminary testing I’ve found this version to be MUCH slower than 0.15.1 .. I think it has something to do with it wanting to scale the SDL window. ¬†Also I’ve had issues with various network cards not¬†initializing¬†with the BIOS that ships with this version of Qemu so I’ve included the bios directory from 0.15.1 . ¬†And lastly yes the disk images… I’ve had major issues with my qcow2 disks, and disk corruption with this build. ¬†I’ve gone ahead and ¬†included the qemu-img tool from 0.15.1 so you can convert qcow2 to raw, then use the 1.1.1 tool to take them from raw back into qcow2 … But I’d probably only do it as a test.

You may want to kick the tires on this version but 0.15.1 really blows this one away…

Running Qemu as a Windows service …

Long story short I’m doing some work with a network that suffers a lot of ‘you can’t get there from here’. ¬†They’ve given me VPN access and yet even the VPN cannot get to a lot of stuff.

The solution for them is to use this old server and ssh out from there to the rest of everything.  Which for the most part works fine, but if more then 2 people need to leapfrog suddenly you are waiting in line, or constantly knocking people off.

So I figured I’d do something different, install a QEMU¬†virtual machine on the server during my allotted hour, and then launch it as a service so that I could leap in/out through the VM leaving the console free.

While I am going to add Qemu as a service, it is still somewhat stealthy as I don’t need device drivers, and I can run it nested as I know this machine is slated to be migrated to VMWare ESX. ¬†And the best part of that is that it’ll continue to run.

So how do we set this kind of thing up?

The first thing you’ll need is srvany.exe instsrv.exe which both can be found in the Windows 2003 resource kit.

Installation is very straightforward, just remember to use complete paths for your Qemu, BIOS, and disk files.  Installation goes like this from the command line:

InstSrv qemu c:\qemu-0.15.0\srvany.exe

This will create a service entry named Qemu, which will in turn kick off the srvany executable from the resource kit. ¬†Now I know what you are thinking, what about Qemu? ¬†Well we have to specify that using regedit. ¬†Also remember that because you are going to run this as a service you don’t want the SDL display popping up and scaring some poor hapless user. ¬†So the first thing I’d recommend is to work out the flags that you want to start with. ¬†Something like this:

c:\qemu-0.15.0\qemu -L c:\qemu-0.15.0\qemu\pc-bios -hda mydisk -net nic -net user -redir tcp:2222::22 -vnc w.x.y.z:2223

This will redirect tcp port 2222 into the VM for ssh, and sits the VNC display on port 2223 …

So we fire up regedit and navagate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Qemu

There we add a new key “Parameters”. ¬†Then add an ASCII key of “Application” then just paste in the all of the qemu flags as mentioned above (or changed as needed by you).

Then you can simply start/stop the thing using the net start/net stop.

I suppose this is a little subversive (lol) but sometimes you’ve got work to do and the best way through it to piggyback on someone¬†else’s¬†computer. ¬†Also I really fail to see the ‘wisdom’ in creating ACLs that only permit you to access your routers/switches from your desktop when you could easily *NOT* be in the office. ¬†Or this guy just likes the excuse of not being able to work from home.

Anyways not to ramble but that’s how I ‘fixed’ the issue without ruffling too many feathers.

Qemu 0.14.0 rc2 released!

Qemu 0.14.0 rc2 and Windows NT December 1991
Qemu 0.14.0 rc2 and Windows NT December 1991

Well this one compiles clean under MinGW so that’s a nice touch. the ISAPC machine type is still broken. ūüėź

I’ve built the usual set with soundblaster & adlib enabled, and the NE2000 set to 0x300 irq 3 so old crusty things ought to have some hope of working. I’ve also included the PS/2 mode 3 keyboard patch for some really old stuff.

So here we go the x86 / x86_x64 builds that 99% of you want/need.

And here for the rest of the stuff for the 1% that need/want sparc/arm/powerpc/mips etc…

Qemu 0.14.0 rc1 released!

Back on the heels of the 0.14.0 rc0 release, it’s rc1!

Still nothing on the official changelog

Also I ran into this snag while building under windows..

LINK i386-softmmu/qemu.exe
../qemu-timer.o: In function `host_alarm_handler’:
C:/msys/1.0/src/qemu-0.14.0-rc1/qemu-timer.c:188: undefined reference to `qemu_next_alarm_deadline’

I moved the “#ifndef _WIN32” below the definition of `qemu_next_alarm_deadline’, and all was well.

So here is the x86, x86_x64 build, what 99% of you want. And here is the RISC version for the 0.01%.

Qemu 0.14.0 rc1 and Windows NT October 1992
Qemu 0.14.0 rc1 and Windows NT October 1992

I know this may not look like much, or seem different from much of any version of Qemu but it’s 0.14.0 rc!!!!

SHOWSTOPPER!

show-stopper-coverI was browsing around at a book store, and I came across the book “SHOWSTOPPER” the breakneck race to create Windows NT and the next generation at Microsoft.

If you have ever lived through the Windows NT 3.x days you’ll find this a very interesting read. It goes into the big personalities, and of course covers the working habits of Dave Cutler… Although it does paint him in some really odd colors, mostly as an antisocial kind of dictator pushing people to produce the largest program Microsoft had ever produced at the time.

But there is no doubt, Cutler could not have written Windows NT at Digital, as DEC was too fond of hardware lockins (look at VMS & Ultrix/True64). And it does cover the major animosity of Cutler towards DEC with the cancellation of the Prisim/Mica projects, and then the later “I told you so” moment when DEC licensed Windows NT from Microsoft (although other reports claim that DEC threatened MS with a lawsuit, and MS gave them access to NT, along with some money…). Apparently the mantra was “Dec could have had NT for free”..

There is also coverage of the culture clash of what happened when Microsoft had absorbed the Prisim & Mica engineering teams from DEC, and how they did not get along with Microsoft staff, and even did their best to poke holes in the current offerings of MS-DOS & OS/2 as either a toy, or a joke.

One thing I found interesting, is that the book mentions the WLO project, as the foundation for what would be the ‘Win32’ system. WLO if you remember was a port of the Windows Libraries to OS/2. It was very interesting in that Windows, OS/2 and even MS-DOS & Win16 via WOW were all not part of the main Windows NT group, but rather ‘tacked on’.

However it is quite interesting that the design decisions made for a very portable and modular operating system, that survived it’s original CPU & platform being changed 1/4th the way through development, and then the removal of the primary API.

Another thing that was interesting was some of the ‘fixes’ for the too slow, too big that would plague the early versions of NT, was the idea of demand paging portions of the kernel.. I for one would go insane with the blue screens about paging non page-able areas or some other VM error… But the truth was NT was written by people who came from a minicomputer world, and as the book made evident from time to time, they did NOT use PC’s.

Needless to say, the book was somewhat spot on, in that it’d take 10+ years for computers to catch up to what Windows NT was written for. I for one can remember trying to run this on a 386sx-16 and it was horrible… But if you install it on a Pentium II the 3.x series simply FLIES… And in emulation on modern machines it has incredible performance.

While Windows NT 3.1 was no doubt a 1.0 release, 3.5 was a 2.0. The x86 optimizations really payed off, and kicking out the Spider TCP/IP stack, and bringing in the new MS stack helped a LOT. There is no doubt back in 1994 as SLIP & PPP accounts were becoming more common place, Windows NT 3.5’s networking was the easiest to configure and use. Linux back then really was in it’s infancy, and the dialup scripts for pap/chap/pppd were… a nightmare.

“Dogfooding” was another interesting, and necessary thing as once NT was able to start running programs it was important to make people start using it as quickly as possible to shake out bugs in the system. Its also interesting to note the reluctance of the kernel team to deal with the graphical part of NT, and how the first versions were text only. Another weird part was how the security in Windows NT was an after effect, of the internal networking group cooking up what eventually became the domain & trust model. Not to mention how NTFS almost didn’t make it because the filesystem people (all two of them!) were so busy making sure HPFS worked correctly.

There is no doubt that such a ‘ground up’ OS of this magnitude hasn’t been attempted since 1988. It took Microsoft 5 years to get Windows NT out the door, but there is no doubt looking around in the year 2010, Windows NT has a long life ahead of it.

For those interested, you can find it on amazon.