Qemu

Qemu is one of the most versatile emulators out there.  While mainly used for x86 system emulation, it is capable of emulating the following systems:

  • i386
  • x86_64
  • MIPS (32bit/64bit)
  • PowerPC (32bit/64bit)
  • ARM
  • Sparc (32bit/64bit)
  • s390x
  • m68k
Qemu 2.4.0.1
 
Qemu 1.3.0
 
Qemu 1.2.0
 
Qemu 1.0.1 for OS X PowerPC (10.5.8)
Qemu has a reputation as being ‘difficult’ because it is command line driven.  But it’s really not that hard to configure.
 
And don’t forget to use flags like this with 0.15.0 and higher evoke some slow disk speeds unless you add a disk like this:

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

Also, don’t forget the exciting adventure on how to compile Qemu for Win32.

Years later the syntax has drifted so much that this is the best way to attach a NE2000 and use NAT

qemu-system-i386 -net none -device ne2k_isa,iobase=0x320,irq=10,netdev=ne -netdev user,id=ne,hostfwd=tcp::42323-:23 -drive file=netbsd-1.0.vmdk,if=ide,index=0,media=disk,cache=writeback

23 thoughts on “Qemu”

  1. Tried this build and see something strange: amd64 can only use 1140MiB of RAM. I’d expect the maximum to be at 2047… Is my XP installation foobar, or is it something wrong with this build? I haven’t tried compiling qemu for a pure win32. Last time I compiled it under cygwin and I definitely could use 1.5G.

    BTW, thanks for building it.

    • I think it cuts it down because the whole process can grab 2GB with Qemu using a large chunk… Maybe flagging it 3GB ‘ok’ may help.. ultimately the right thing is a win64 build… 😐

      • at least
        peflags –bigaddr=1 qemu-system-x86_64.exe
        made no visible effect.

        Yes, a win64 build would be nice, but in my particular case it won’t help: the customer is stuck to XP on the desktops… So, I guess they gonna have to suffer having just ~1G for the virtual machines…

        • Do the machines have 3GB of ram, and booted into that PAE mode or whatever it is? I’ve only messed with SQL & Exchange for PAE/3GB but never got that much out of it as it was just easier to move to 64bit…

          There may be a ~1GB limit in Qemu’s win32 host support…. I’ve never looked into it.

          • The machines do have 3GB RAM. As for the mode, I don’t know how to find out without having an access to the boot.ini.

            On the qemu side the limit it 2047 (this off-by-one is odd, but oh well). If qemu is started with -m 2048 or more, the error message is clear.

            Yeah, on my machines I’ve moved to 64 bit long ago. But then again, none of these was a windows box… 🙂

        • I’m switching to OS X, and the 64bit gcc here gives me 64bit QEMU’s! … which can happily give 3072MB of ram to a lowly OS like NT 4.0!

  3. Quick question i think your the right person to ask
    Is it possible to have
    OS Host : Windows 7
    Emulator : Qemu 1.2.0 (Your Compile Version)
    Guest OS : Windows 8
    if YES can u please make me Tutorial

  6. Hello,

    I have read your excellent wiki page about installing NeXTStep on Qemu. Everything works but I still have one problem.
    With Interface Builder, you need to use Alt+Clic when you want to create a bloc of repeated objects (for example a Button matrix from one button to create a kind of keyboard).
    That combination Alt + clic doesn’t work.
    Have you heard about that problem?

    Thanks, guillaume.

    • As far as I know right now it won’t even fully run the SRM ROMS, much less an operating system. There is that ES40 emulator which apparently can run OpenVMS to some degree.

  9. your vpsland server is dead, and along with it, all the rare emulators and os images that were on it

    you should mirror them to archive.org (such as the nextstep daydream emulator thing and the previous emulator)

  10. Hello everyone, and best wishes from Italy.
    I hope I’m not writing an inappropriate comment, sorry if I do.
    For nostalgic fun, I have a VM where, with a qcow and two partitions, I emulate an MS-DOS 6.22 plus Windows for Workgroups 3.11 on the primary, and a Windows 98 Second Edition on the logical, switching from one system to another with the Windows bootloader.
    I have tried different versions of Qemu, including those hosted on this site, so far I have obtained the best results with a 2_9_94 (accel=hax) that I have been using for years to emulate Ubuntu (https://qemu.weilnetz.de/w64/ 2017/qemu-w64-setup-20170824.exe) and with a 0_8_2 (https://web.archive.org/web/20061130051913/http://www.h6.dion.ne.jp/~kazuw/qemu- win/qemu-0.8.2-windows.zip) but …
    With 2_9_94 and emulating a Cirrus PCI the well-known corrupted screen problem in WfW is present.
    With 0_8_2 no display problems even in WfW but unfortunately in MS-DOS I lose the possibility of using the USBASPI.SYS DI1000DD.SYS combo to hook a fake USB disk (instead the fake USB disk works perfectly in 2_9_94 even in MS-DOS while only Windows 98 Second Edition hooks the fake USB disk into 0_8_2 LOL).
    In your opinion, is a “cornea” transplant possible? That is, force the 2_9_94 to use the vgabios-cirrus.bin of the 0_8_2?
    I tried the simplest way, in a folder on my Windows host and with the CMD MKLINK command I mixed the various original BIOS binaries pointing to Qemu but…
    0_8_2 crashes, while 2_9_94 remains with a black screen and <>.
    Or, but I think it’s more complicated, give the 0_8_2 a BIOS that can manage the fake USB disk?
    I’m open to suggestions, and thank you all for your time and attention.

Leave a Reply