GCC 1.40 on Windows

I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right!  I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!

Where can I turn away from all this so called progress!  I don’t like my C compilers to be C++ programs that require massive HOURS to compile.  Can’t we just go back to the good old days?

And the answer is YES, you can!

While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms!  Well isn’t that fantastic!

So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?

Well ancient versions of EMX are very difficult to track down.  Somehow I did mange to find this hybrid of 0.8B & 0.8C.  The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B.  And the best thing is that the 0.8B is based around GCC 1.40!  So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW!  Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows!  So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.

Compiling & Binding

Compiling & Binding

Now with my executable, I can run it on MS-DOS & OS/2!

MS-DOS via DOSBox

MS-DOS via DOSBox

and OS/2 2.0!

OS/2 (on Qemu)

OS/2 (on Qemu)

Well isn’t that fantastic!

However when running RSXNT’s bind, NTBIND I got this error:

D:\emx_w32\infocom>..\bin\ntbind info2
No relocations in file:
you have not linked the NT library

Great.  Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries.  So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:

io.o: Undefined symbol __streams referenced from text segment

And looking at the stdio.h there is this:

extern struct _stdio _streams[];

No doubt, the headers & libraries are tied together.  So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).

Running on Windows 10

Running on Windows 10

Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory.  I suppose it’s a fair trade off.  Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days.  GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!

For comparison, GCC 5.10 produces a 55,906 byte interpreter, while GCC 1.40 produces a 88,576 byte interpreter.

For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles.  It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!

Nethack 1.3d on Windows 10 x64

Nethack 1.3d on Windows 10 x64

I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.

How about some speed comparisons?  I dug out the ancient dhrystone.c, and gave it a shot.  I had to define 500,000,000 passes, as my computer is fast.  GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.

D:\emx\demo\dhry>gcc140.exe
Dhrystone(1.1) time for 500000000 passes = 57
This machine benchmarks at 8771929 dhrystones/second

D:\emx\demo\dhry>gcc140_O.exe
Dhrystone(1.1) time for 500000000 passes = 40
This machine benchmarks at 12500000 dhrystones/second

D:\emx\demo\dhry>gcc510.exe
Dhrystone(1.1) time for 500000000 passes = 43
This machine benchmarks at 11627906 dhrystones/second

D:\emx\demo\dhry>gcc510_O.exe
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

D:\emx\demo\dhry>gcc510_O2.exe
Dhrystone(1.1) time for 500000000 passes = 14
This machine benchmarks at 35714285 dhrystones/second

D:\emx\demo\dhry>gcc510_Ofast.exe
Dhrystone(1.1) time for 500000000 passes = 11
This machine benchmarks at 45454545 dhrystones/second

As you can see, GCC 1.40 produces the slowest code.  While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away.  And again GCC 5.1 beat out the older 1.40 for executable sizes.

29,960 gcc510_O.exe
29,996 gcc510_O2.exe
30,472 gcc510.exe
70,656 gcc140_O.exe
74,752 gcc140.exe

And this time by over a 2x lead!  It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.

For anyone who’s read this far, I guess you want to take it out for a test drive?  Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk.  I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.

You can download the exe’s and combined source here: gcc-1.40_EMX-OS2_RSXNT.7z

Adding ncurses into Qemu!

Text mode.. text mode..

Text mode.. text mode..

One thing that’s always bugged me about the Qemu 1.0 and higher is that they don’t print anything to the Win32 console.  So you have to go digging around in stdout.txt or stderr.txt .  Very annoying.  And of course Windows users can’t have the nice ‘curses’ text mode interface.  Or can they?

While I was re-updating the 4.4LiteBSD MIPS Qemu package, I turned off the normal SDLmain so that it now acts like a console binary, meaning that stdout/stdin now function properly.  So if Qemu had a problem, you can see it!

And while I was in the source, I thought why not see how hard it is to manually turn on curses?  It’s a quick one liner to config-host.mak (since it’s not detecting) then updating everywhere it has <curses.h> hard coded to use <ncurses.h> …. I guess I could have made a symlink, but whatever.  It links and more importantly I can run text mode MS-DOS in text mode!

To activate simply use the -curses flag.

Rest assured that SDL is still in there as well.  But now you can see error messages like this:

C:\qemu>qemu-system-i386.exe -L pc-bios -m 16 -soundhw sb16
dsound: Could not initialize DirectSoundCapture
dsound: Reason: No sound driver is available for use, or the given GUID is not a valid DirectSound device ID

So now you know there may or maynot be issues… In this case, I don’t care about recording audio, so it doesn’t matter.

I’ve updated the existing files on my server, so simply re-download.  Otherwise for new people my i386 only package (~4MB) is here:

qemu-2.4.0.1_win32-x86_x86_64.7z

And the ‘full system’ package (~22MB) is here:

qemu-2.4.0.1_win32-all.7z

For the two of three people who like this kind of thing..

Qemu 2.4.0.1 binaries for Windows

So here is my cross compiled Qemu binaries for Windows.

I added in my Control+Alt+d ‘fix’ to be a Control+Alt+Delete that anyone who runs Windows NT or MS-DOS will no doubt love.  The kbd_put_keycode function had been removed, so I also put that back in.

I also undid the weird scaling thing that has been around since version 1.1.  And I tried my best to merge in some NE2000 fixes.

Solaris 9

Solaris 9

I threw a Solaris 9 ISO at it, and it booted up to the text installer!

asd

MIPS ARC

The MIPS ARC firmware however always bombs out on reset with an Interrupt Controller Error.

I tried the ‘doom’ test, and installing DooM 1.1 took FOREVER.  Writing to the disk is slow. Incredibly slow. I guess forcing the write thru cache is mandatory?

-drive file=bla.disk,if=ide,index=0,media=disk,cache=writethrough

I haven’t tested.

Also DO NOT USE THE PCSPEAKER DEVICE.

I nearly went deaf.  It doesn’t work properly, but rather loops so that one beep turns into a hurricane of beeps.

I’ve included the needed DLL’s, and compiled everything I could statically.  I guess I could have fought more but I have other things to do.

So the ‘cut down’ version which is i386/x86_64 only is HERE.

Those who want to try out the various RISC processors download the ‘full’ package HERE.

Building SDL2 for Android

Phew is this rather involved.  First you need to download over a gigabytes worth of files. For something that is going to be embedded you need a MASSIVE amount of space.

You need:

I went ahead and installed the JDK in a normal directory,  The same went for the Android SDK.  The NDK is a 7zip file, that I went ahead and put at the root of my C drive because I’m that kind of guy.  Next I unpacked ant into the NDK directory, and SDL.  For SDL be sure to use some command line or other unzip tool that makes sure that the text files are translated appropriately, otherwise they are impossible to read in good editing tools, like notepad.

cd C:\android-ndk-r10d\
unzip -aa \Downloads\SDL2-2.0.3.zip
unzip \Downloads\apache-ant-1.9.4-bin.zip

Now to stage the project directory.  The ‘Android project’ that we are going to build out of is *INSIDE* the SDL archive.  And SDL needs to be inside the project directory, so we xcopy out the bits we need.

md proj
cd proj
xcopy ..\SDL2-2.0.3\android-project\*.* . /e/s
md jni\sdl
xcopy ..\SDL2-2.0.3\*.* jni\sdl /e/s

Now we need to set some environment variables.  Again this is where my stuff is, yours may be different.

set NDK_ROOT=C:\android-ndk-r10d
set ANDROID_HOME=”C:\Program Files (x86)\Android\android-sdk\”
set PATH=%NDK_ROOT%\apache-ant-1.9.4\bin;”C:\Program Files\Java\jdk1.7.0_79\bin”;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools;%PATH%

Now we need to edit the jni\src\Android.mk and point it to your sources.  In this case I’m using dinomage.com‘s simple main.c &  image.bmp as I haven’t written anything exciting yet. Change YourSourceHere.c, to main.c

Now copy in the image.bmp file into the assets directory:

md assets
copy image.bmp assets

Now we can fire up the native compiler tools, and by default it’ll compile for ARM thumb, ARM v7a, and x86

..\ndk-build

Now for the java.  Android is a java platform, so now we have to compile the wrapper that calls our C/C++ code.  First we have to set what version of Android we are compiling for:

android update project –path . –subprojects -t 12

And now we compile with ‘ant’ by typing in:

ant debug

And if all goes well you’ll get:

BUILD SUCCESSFUL
Total time: 2 seconds

Now to run the program, we can fire up one of the emulators (you will have to configure one no doubt) using AVD.  I just clicked around, and picked something that’d launch.  The shell seems to crash a lot, but otherwise yeah.

Now to upload our application to the emulator once it is running:

ant debug install

And if all goes well, you’ll see:

install:
[echo] Installing C:\android-ndk-r10d\proj\bin\SDLActivity-debug.apk onto d
efault emulator or device…
[exec] pkg: /data/local/tmp/SDLActivity-debug.apk
[exec] Success
[exec] rm failed for -f, Read-only file system
[exec] 1985 KB/s (1028625 bytes in 0.506s)

BUILD SUCCESSFUL
Total time: 5 seconds

And on my first shot at running, it crashed.

Unfortunately SDL App has stopped

Unfortunately SDL App has stopped

Using ‘adb logcat’ on the emulator I was able to find this line:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol “signal” referenced by “libSDL2.so”…

Well it turns out signal was an inline function until platform android-21, now it’s not inline anymore. When you use the ndk r10, android-21 is used by default but it’s not fully retro-compatible with devices running former Android versions. In this case, signal can’t be found on the emulator. (It did run properly on my Lollipop phone).

Fixing this is simple just edit jni\Application.mk and add in the APP_PLATFORM line:

# Uncomment this if you’re using STL in your project
# See CPLUSPLUS-SUPPORT.html in the NDK documentation for more information
# APP_STL := stlport_static
APP_PLATFORM := android-12
APP_ABI := armeabi armeabi-v7a x86

Re-compile with ndk-build, and re-upload with ant then you are good to go.

working

working

I grabbed, and borrowed some phones around the office, including an x86 phone and yeah it works!

SDL2 test!

SDL2 test!

I haven’t even tried to cross build libraries on Windows… I suspect I should be doing this on OS X or Linux.

Shoebill now has working Ethernet support!

Great news!  The excellent A/UX capable emulator Shoebill, now has working Ethernet support!  The sad news is that it only supports the TUN/TAP interface.  So Windows users are kind of left out in the fun.

Shoebill + Ethernet

Shoebill + Ethernet

Except, I’ve been here before with SIMH ages ago.  So I dusted off my source code, and injected it into Shoebill.  The first issue I had was that SLiRP was rejecting all the inputted frames, because of invalid frame length.  Even more weird is that ARP worked, and I could see the 10.0.2.2 and 10.0.2.3 virtual IP’s but TCP and UDP outbound wouldn’t work at all.

It took me longer than it should have but although this code worked great with GCC 2.7 and 3.0, 4.x breaks it.  And it’s the same reason why Shoebill originally didn’t work on Win32, the blasted packed structures!  So adding the ‘-mno-ms-bitfields’ flag to GCC is all it took, and now I could ping 10.0.2.2 for about 5-7 pings until SLiRP would crash.  I tried all kinds of stuff trying to see if there was an issue with SLiRP, but I should have payed closer attention to the debugger, with all those threads flying around.  It turns out Shoebill was trying to read & write a the same time, which caused SLiRP to crash as it is not re-entrant.  I tried to place mutex’s on every SLiRP call but that ended up having SLiRP not process any packets.  Very strange.  I then reduced it to where I read the frame out of SLiRP and pass it to Shoebill, and where Shoebill write’s a frame out the SLiRP.  And much to my amazement I can run ‘worms’ just fine!

So after a minute of worming and pinging I called it ‘good enough’ and rebuilt a production binary, and packaged up my source code.

For anyone who want’s to play, my Win32 EXE is here, and the source code I am using is here.

Fun with PGP 1.0

Well I got slightly bored, and thought I’d dig into some old crypto software.  And PGP 1.0 was as good as any place to start.

Now one scandalous thing at the time was the inclusion of RSAREF 1.0, the RSA reference library which redistribution required a license that wasn’t exactly included with PGP.

A company called Public Key Partners (PKP) holds the exclusive
commercial license to sell and sub-license the RSA public key
cryptosystem. For licensing details on the RSA algorithm, you can
contact Robert Fougner at PKP, at 408/735-6779. The author of this
software implementation of the RSA algorithm is providing this
implementation for educational use only.

And wow was this fun at the time.  As far as I know this license lapsed on September 21, 2000

And then there was this slight issue:

After Biham and Zimmermann go their food and sat down, Zimmermann took out a few pages of computer listings.  Within minutes, Birham was finding fundamental flaws in Bass-O-Matic.  Some of the flaws were subtle-weaknesses that made the algorithm susceptible to differential cryptanalysis, which was Birham’s speciality. Others were more embarrassing, like a conceptual error in Zimmermann’s algorithm that prevented the last bit of each byte from being properly encrypted.  After ten minutes of Birham’s onslaught, Zimmermann realized that Bass-O-Matic was a lost cause.

So now you would be wondering, why would I even bother with what was a quickly abandoned encryption?  Well I was bored, and I was more interested if I could locate the source to 1.0.  What would be more interesting to me is to revive it onto somewhat more modern 32-bit platforms.  Namely OS X, Win32 and MS-DOS.

With a little luck, I found the unix_pgp10.tar.gz, which does contain the source code for a Unix version of PGP!  This version is more so geared to the SPARC of all things. Specifically it mentions:

Tested on SunOS 4.1 with gcc 1.39

However building on OS X was trival with changing the Makefile.  The CC had to be changed to reflect a 32bit build, and the DEFINES had to remove the HIGHFIRST define, as the x86 platform is little endian.

CC=cc -arch i386

DEFINES= -DUNIX -DPSEUDORANDOM -DUNIT16 -DPORTABLE

Is the relevant changes.

And even better it’ll work!

$ pgp pgp.ctx pgp.exe

Pretty Good Privacy 1.0 – RSA public key cryptography for the masses.
(c) Copyright 1990 Philip Zimmermann, Phil’s Pretty Good Software. 5 Jun 91

File has signature. Public key is required to check signature.
File ‘pgp.ctx’ has signature, but with no text.
Text is assumed to be in file ‘pgp.exe’.
.
Good signature from user “Zimmermann, Philip R. – prz@sage.cgd.ucar.edu”.
Signature made Wed Jun 5 13:51:18 1991

Signature and text are separate. No output file produced.
Plaintext filename: pgp.exe

Wasn’t that great!

Now getting this to run on Windows was a little bit more of a challenge.  I was going to build from the UNIX source code again, however both Visual C++, and Watcom C++ build an executable, but neither are able to add keys to the keyring, verify the executable reliably and deadlock all the time.

So I thought I’d get a little creative and start replacing some code from the MS-DOS version of PGP. It turns out that all I needed was rsaio.c & rsaio.h and I was able to build an executable.  But I ran into other snags, and stack errors.  A glance at the MS-DOS Makefile, and I saw that they had to up the stack size from the defaults.  So I figured the same would hold true, and I picked a much larger 32kb stack for the heck of it.  I mean it is 2014, and if you can’t handle a 32kb stack well..

Compiling on Visual C++ went like this:

cl386 -c /DPSEUDORANDOM /DUNIT16 /DPORTABLE *.c
cl *.obj /F32768 /Fepgp.exe

And for Watcom C++

wcl386 -c -dPSEUDORANDOM -dUNIT16 -dPORTABLE *.c
wcl386 *.obj -fe=pgp.exe -k32768

And now I can build for either compiler.  And even better, it works!

PGP 1.0 on Win32

PGP 1.0 on Win32

Even for completness sakes, DOS4G/W works as well! Just remember to link for MS-DOS

wcl386 *.obj -fe=pgp.exe -k32768 -l=dos4g

And you should be good to go.

PGP for 32bit MS-DOS

PGP for 32bit MS-DOS

So what happened to PGP?  Well version 2 used a more ‘acceptable’ encryption, the IDEA cypher, then the company was sold, IP was sold again and again.  It’s still out there, mostly for email encryption.

While it sure did ignite the world on fire for a while, the overall difficulty of using it, combined with the ease of losing the private key and all your data is just too easy.  But this really is the nature of the beast.

Qemu 1.6.0 for Win32

I updated my glib2 to the same version that works great on OS X, and it feels like the Win32 binaries are just slower than ever.  Now I am running this under VMWare, so maybe that is why it is so slow.

Can someone give this a shot?

Any and all feedback would be nice.

Oh I included the Doom 1.1 in there run it like this:

qemu-system-i386 -L pc-bios -m 16 -hda doom11.img -soundhw sb16,adlib

And you should be able to run doom with sound.

I’ve removed the fullscreen/resizing on Qemu 1.1.1

And now it is *MUCH* faster…

Next I’ll have to investigate better audio libraries, as winwave seems to leave a lot to be desired.

Basically the changes in ui/sdl.c were:


case 0x21: /* 'f' key on US keyboard */
// toggle_full_screen(ds);
// gui_keysym = 1;
break;
case 0x16: /* 'u' key on US keyboard */
// if (scaling_active) {
// scaling_active = 0;
// sdl_resize(ds);
vga_hw_invalidate();
vga_hw_update();
// }
// gui_keysym = 1;
break;

And


case SDL_VIDEORESIZE:
// sdl_scale(ds, ev-&gt;resize.w, ev-&gt;resize.h);
vga_hw_invalidate();
vga_hw_update();
break;

So now it keeps the correct video display size, so it isn’t going like crazy trying to scale the screen 30 times a second..

Doom now looks normal!

As you can see stuff like Doom now looks normal.  As mode changes are initiated by the video card, it keeps the scale to where it was in prior versions.  At least its not going 1:1 native as looking at a 320×200 window on a 1280×768 desk would be a tad hard..

And yes, even things like Windows 3.0 look correct when the screen changes resolution:

Windows 3.0 in 386 enhanced mode

Also I should add that if you are going to try to use disk images that are *NOT* 1.44 MB they will not work.  You’ll have add this flag to Qemu:

-global isa-fdc.check_media_rate=off

I’ve been told the new handling of disks is better in this version so I’ve left this setting where it was..

I have just updated the download link, but for those who missed it, you can download the i386  win32 version here.

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…

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…