Installing Xenix on Qemu 0.14.0 part two.

Ok, we left off from part one, having prepared the hard disk. Now we are going to boot off the hard disk like this:

qemu.exe -L pc-bios -m 16 -hda xenix.disk -fda b1

 

xenix2 1 (1)Now if we go ahead and try to install normally it’ll fail like this:

xenix2 2 (1)

 

Which isn’t good at all.

xenix2 3 (2)

Instead, what we are going to do is hit the delete key breaking us to an install shell.

xenix2 4

So at the shell, we are going to fix the install/rinstall devices to force them to the 3 1/2″ high density diskette like this:

cd /dev
ln -f fd0135ds18 install
ln -f rfd0135ds18 rinstall
cd /
. /.profile

xenix2 5

Now we can proceed with the install, and since diskette B1 is already in the drive, we just hit enter. Once the B diskette is copied, the install script will prompt for a root password.

xenix2 6

Now it’s time to pick a timezone, and yes, I’m in North America.

xenix2 7

In EST.

xenix2 8

And sadly, yes we do DST. (*NOTE being this old, you can bet the offsets are all wrong for DST, I’m sure there is some deal to update the files, but I’m not sure of it off hand. But it’d be nice to update the timezone stuff for 4.2BSD as well).

xenix2 9

Let’s continue with the install.

xenix2 10

And let’s finish the operating system install.

xenix2 11

Now we’ll need the X1 diskette…

So far we’ve not needed to swap diskettes live under Qemu, but I thought I’d remind people that it’s a simple matter of hitting ctrl+alt+2 to bring up the Qemu console, then typing in:

change floppy0 x1

To verify you’ve even done this correctly, you can issue a “info block” command, and you should now see the floppy0 device referencing the x1 file.

Once you are done, you can switch back by hitting ctrl+alt+1

We are going to install one or more…

All of them as a matter of fact.

I’m going to fast forward a little here, and process all the X diskettes… there isn’t much to see here, it’ll prompt for a diskette, mount it in the qemu console, and switch back and proceed.

Yes this is a root only install, KISS (Keep it simple stupid) as they say.

Now it’ll prompt for the backup user password, then start to compress man pages. Needless to say on a fast computer this takes mere seconds… Not so back in the day on a 386!

Now it’ll prompt for the sysadm password, generate the termcap, then it’s time to swap series to the N series diskettes..

Now onward to N2.

Time to license & activate the system. Again.

Ok we are done.

And there we go, Xenix is installed!

A quick reboot, and we are ready to go!

So looking back, we’ve just done the impossible, we’ve installed Xenix on Qemu.

Qemu 0.14 PowerPC & Debian.

So I got this request about running Mono on the PowerPC. As it stands right now I don’t have a PowerPC box in my home to test, so I thought I’d turn to Qemu & Debian.

Qemu 0.14.0 PowerPC Debian boot

Qemu 0.14.0 PowerPC Debian boot

And yes, it surprisingly boots!

I opted for the network install, as I didn’t even know if it would work. But not only did the 32bit version of Linux for the PPC boot up, but the 64bit did as well! The flags were a little involved to get going, but it went something like this for the 32bit version:

qemu-system-ppc.exe -m 512 -boot d -hda debian-ppc.qcow2 -L pc-bios -M mac99 -net nic,model=pcnet -net user -cdrom debian-6.0.1a-powerpc-netinst.iso -boot d

And for the 64bit version:

qemu-system-ppc64.exe -L pc-bios -m 512 -hda ppc64.qcow2 -net nic,model=pcnet -net user -cdrom debian-6.0.1a-powerpc-netinst.iso -boot d

And then it’s a matter of waiting… Maybe I should have just torrented the install DVDs or something.. 😐

Qemu 0.14.0 PowerPC Debian install 33%

Qemu 0.14.0 PowerPC Debian install 33%

But booting from the hard disk produces a:

openbios panic: Unexpected exception 704

So close. Perhaps the macintosh machine type I select means the boot type isn’t PReP like for OpenBIOS to find?

I’ve also been told you can find various pre-built images here.

Windows NT July 1992 Preview

So I got my hands on another early Windows NT preview. This one is so rough around the edges, it’s more of an alpha then a beta. It’s even reflected in the bootup screen.

Bootup Bluescreen

Well, what has changed from the 1991 releases? Plenty, the registry is coming along quite a bit, but there is no integrated setup program at this point. I almost wonder if this build was meant to be internal only, as it does drop stuff about your Microsoft badge ID. No, really!

Freaky, isn’t it?

Winver showing Build 297

In this build 297, and it includes the OS/2 & MS-DOS/WOW subsystems. The POSIX subsystem is absent, further cementing the idea that it was included much later to target Windows NT at government contracts with a POSIX check-box. I’ve only done some simple testing with the MS-DOS compatibility and it was ‘ok’ but nothing too solid. I didn’t have any luck with the OS/2 stuff, maybe I’m just doing it wrong. One thing is for sure, if it’s this rickety in 1992, they were nowhere near ready in 1991!

I guess if you paid for it, you can put your name all over it!

Another fun touch is who it’s registered to. I guess since Bill is footing the bill for NT, it’s all his anyways.

Broken boot.

With that being said, the installation which involves a batch script dos2nt.bat is very touchy, it does require few files to manually edit. I’ve found it works best with a d drive to swap to, but for the most part NT cann’t find itself properly and you wind up with a blank desktop, stemming from the “An error has occurred in the registry. The Program Manager’s settings and groups can not be accessed.” error. Since NT at this point is far more closer to Windows 3.1, then 1991’s builds being closer to Windows 3.0, the famed game reversi is missing…

However the administrative tools is in NT now, the logon/logoff and locking works. NT at this point is transitioning from an OS running a 32bit version of Windows 3.0 into a fleshed out operating system.

Shutting down.

WinDoom, WinG, Win32s on Windows 3.1 (on Qemu)

So since I was looking at the Doom stuff, I thought I’d try to track down the WinG version of Doom, and luckily someone pack ratted away two versions! Needless to say the older one didn’t work for me, but the last one, the April 13th, 1995 build, worked just great!

WinDoom on Windows 7 x64

Even on Windows 7 x86_64, sp1!

So how much of a chore was this to run back in 1995, before Windows 95?

Well to start WinDoom requires a display capable of at least 256 colors. I thought I’d use Qemu for this, but this proved to be… exceptionally difficult to locate a satisfactory display driver. I know lots of people point to the SVGA.EXE update from Microsoft, that uses VESA extensions to drive the video. Oh sure it sounds great but this is what I got:

And.. corruption.

Ok, so you say, there is this great patch to enable better VESA support right?

Wrong.

Yeah. I also hunted down various cirrus drivers for the specifically emulated chip (I checked the source) and they were all consistently defective. So I tried using a lower chip driver from HP and amazingly the 640x480x16MM colors works! (well, works ‘enough’).

Installing the right driver.

It’s the GD5430 v1.25f, 640x480x16.8M

The next thing is that Doom in both MS-DOS and Windows are full 32bit executables. On the MS-DOS side, it relies on the DOS4G/W extender. For Windows, it relies on the then new Win32 standard, and Windoom was written to conform to the Win32s standard, meaning with an addon it can run on Windows 3.1, Windows 95, And Windows NT. I just fished around the internet and scored a copy of Win32s 1.25. I just remember this being a somewhat stable version.

Installing Win32s

Win32s installs pretty smooth, (as long as you remember the share.exe). Now we just need the WinG runtime to be installed. WinG was Microsoft’s first real attempt at high speed gaming video under Windows. From what I understand it kind of went down because it was ‘too difficult’, and buying DirectX seemed to be a better fit.

Setting the midi mapper.

Another thing I’ve found is that if you change the midi mapper from the default “Ad Lib” to “Ad Lib general”, you can at least get the midi working in Doom.

Once WinG is installed, then it’ll want to do some blit tests…

WinG calibrating.

And after that, we can even bump it up to glorious 640×400, something the initial MS-DOS version couldn’t do easily as VESA wasn’t a big standard with INSTALLED cards at the time, and it’d require lots of work from the iD team, where the move to Windows pushed all the peripheral development to the Vendors to work around Microsoft. Even to this day, it’s still a big deal with video and audio.

One thing that is cool about Qemu is that at compile time, you can put in adlib & soundblaster cards to give the ‘full’ Windows 3.1 multimedia experience. There is also GUS (Gravis Ultra Sound) support
in Qemu, but I’ve never played with it..

With all of that out of the way, WinDoom will launch.

WING dispdib.dll missing error that turned out to be Video for Windows.

Then it’ll throw an error, because Windows 3.1 doesn’t have the same video backend as Windows NT 3.5 (and higher), hit ok and then …

And it works! WinGDoom running on Windows 3.1 on Qemu!

Sadly on Windows 3.1 the sound effects do not seem to work, but overall it’s a GREAT little port, mostly because as it comes up on 16 years old, it still works, and with sound. I wish other OS’s could give this kind of support for legacy applications, even ones that had such a brief window of support.

Anyone crazy enough to even think of playing along can download the blob of software I used to get this going here (Updated on archive.org here: Windows-3.1-WING-doom)

I should also add if you want sound effects to work on WinDOOM you really should install the Video for Windows Runtime, and it’ll work… poorly on Qemu/SoundBlaster 16, but it does work!

Desqview/X

Desqview/X

I never used Desqview back in the day, as I didn’t have a good enough computer. A 286 with 1mb of ram just wasn’t enough to push the thing. And by the time I did get a 386, OS/2 2.1 was all the rage. But in that time between OS/2 2.x and the release of the 80386 CPU there was all kinds of programs to take advantage of the 386’s v86 mode.

Desqview X really is different in that it not only incorporates the desqview multitasking, but it also supports the X11 protocol found in the UNIX world. Sounds cool right? A friend wanted to run it, so he actually dug out a web page, chsoft.com with all the bits.

The first stumbling block is that Desqview requires that you use the memory manager QUEMM, which the majority of emulators we tried couldn’t work with it. Qemu 0.14.0 however proved itself up to the task, as long as you didn’t let it do the aggressive optimization, just let it install, and reboot.

Installing DesqviewX was pretty straightforward, the only catch was the video. VGA doesn’t work but the SVGA modes work fine. I just used the 800x600x256 mode.

With that out of the road, the next thing needed was a good mouse driver. For some reason the majority of the mouse drivers I tried just wouldn’t work with desqview, until I tried ctmouse.

Naturally for the whole X11 experence you need networking. The tcpip package on the desqview webpage uses some old netware thing with a ne2000 driver that is hard coded to 0x300 irq 4. Which won’t work in any machine I know since everyone has at least one com port. So I had to take the lsl & ne2000 parts from my Netware 3.12 client. But doing so revealed that the lsl wouldn’t run because of a lsl buffer pool error. And of course to work with slirp you need to be running ethernet_II instead of 802.3 …

So you’ll need a net.cfg like this:

link support
buffers 4 1504
mempool 8096
max stacks 4
link driver ne2000
port 300
irq 3
frame ethernet_ii

Naturally you’ll need to change the source to Qemu if you have your own build to use IRQ 3 instead of 9 (it’s in hw/pc.c), or use one of my binaries. It’ll configure via bootp and at the end you should be able to ping 10.0.2.2

Putting it all together, running it like this:

./qemu -L pc-bios -hda packet2.qcow -net nic,model=ne2k_isa -net user -redir tcp:6001::6000

On OS X has qemu listen on 6001 for X11 sessions, then redirect them into the VM on it’s X11 port. So I could then easily run xeyes like this:

xeyes -display 127.0.0.1:1

And the output appears inside of Desqview X. Likewise, removing the session security, and allowing remote connections in OS X’s X11 widget, then allowed me to send xeyes from Desqview to my mac like this:

xeyes.exe -display 10.0.2.2:0

And exeyes pops up on OS X as running from the Desqview VM.

I don’t know if it’s terribly useful, but I thought someone may get a kick that Desqview X can run on Qemu 0.14.0 In this day & age though you can get easier versions of X11….

AMD PCNet with Netware 3.12

Well I found out that the AMD PCnet driver will work on Netware 3.12 on Qemu 0.9.0 with a little cajoling. So to switch from the NE2000, I first downloaded the following files:

*odi33g.exe
*odi_ahsm_svr3x.zip
*nw4-idle.nlm

From odi33g.exe, copy out the following files to your server directory

\server\33spec\ethertsm.nlm
\server\33spec\312\msm31x.nlm
\server\33spec\312\nbi31x.nlm

Your server directory should contain…

nbi31x.nlm
ethertsm.nlm
msm31x.nlm
pcntnw.lan
pcntnw.ldi
nw4-idle.nlm

Then configure your autoexec.ncf like this…

load c:\server.312\msm31x
load c:\server.312\pcntnw slot=2 frame=ETHERNET_II
bind ipx to pcntnw net=c0ffcab
load c:\server.312\nw4-idle

I’m not sure about the speed, but the idle NLM is fantastic, it means that your VM won’t run at 100% cpu…

Wasn’t that fun?

Installing Windows NT 4.0 on Qemu 0.14.0 with SCSI

So for a test I needed an email server, so I thought I’d setup an Exchange server quickly. Exchange 5.5 runs best on NT 4.0 so I’m going to install it on Qemu 0.14.0. Along the way I ran into a few little gotcha’s so I thought I’d update on how to do this.

qemu.exe -L pc-bios -cpu pentium -hda nt4-server.qcow2 -net nic,model=pcnet -net user -cdrom nt4server.iso -boot d

As you can see on NT 4.0 you now have to set the CPU level. This needs to be done going forward with NT 4.0 as again it’s too old to detect newer CPU’s and gets confused. Also I’d recommend selecting the ‘standard pc’ HAL. Oh sure it may look all nice with a MPS/Uniprocessor, but I’ve found it noticeably slower.

The default cirrus logic driver works at 16bit depths at 800×600 well enough (The hardware mouse pointer doesn’t work so you’ll need to turn on a custom pointer). Another thing is my choice of the AMD PCNet NIC, is that it’s the same that VMWare uses, so you can always run these disks under VMWare if need be (as long as VMWare has IDE disk support, and you convert the disk first!!).

Ok that basically covers an IDE install, but let’s get onto SCSI. Qemu now (it’s been in there for a while..) emulates a SCSI controller, the PCI 53c895a adapter. And I’ve found that you can get it to work with Windows NT 4.0! First you’ll need a driver diskette & BIOS both found at LSI’s webpage. The NT driver is nt896.zip if you’ve gotten the correct one.

Now that I’m going to install exchange, the best practice I’ve found for NT is something like this:

OS DISK 4GB
SWAP DISK 256MB
INSTALLS 2GB
MAIL STORE 8GB
LOGS 128MB

So that’s a bunch of SCSI disks, right? I guess I could build a stripped set but that’d be kind of crazy… so here is how I’m going to do it:

qemu-img.exe create -f qcow2 scsi0.qcow2 4G
Formatting ‘scsi0.qcow2’, fmt=qcow2 size=4294967296 encryption=off cluster_size=0

qemu-img.exe create -f raw scsi1.qcow2 256M
Formatting ‘scsi1.qcow2’, fmt=raw size=268435456

qemu-img.exe create -f qcow2 scsi2.qcow2 2G
Formatting ‘scsi2.qcow2’, fmt=qcow2 size=2147483648 encryption=off cluster_size=0

qemu-img.exe create -f qcow2 scsi3.qcow2 8G
Formatting ‘scsi3.qcow2’, fmt=qcow2 size=8589934592 encryption=off cluster_size=0

qemu-img.exe create -f raw scsi4.qcow2 128M
Formatting ‘scsi4.qcow2’, fmt=raw size=134217728

Since the swap & log disk are constantly being written to, it’s best to leave them in the ‘raw’ disk format.

Ok now to install. I know it’s a massive command line but this is how I’m going to kick off the install:

qemu.exe -cpu pentium -m 256 -L pc-bios -net nic,model=pcnet
-net user -drive file=scsi0.qcow2,if=scsi,bus=0,unit=0 -drive file=scsi1.qcow2,
if=scsi,bus=0,unit=1 -drive file=scsi2.qcow2,if=scsi,bus=0,unit=2 -drive file=sc
si3.qcow2,if=scsi,bus=0,unit=3 -drive file=scsi4.qcow2,if=scsi,bus=0,unit=4 -opt
ion-rom 8xx_64.rom -fda lsi.vfd -cdrom nt4server.iso -boot d

And if it’s done right, you’ll notice that now the SCSI bios will be initializing as seen below with a bunch of disks…

qemu 0.14.0 scsi bios

qemu 0.14.0 scsi bios

Once your NT CD starts to boot up, you’ll see a blue screen like this. It’s important that you hit both F5 and F6 over and over to tell the setup program that you want a custom HAL, along with an install time SCSI driver.

qemu 0.14.0 nt 40 scsi hit f5/f6

qemu 0.14.0 nt 40 scsi hit f5/f6

And as I did above, I’ll first select the ‘standard pc’ HAL.

qemu 0.14.0 nt 40 scsi load Symbios driver

qemu 0.14.0 nt 40 scsi load Symbios driver

Select the  Symbios driver

Select the Symbios driver

Then You can tell it to load the LSI / Symbios scsi driver, and install will roll through as normal. Since this is going to be an Exchange server, I’m also going to make it a PDC on it’s own domain, since Exchange requires DC functionality.

Make it a DC

Make it a DC

And from there it is a somewhat normal NT install. I did leave out the messaging stuff, because it’s that ancient “Microsoft Mail” stuff, and it’s somewhat crippled at that.

For the fun of it, if you load 256 colors, you’ll wind up with this:

Windows NT 4.0 with 256 colours

Windows NT 4.0 with 256 colours

And all the icons will be blank squares. Not terribly useful. Maybe for low displays the regular VGA would be best…. But again with 16bit and custom pointers (much like an old MIPS issue) it will work enough. 1024x768x16million colors at 43Hz (interlaced) works pretty good too!

Next I fired up the disktool, (diskman) and slapped down a bunch of partitions… I let the swap formatted FAT as I don’t care about it’s crash to crash integrity, but the rest can be NTFS. Also from a boot limitation the first disk is only 1GB out of it’s 4… I don’t know if that matters.

qemu 0.14.0 nt 40 partition disks

qemu 0.14.0 nt 40 partition disks

Then into the system tool to move the swap to the ‘s’ drive.

qemu 0.14.0 nt 40 scsi setup swap

qemu 0.14.0 nt 40 scsi setup swap

I don’t know if the actual setup of Exchange is all that … interesting so I’ll just leave it to your imagination.

More failure on the Netware front….

Years ago Netware sold these 4.1 dev kits on the cheap, and I picked one up in College. Back then the selling point was that along with Watcom you could actually run Netware 4.1 along with OS/2, and do all the dev loading on the same machine!

What a time saver, not to mention you could simulate a LAN on the same PC as each MS-DOS VM could have it’s own virtual NIC and each VM could login independently.

Anyways, I thought I’d go ahead and give this thing a shot, since I haven’t run this in a while, so I installed OS/2 2.11 on Qemu 0.14.0, and … got this.

Qemu 0.14.0 OS/2 and Netware crash

Qemu 0.14.0 OS/2 and Netware crash

PNW0162: An internal error has occurred. The program cannot initialize the GDT information.

Which of course is the Global Descriptor Table, and I don’t know why it can’t play with it… Qemu limitation? OS/2?

Anyways afterwards, I get this.

Qemu 0.14.0 OS/2 and Netware trap

Qemu 0.14.0 OS/2 and Netware trap

Trap 000d

And you thought Windows NT blue screen of death was impossible to read…

Revisiting Netware 3.12

I know this is one of the really ‘hot issue’ things out there. Sadly the thing is that Qemu ran Netware 3.12 back in the 0.90 release, but not any release since then has been able to run it.

And after testing Netware 4.1 & 4.11 they too only run acceptably under Qemu 0.90

Otherwise on the newer versions, I get nothing but disk errors, even trying to used some 3rd party updated IDE drivers, it still does not work.

It’s very perplexing, and at the same point I know it’s not a burning priority for the Qemu team….

Proxmox/VE gets much further but ultimately I couldn’t get it all working…

Apparently it’ll run on VMWare, more information here.

One thing is for sure, Netware 3.12 and it’s “patching” system is a major nightmare.

Any Qemu higher then 0.9.0 gives this error….

“Abend: A directory buffer with no dirty bits set was encountered on the dirty list”

qemu 0.14.0 netware abend

qemu 0.14.0 netware abend

While there is the ‘scsi option’ for Qemu 0.12 and higher, you’ll need a BIOS… However for 3.12 it hinges on the DOS driver, which when loaded… crashes out Qemu.

Qemu and 64bit windows…

It’s been a while since I’ve tried to run some 64bit versions of windows so I downloaded some from MSDN, and tried to run some under the latest 0.14.0 build

First up is Windows XP x64 sp2 (en_win_xp_pro_x64_with_sp2_vl_x13-41611.iso)

I launched it like this:

qemu-system-x86_64.exe -m 1024 -hda six64.disk -L pc-bios -cdrom en_win_xp_pro_x64_with_sp2_vl_x13-41611.iso

And the bootloader loads up, but it hangs transitioning to the kernel. Nothing is logged to the serial port.

qemu 0.14.0 windows xp sp6 x64

Next up is Windows 2003 server, with no service pack.

I’m loading up Qemu like this:

qemu-system-x86_64.exe -m 1024 -hda six64.disk -L pc-bios -cdrom \install\en_ws_2003_std_x64_vl.iso

And again being met with a hung state booting the kernel.

qemu 0.14.0 windows 2003 x64

I guess this isn’t surprising as booth 2003 & XP x86_64 both use the same kernel.

Next up, I thought I’d try a longhorn beta…

qemu-system-x86_64.exe -m 1024 -hda six64.disk -L pc-bios -cdrom longhorn-some-random-beta-x86_64.iso

qemu 0.14.0 longhorn 3016

And I get a nice black screen, again transitioning to the kernel…

So let’s try Windows 2008r2 (It’s the same thing as Windows 7).

qemu 0.14.0 windows 2008 r2 x86_64 crash

So this is different, so googling around for the Stop: 0x0000005D (0x0000000078BFBF9,0x0000000000000000,0x0000000000000000,0x0000000000000000 code, led me to some config file for the x86_64 for additional CPU types. It appears that in the arch_init.c file I modified the following line:

const char arch_config_name[] = CONFIG_QEMU_CONFDIR “/target-” TARGET_ARCH “.conf”;

Into:

const char arch_config_name[] = “./target-” TARGET_ARCH “.conf”;

So that way I could pick up the ” -cpu Nehalem ” flag. Sadly it produced…

qemu 0.14.0 windows 2008 r2 x86_64 crash nehelam

Bummer.

Meanwhile, much like Novell Netware, it really only works on Qemu 0.9.0

qemu 0.9.0 widnows xp x64 sp2 boot

qemu 0.9.0 windows 2008 r2 x86_64

But not so hot for Windows 2008 r2 (AKA Windows 7).