Compiling WinQEMU v0.10.2 using Visual Studio 2008 and Visual Studio 2012

3.00 avg. rating (74% score) - 1 vote

Earlier this year I managed to get DOSBox-X to boot Ubuntu 9.10, as least as far as dropping into the initramfs shell, in an attempt to reverse engineer a legacy Linux device driver. Although DOSBox-X worked just fine, eventually there was a need to study the device driver behavior in a full Linux environment, and the time has come for me to search for a better solution.

QEMU is definitely a better choice as it is still actively maintained and can run anything from MS-DOS to the most recent 64-bit OS. However, recent versions of QEMU can only be built on Linux, or at least MinGW, and debugging using GDB has never been my cup of tea. I know some developers hate Visual Studio, but I usually prefer a GUI way of debugging things, where possible.

After some efforts I located a port of QEMU v0.10.2 for Visual Studio 2008 (see also github repository). It was done by some Chinese developer (judging from the Chinese language in the included readme.txt file), was not subsequently maintained and eventually abandoned in 2009. Nevertheless I decided this would be my best shot and focused my efforts in getting WinQEMU to work.

Visual Studio 2008 will no longer work properly in Windows 11, so I installed it on Windows XP running in VirtualBox. After that, install the DirectX November 2007 SDK (filename: dxsdk_november2007.exe) and configure Visual Studio to parse the relevant header and library files. This can be done from Tools > Options > Projects and Solutions > VC++ directories:


Then, I fixed a few hard-coded include paths as well as a missing header file (opcode-cris.h). Although the file is available on the WinQEMU’s Github repository, its content has been changed over the years. It took me a while to search Github commit history and locate an old version which will work with WinQEMU. With this, WinQEMU successfully compiled on Visual Studio 2008.

The next challenge is to find the correct ROM BIOS and VGA BIOS which will work with this version of QEMU by seaching the SeaBIOS archives here. Again, it took me a while to find the correct BIOS, without this the emulated computer will not boot and will just show a black screen.

Next, we need to set up the command line parameters telling WinQEMU the configuration of the emulated machine. This is done by setting Debugging > Command Arguments from the property pages of WinQEMUTest:

-net none -cpu coreduo -m 480 -M pc -vga std -hda d:\Images\WINME.img

The above setting emulates a Core Duo PC, 480MB of RAM, with VGA display having WINME.IMG as the hard disk drive. WinQEMU will then load the ROM BIOS and VGA BIOS from the directory specified by CONFIG_QEMU_SHAREDIR in config-host.h:

#define CONFIG_QEMU_SHAREDIR "d:\\Images"
#define HOST_I386 1
#define HOST_LONG_BITS 32
#define CONFIG_WIN32 1
//#define CONFIG_GDBSTUB 1
#define CONFIG_SLIRP 1
#define CONFIG_ADLIB 1
#define QEMU_VERSION "0.10.0"

With everything setup correctly, Visual Studio 2008 is finally able to debug WinQEMU booting up Windows ME:


Take note that you should disable Virtual Box mouse integration, else the mouse cursor will move randomly. This issue is not unique to VirtualBox or QEMU and is common for emulator-within-emulator scenarios. Recent versions of Virtual Box added a message panel covering the right portion of the virtual machine, making the situation worse. Also for the record, Windows ME is the last Windows version to work on DOSBox. Later Windows versions (Windows 2000 onwards) will fail to find the IDE controller on DOSBox but work well on WinQEMU (I tested up to XP).

After successfully setting up the project with VS2008, I also managed to get the project compiled under Visual Studio 2012. After going through VS2012 upgrade wizard, not many extra steps were needed, except to add the DirectX SDK files to the VC++ Directories page in the project property. In VS2008, these settings were set on a global basis from Tools > Options.


WinQEMU now boots Window XP 32-bit just fine:


Ubuntu 10 works fine too:


You can boot newer 32-bit OSes if you configure a higher amount of RAM for the emulated machine. WinQEMU is a 32-bit application and can only theoretically support up to 4GB of RAM. Under Visual Studio 2012, to be safe, you should configure the emulated RAM to be 3GB or less.

To note, during the process I discovered that WinQEMU always disassembles a bunch of instructions and executes them at once, independent of any caching that would be done by the OS. In cpu-exec.c around line 640 you will find the following lines of codes

/* execute the generated code */
#if defined(__sparc__) && !defined(HOST_SOLARIS)
#undef env
	env = cpu_single_env;
#define env cpu_single_env

#ifdef _MSC_VER
	pGenCodeBuffer = &(code_gen_prologue [0]);

	if ((env->eip == 0x9016ee30) || (env->eip == 0x9117a000))
		pGenCodeBuffer = &(code_gen_prologue [0]);

		mov eax, tc_ptr;

		mov nEbpBackup, ebp;
		mov ebp, env;
		call pGenCodeBuffer;

		mov ebp, nEbpBackup;
		mov next_tb,eax;
	next_tb = tcg_qemu_tb_exec(tc_ptr);

Here the generated code is stored in pGenCodeBuffer, which is essentially array of pointers to functions which will perform the relevant CPU instructions (e.g. MOV, CMP, JMP etc.) once executed. The usage of inline assembly instructions to execute these functions, specifically the line call pGenCodeBuffer, will confuse the debugger. If you run OUT DX, AL and trace how QEMU actually handles this instruction, you will find that the stack trace starts from helper_outb(uint32_t port, uint32_t data) (file op_helper.c) and ended with ioport_write(int index, uint32_t address, uint32_t data) (file vl.c), with no records of what leads to the helper_outb call. You will then have to perform a text search of the QEMU source code to realize that this function originates from the gen_helper_outb call within gen_helper_out_func (file translate.c line 747), which could be then traced back to function disas_insn() also within translate.c, where the majority of the code generation is performed. And for some reasons, the code generation buffer is only performed if compiling using Visual C++ (see the #ifdef _MSC_VER preprocessor).

I have to say that the structure of QEMU is far more complex than that of DOSBox or other emulators.┬áDOSBox usually disassembles and execute instructions one by one. But then again, QEMU is a much more advanced emulator …

WinQEMU does not compile on newer versions of Visual Studio. I tried, only to be presented with zillions of error messages within various C headers and did not have the time to fix the issue. Visual Studio 2012 works well on Windows 11 and can be installed concurrently with newer versions of Visual Studio. The WinQEMU VS2012 setup is therefore good enough for me.

You can download a ZIP file ( containing the VS2008 and VS2012 solutions here. The BIOS files are located in the BIOS folder.

UPDATE (Dec 2023): Check out this Github repository for another SDL port of WinQEMU 0.10.2 to Visual Studio 2013. Thanks gdwnldsKSC for the hard work!

See also:
Getting Linux to boot on DOSBox-X



3.00 avg. rating (74% score) - 1 vote


A tough developer who likes to work on just about anything, from software development to electronics, and share his knowledge with the rest of the world.

10 thoughts on “Compiling WinQEMU v0.10.2 using Visual Studio 2008 and Visual Studio 2012

  • December 19, 2023 at 6:26 am

    Can you re-upload the project files and maybe which specific bios versions/filenames you used?

  • December 19, 2023 at 6:28 am

    Whoops! I found it, the link on the copy of the article is broke.

  • ToughDev
    December 19, 2023 at 9:21 am


    Thanks for the feedback. The CodeProject article was synchronized from this page via RSS. However, when I updated the link subsequently, the changes were not reflected. I’ll manually update the link on the CodeProject article later.

    Let me know if you have any issues compiling the project.

  • December 19, 2023 at 10:28 pm

    I actually got it working – the only issue I had was the correct bios/vgabios versions and was looking for yours to find it. I’m actually using SDL as the interface and all that jazz. My other reason for looking at it was for changes made that might differ from mine.

    My main goal is to get in a VS building version, Alpha emulation support fixed up since an ancient (around this version) patch set does something with graphical display nothing else does. Can load alphabios (ARC firmware) instead of just SRM firmware. It’s the closest we’ve gotten there – here’s someone who made that patch set work, but only with mingw/gcc 3.

    Ideally this’ll let it be a lot easier to debug and a bunch of other things before I start backporting forward improvements in the core and alpha target

  • ToughDev
    December 23, 2023 at 12:49 am


    Congratulations on the great job that you’ve done! I love your VS2013 port, for it works perfectly on my Windows 11 machine. There are some annoying VS2012 bugs when running on Windows 11, making debugging a hassle.

    I have updated the article to include a link to your Github repository. Thanks again for contributing to the open source community!

  • December 24, 2023 at 12:56 pm

    Definitely not a problem – the VS2013 fixes were actually relatively simple, after banging my head against a wall for a day and a half!

    I’ve got my repo tracking upstream too – ish. My code’s now at 0.10.3 release level, and once I get the -alpha CPU target architecture stuff folded in, i’ll be pushing to 0.10.5 and beyond. Should definitely be an adventure, that’s for sure!

  • February 14, 2024 at 9:57 pm

    Oh, do I have news for you!

    VS2022 building release, with a fair amount of updates post-0.10.2 (but not up to 0.11 timeframe yet, still have a few months of commits to slog through and implement).

    This is the latest commit from Qemu that i’ve implemented -> (as well as all previous).

    In my repo i’ve also been keeping all the other targets updated and current as well as all the other functionality, with how i’ve whacked in the MSVC changes it should still be buildable under other OSes as well.

  • ToughDev
    February 19, 2024 at 6:40 pm

    Sorry for the late reply as I’ve been really busy for the past few days.
    Absolutely fantastic work on updating the WinQEMU project to VS2022! Your efforts are truly appreciated, and I can’t wait to dive into the latest source code. I’ll be testing it out in the next couple of days and eagerly look forward to writing a new article about it.
    Thanks again for your hard work.

  • March 1, 2024 at 8:22 am

    Powered through about six months of patches and whammo.

    cranked it from v0.10.2 (ish, it wasn’t really fully there, it was a mess) to v0.11.0-rc0 and sync’d up most of the tree so that the qemu folder should just properly build on linux/bsd/mac with standard ./configure and make as well.

    A whole bunch of files are now 100% upstream, and a lot have greatly reduced modifications.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>