.js like JavaScript?. Â YES. Â I’m not kidding. Â James Friend has whipped up a port of PCE to javascript!
Complete with Macintosh, and IBM PC!
Yes, it even runs Wolfenstein 3D!
However on my 2006 Mac Pro it is VERY VERY slow. Â But then again what would you expect from javascript?
It is far more heavier than jdosbox, but at the same time no pluggins!
I’m still on the fence at the moment about something as heavy as pc emulation in javascript, but it is still fun/neat!
This was the first version of Watcom that included the much beloved DOS4/GW dos extender. Â Funny enough it doesn’t bind in a stub for running DOS4/GW by itself, you have to do it manually or I guess write the stub for yourself. Â Another fun feature of Watcom C/386 8.5Â is that it includes the win386 windows extender.
Basically it does to Windows 3.0 what DOS4/GW does to MS-DOS. Â Now I’ve never messed around with win386 that much because by the time I did have a 386sx processor with more than 1MB of ram, Win32s & OS/2 2.1 were all the rage. Â But in the world of VM’s I thought I’d give it a shot.
The default example is the game of life. Â It compiles trivially, but the moment you got to run it you get this fine error:
Ooops!
It turns out that it is a timing loop error, and effects of all things Microsoft FoxPro!  The solution is provided by Microsoft, in the form of IPatchFP.exe. Naturally it is a console Win32 executable.  But with enough of the HX DOS Extender‘s runtime I can run the patch inside of MS-DOS.
With my executable all patched up, I can now run the game of life!
Conway’s game of life
Which is all very exciting.
Win386 was very cool for the time, taking the Win16 API and making their own Win32 set out of it. Another cool thing is that there wasn’t a separate runtime to repackage, as Win386 was just bound to the executable. I’m sure it didn’t fall on deaf ears at Redmond with the disillusion of Cruiser, that Win16 could have a brave new future in Win32.
And I should mention I’ve gone over a lot of the Win32s versions here.
Something interesting crossed my desk today. The much-fabled Microsoft OS/2 2.0 SDK beta.
OS/2 2.0 SDK in action
Sadly, this does *NOT* include the operating system, just the C compiler and the SDK bits. As you can see, the C compiler is version 1.00.075, a full year+ before the WindowsNT 3.1 1991 pre-release which had 6.00.080. An interesting thing is that the C compiler can be run from 16bit OS/2. Unfortunately, the EXE’s produced by the SDK will not run on a production OS/2 system. The fault lies with the linker & resource compiler. However swapping those two components out for production versions seems to remedy this and produce working executables. The only SDK examples that don’t work correctly involve the creation of DLL’s. I’m sure it is again related to either the linker again, or from some gem I saw in the SDK saying you should always link by ordinal, and never by name. Apparently a bunch of function calls were going to change name from OS/2 1.2 to 2.0. It is interesting to me that going from the old Windows 3.1 to NT days we always had so much issues with people calling by ordinal vs the function name. It broke all the time, but it is funny to see possibly where this bad habit started.
Import and link by Ordinal? What were they thinking!?
For those who don’t know DLL’s contain a table of functions sorted by NAME, and NUMBER. The names have to be unique but the number depends on the order in which the DLL is linked together. And it is very easy for someone to accidentally change the link order, and next thing you know the ordinal are all wrong.
Otherwise, yeah the tools from the MS OS/2 2.0 beta working in 2013. I do believe that the object files can also be strung together with some DOS Extenders from the era to produce DPMI exe’s.
But I’ll save that exercise for later, like here! targeting OS/2 with Visual Studio 2003!
Descent I
I never was good at this game.
As a matter of fact, I was terrible.
Apparently I get lost in 3d worlds like this, and I get dizzy and need to lie down. Â Something about these kinds of 3d virtual worlds. Â At least it doesn’t pertain to virtual machines.
While browsing around, I came across the source code. Â From their notes they built the thing using:
I was unable to find Opus Make, however with a little bit of tweaking, Microsoft nmake can happily read the makefiles. Â The other small snag largely was due to MS-DOS not being able to process massive commandlines, and having to build response files to the librarian and linker in various parts. Â But all in all it was thankfully a trivial amount of work to get a working executable.
I only tested it for a few minutes until I was feeling out of it again. Â I guess it isn’t surprising, I had issues when it was full screen back in 1994, but in a tiny window in 2013 it is unbearable.
For the two or three people who care, here is my VMDK that I used. Â It works fine with Qemu probably other emulators that can read VMDK’s.
Gravis Ultrasound
Back when the Adlib & Sound Blaster cards were king, there also was the far more expensive, and far better sounding Gravis UltraSound. What really separated the GUS from the Adlib cards was a wavetable approach to midi file playback. The GUS was driven by a ‘soft’ table, meaning programs had to upload samples to the card before it could use them. Â This was unlike cards like the SoundBlaster AWE editions which stored their wavetables in ROM.
Qemu has included GUS emulation for some time now, however because of the softset files it is rather involved to get working.
The first thing you will need to do is download the soft files here. Â You will need to inject them into your MS-DOS disk image. Â I prefer to use the following method:
 -hdb fat:xfer/
Where xfer is the directory where I’ve extracted my files. This will make the directory show up as a second hard disk.  Now the drive is read-only so getting files OUT of the emulator still requires either virtual floppy disks (yuck) or a network client.  The archive contains two versions of the wavetables, one that is stock that I couldn’t get to work, and a ‘patched’ version.  Copy the ULTRASND411 directory to c:\ultrasound  .
Next we need to setup the environment variables.  The Gravis UltraSound in Qemu is setup for IO port 240, Irq 7, and DMA channel 3.  As you can see from gus.c in Qemu source:
static Property gus_properties[] = {
DEFINE_PROP_UINT32 (“freq”, GUSState, freq, 44100),
DEFINE_PROP_HEX32 (“iobase”, GUSState, port, 0x240),
DEFINE_PROP_UINT32 (“irq”, GUSState, emu.gusirq, 7),
DEFINE_PROP_UINT32 (“dma”, GUSState, emu.gusdma, 3),
DEFINE_PROP_END_OF_LIST (),
};
This means we need to setup the following environment varriables in the autoexec.bat
SETÂ ULTRASND=240,3,3,7,7
SET ULTRADIR=C:\ULTRASND
 Re-launch Qemu and specify the soundcard emulation something like this:
-soundhw gus,pcspk -parallel none
This will give us both the PC speaker, and the Gravis UltraSound.  Additionally this disables the parallel port which also uses IRQ 7.  We should be able to run games now.  For anyone interested, Maraakate has given me a link to share of his GUS archive.
I found this information on a Qemu patch page (before the GUS support was mainlined), and Vogons support for DOSBox & GUS emulation.
I’ve tested Doom, and Heretic which work fine on Qemu 1.6.1 on OS X.
For anyone who cares, this is what the SoundBlaster/Adlib sounds like, and this is the Gravis UltraSound emulation in Qemu.
Or even better, embedded audio!
UltraSound
SoundBlaster
So, since I’ve been starting up my virtual network thing, I got distracted with this thread on reddit
Fun times ahead!
, talking about the good old days of Doom. Â Now Doom was revolutionary for the music, the sound effects, the 2.5D environment, the fast pace, the violence, the unlimited lives, dynamic lighting and of course LAN play. Â Now what was cool is that it could easily run over IPX/SPX networks. Â Although you did have to be on the same network it was very easy to setup, and get going. But as anyone can tell you, the moment you setup a four player deathmatch on a company LAN people would go nuts, as you would without a doubt bring the entire network to a halt. Â Back when I used to play this we would just disconnect the 10base2 cable from the lab 486DX2/50 PC’s and just make our own four computer segment. Â We did notice that if we had 3 four player games on the same network (afterhours!) that it was unplayable. Â I never did have access to a sniffer back then, and when I got a corporate job, being caught with something like Doom was grounds for termination so I never did get to see what the big deal was.
So I figured I’d cook up a super quick lab to check it out. Â This is my Dynagen configuration. Â Sadly I do need a cisco router to preform the network capture, although I don’t need to configure it to see what is going on.
autostart = True
[localhost]
[[7200]]
image = ../C7200-JS.BIN
npe = npe-400
ram = 160
idlepc = 0x60529c84
disk0 = 0
mmap = False
ghostios = True
[[ROUTER corertr1]]
model = 7200
slot1 = PA-8E
F0/0 = coresw1 5
[[ethsw coresw1]]
1 = access 1 NIO_udp:41300:127.0.0.1:51300
2 = access 1 NIO_udp:41301:127.0.0.1:51301
3 = access 1 NIO_udp:41302:127.0.0.1:51302
4 = access 1 NIO_udp:41303:127.0.0.1:51303
5 = access 1
As you can see this is very simple, a switch with four ports setup for four virtual computers, and a fifth port for the router. Â Next I run four instances of Qemu with a copy of Doom v1.1 shareware, and a IPX/SPX client. Â I fire them up like this:
./qemu/qemu-system-i386 -cpu pentium -L ./qemu/pc-bios/ -m 16 -hda doom11-00.img -soundhw sb16,adlib -net nic,model=pcnet,macaddr=00:11:22:33:44:00 -net socket,udp=localhost:41300,localaddr=0.0.0.0:51300 &
#
./qemu/qemu-system-i386 -cpu pentium -L ./qemu/pc-bios/ -m 16 -hda doom11-01.img -soundhw sb16,adlib -net nic,model=pcnet,macaddr=00:11:22:33:44:01 -net socket,udp=localhost:41301,localaddr=0.0.0.0:51301 &
#
./qemu/qemu-system-i386 -cpu pentium -L ./qemu/pc-bios/ -m 16 -hda doom11-02.img -soundhw sb16,adlib -net nic,model=pcnet,macaddr=00:11:22:33:44:02 -net socket,udp=localhost:41302,localaddr=0.0.0.0:51302 &
#
./qemu/qemu-system-i386 -cpu pentium -L ./qemu/pc-bios/ -m 16 -hda doom11-03.img -soundhw sb16,adlib -net nic,model=pcnet,macaddr=00:11:22:33:44:03 -net socket,udp=localhost:41303,localaddr=0.0.0.0:51303 &
Again all very simple.
From there I configure each of the four VM’s for a four player game, start the game, then connect.
Loneliest deathmatch
I only had the game running for a few seconds when I went to my Dynagen console, and setup a capture session:
=> capture corertr1 fa0/0 doom.cap
=>
As you can see very simple. Â I walk the guys around a little bit, shoot someone, then just quit all the clients, and turn off the VM’s. Â Then I end the capture
=> no capture corertr1 fa0/0
=>
And now I’m left with a 50MB file!
$ ls -alh *cap
-rw-r–r– 1 jsteve staff 50M 25 Oct 14:27 doom.cap
I’m shocked! Â I wasn’t even running Doom that long! Â A quick peek reveals why Doom was never popular on corporate networks.
14:25:57.464031 IPX 00000000.00:11:22:33:44:00.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
…
14:27:28.996489 IPX 00000000.00:11:22:33:44:01.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
14:27:28.997618 IPX 00000000.00:11:22:33:44:03.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
14:27:29.019568 IPX 00000000.00:11:22:33:44:01.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
14:27:29.026000 IPX 00000000.00:11:22:33:44:03.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
14:27:29.026205 IPX 00000000.00:11:22:33:44:01.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
14:27:29.054425 IPX 00000000.00:11:22:33:44:01.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
If you see the destination it is ff:ff:ff:ff:ff:ff, a broadcast packet.  And I have 50MB of this in the span of a minute and a half!  Even worse, opening the packet stream most of it is empty packets!
14:26:22.806014 IPX 00000000.00:11:22:33:44:00.869c > 00000000.ff:ff:ff:ff:ff:ff.869c: ipx-#869c 444
0x0000: e0e0 03ff ff01 da00 0000 0000 00ff ffff …………….
0x0010: ffff ff86 9c00 0000 0000 1122 3344 0086 ………..”3D..
0x0020: 9c00 0000 0000 0000 0001 0000 0001 0000 …………….
0x0030: 0002 0000 0000 0000 0000 0065 0000 0000 ………..e….
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0110: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0x01d0: 0000 0000 0000 0000 0069 0000 00 ………i…
Needless to say this could have been optimized a little better.. but at the same time back in 1993 this was the coolest thing ever. Â Even if it did have a reputation of destroying networks.
I can remember how loudly network people would complain about Doom, but it is kind of interesting to see it first hand how chatty it is. But at the same time, how exhilarating it was, for the first time we were playing against each other, not bots.
And speaking of this era, for those who may not have ever read about the rise & fall of iD, you may want to check out the book ‘Masters of Doom‘. Although the end is pretty much Old Man Murray. There is no mention of the soundcard disaster that was DMX, or anything about how deathmatch could crush a LAN. But I guess everything can’t be 100% for the time.
First I just found out about the KVM Forum 2013, taking place in Edinburgh, Scotland.
You can find all kinds of information and videos of the presentation on the G+ page!
This is an incredible resource for anyone thinking of deploying KVM (Proxmox/VE!) in a serious setting. Â Unlike VMWare ESX this is a free solution with no insane license restrictions. Â Not to mention that KVM+Qemu is far more flexible than any traditional x86 focused hypervisor will ever be. Â And poor Microsoft still doesn’t yet offer x86_64 solution.
I also got a ping back from Linux Lifestyle, about a challenge to find an ancient version of Linux. Â Although the real credit goes to the excellent preservation work of oldlinux.org .
Personal note, I got the flu (again!) and have been sick.. which is why the lag in the network stuff, but I’ll bang more on it tomorrow. Â I’ll finally get to adding remote sites, routing protocols, and all that fun stuff. Â Internet/NAT/Firewalls afterwards. Â ASA stuff too, as much as I don’t like them.
Much like my prior article on Configuring TCP/IP, the process for configuring IPX/SPX on a cisco router is pretty much the same thing.
The first big ‘gottcha’ in the world of IPX is that it supports multiple frame types. Â This winds up leading to all kinds of troubles when various people setup various servers. Â It is inevitable that people pick their own and incompatible frame type. Â The only to ‘fix’ this is for everyone to be on the same type. Â I have heard of people using different frame types for different environments, much like using 802.1q (trunking) to separate various peoples traffic who do not want to see each-others resources. Â But back when IPX was prevalent, people were still using HUBS which mirror all traffic, and primitive layer two switching at best. Â Not to mention with the advent of Netware 4, you could have virtual NIC’s in the server and workstations, and bind to all possible frame types.
Things got messy, and quick.
But I digress, for this example I’m going to use the ‘default’ frame type of ETHERNET_802.2 or SAP is cisco speak. Â Mostly because I don’t feel like fully configuring the MS-DOS client I managed to dig up, and mostly because at this point (2013) I really don’t care what frame type I use.
I’m going to setup the following IPX networks:
WANÂ C0000001
SERVERÂ C0010001
USERÂ C0010002
The first step is to enable the ipx protocol on the router. Â This is done with the ‘ipx routing’ command.
corertr1#config t
Enter configuration commands, one per line. End with CNTL/Z.
corertr1(config)#ipx routing
corertr1(config)#exit
corertr1#
Now the IPX protocol is enabled. Â The next step is to configure the ethernet interfaces. Â This is pretty straightfoward, we put in the network numbers, and assign the correct frame types.
corertr1#config t
Enter configuration commands, one per line. End with CNTL/Z.
corertr1(config)#int eth1/0
corertr1(config-if)#ipx encapsulation SAP
corertr1(config-if)#ipx network c0010001
corertr1(config-if)#exit
corertr1(config)#int eth1/1
corertr1(config-if)#ipx encapsulation SAP
corertr1(config-if)#ipx network c0010002
corertr1(config-if)#exit
corertr1(config)#int fa0/0
corertr1(config-if)#ipx network c0000001
corertr1(config-if)#ipx encapsulation SAP
corertr1(config-if)#exit
corertr1(config)#exit
corertr1#
Now we can quickly check the interfaces that IPX is running on with the ‘show ipx interface brief’ command. Â You should get something like this:
corertr1#show ipx interface brief
Interface IPX Network Encapsulation Status IPX State
FastEthernet0/0 C0000001 SAP up [up]
FastEthernet0/1 unassigned not config’d admin down n/a
Ethernet1/0 C0010001 SAP up [up]
Ethernet1/1 C0010002 SAP up [up]
Ethernet1/2 unassigned not config’d admin down n/a
Ethernet1/3 unassigned not config’d admin down n/a
Ethernet1/4 unassigned not config’d admin down n/a
Ethernet1/5 unassigned not config’d admin down n/a
Ethernet1/6 unassigned not config’d admin down n/a
Ethernet1/7 unassigned not config’d admin down n/a
So far, so good. Â Now the next question is, does the router see the server? Â And what kind of services are available on the network? Â This can be found with the ‘sho ipx servers’ command.
corertr1#sho ipx servers
Codes: S – Static, P – Periodic, E – EIGRP, N – NLSP, H – Holddown, + = detail
U – Per-user static
3 Total IPX Servers
Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf
P 4 FPNWDC_NW DEAD0001.0000.0000.0001:0451 2/01 1 Et1/0
P 444 VIRTUALLYFUN!FPNWDC DEAD0001.0000.0000.0001:84C8 2/01 1 Et1/0
P 640 FPNWDC DEAD0001.0000.0000.0001:E885 2/01 1 Et1/0
Everything is looking good! Â As you can see my virtual Netware server (FPNW on NT 4.0) is type 4, and called FPNWDC_NW. Â SAP types 444 and 640 are for Windows NT, with 444 being the NetBIOS Browser/Domain control service.
IPX is a rather chatty protocol, and it is easy for things to go wrong. Â Another fun command is ‘show ipx traffic’ which will let you get some idea of what kind of chat is going on.
corertr1#show ipx traffic
System Traffic for 0.0000.0000.0001 System-Name: corertr1
Time since last clear: never
Rcvd: 149 total, 34 format errors, 0 checksum errors, 0 bad hop count,
100 packets pitched, 29 local destination, 0 multicast
Bcast: 126 received, 64 sent
Sent: 79 generated, 18 forwarded
0 encapsulation failed, 2 no route
SAP: 0 Total SAP requests, 0 Total SAP replies, 3 servers
0 SAP general requests received, 4 sent, 0 ignored, 0 replies
0 SAP Get Nearest Server requests, 0 replies
0 SAP Nearest Name requests, 0 replies
0 SAP General Name requests, 0 replies
18 SAP advertisements received, 15 sent, 0 Throttled
4 SAP flash updates sent, 0 SAP format errors
RIP: 2 RIP requests, 0 ignored, 2 RIP replies, 4 routes
9 RIP advertisements received, 30 sent 0 Throttled
7 RIP flash updates sent, 0 atlr sent
4 RIP general requests sent
0 RIP format errors
Echo: Rcvd 0 requests, 0 replies
Sent 10 requests, 0 replies
0 unknown: 0 no socket, 0 filtered, 0 no helper
0 SAPs throttled, freed NDB len 0
Watchdog:
0 packets received, 0 replies spoofed
Queue lengths:
IPX input: 0, SAP 0, RIP 0, GNS 0
SAP throttling length: 0/(no limit), 0 nets pending lost route reply
Delayed process creation: 0
EIGRP: Total received 0, sent 0
Updates received 0, sent 0
Queries received 0, sent 0
Replies received 0, sent 0
SAPs received 0, sent 0
Trace: Rcvd 0 requests, 0 replies
Sent 0 requests, 0 replies
In this brief guide, I’m not going to even get into all of this, however it is important to know that the router has sent things, and received things back.
Another thing that is different about IPX vs TCP/IP is that each server has it’s own internal network, where the services originate from. Â You can see this with the show ipx route command
corertr1#show ipx route
Codes: C – Connected primary network, c – Connected secondary network
S – Static, F – Floating static, L – Local (internal), W – IPXWAN
R – RIP, E – EIGRP, N – NLSP, X – External, A – Aggregate
s – seconds, u – uses, U – Per-user static/Unknown, H – Hold-down
4 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.
No default route known.
C C0000001 (SAP), Fa0/0
C C0010001 (SAP), Et1/0
C C0010002 (SAP), Et1/1
R DEAD0001 [02/01] via C0010001.5254.0012.3456, 10s, Et1/0
As you can see from the SAP advertisements above, and the route here, the server is configured for it’s internal network to be DEAD0001.  The router picked up the advertisement from C0010001.5254.0012.3456, which breaks down as c0010001 being the network the server is on (the server network), and 5254.0012.3456 being the MAC address of the server.
The real test comes from trying to use a client.
Netware 3.12 client
As you can see, this MS-DOS client attached to the client vlan, can see and interoperate with the virtual NetWare server.
This pretty much covers the basics of getting IPX/SPX working. Â Logically the next thing to do would be to configure routing and get IPX working throughout the WAN. Â But I’m going to save that for a later time.
The more ‘advanced’ topics of IPX involve filtering, as it was a common problem in large networks where you could simply have too many servers, and they would be constantly talking among themselves. Â Another problem is licensing, where some products are licensed in certain areas, and you want those licenses to stay in a geographic area. Â Latency was another issue too, it was insane to say use a SNA server in Japan, to talk to a mainframe in Arizona when you were in Arizona. Â Or if you had a 3rd party, and you only wanted them to connect to a print server, and a single file server, you would setup access-lists on your peer router, much in the same way that we setup firewalls in this fine modern age 😉
As always, the source code is here.
New updates from the changelog:
This release contains 48 build/bug fixes, including an important security fix for CVE-2013-4344 involving SCSI disk emulation: http://www.openwall.com/lists/oss-security/2013/10/02/2 Fixed by: scsi: Allocate SCSITargetReq r->buf dynamically Thank you to everyone involved! 62ecc3a: Update VERSION for 1.6.1 release (Michael Roth) fdcbe7d: scsi: Allocate SCSITargetReq r->buf dynamically (Asias He) 1b5f770: qemu: Add qemu xen logic for Xen HVM S3 resume (Liu, Jinsong) bc05a48: qemu: Adjust qemu wakeup (Liu, Jinsong) ba20326: coroutine: add ./configure --disable-coroutine-pool (Stefan Hajnoczi) ae00a27: piix4: disable io on reset (Michael S. Tsirkin) 61fbeb6: vmdk: fix cluster size check for flat extents (Fam Zheng) fc06b43: rbd: avoid qemu_rbd_snap_list() memory leaks (Stefan Hajnoczi) 6bbb9d8: tap: Use numbered tap/tun devices on all *BSD OS's (Brad Smith) b314120: iov: avoid "orig_len may be used unitialized" warning (Michael Tokarev) dc6fbaa: xhci: emulate intr endpoint intervals correctly (Gerd Hoffmann) c8adc0d: virtio-blk: do not relay a previous driver's WCE configuration to the current (Paolo Bonzini) aeab582: blockdev: do not default cache.no-flush to true (Paolo Bonzini) 5c20c1f: tci: Fix qemu-alpha on 32 bit hosts (wrong assertions) (Stefan Weil) 5d2de77: kvmvapic: Clear also physical ROM address when entering INACTIVE state (Jan Kiszka) 7ea8a3c: kvmvapic: Enter inactive state on hardware reset (Jan Kiszka) 50b31e8: kvmvapic: Catch invalid ROM size (Jan Kiszka) 4b5b472: chardev: fix pty_chr_timer (Gerd Hoffmann) 76f6989: pcnet-pci: mark I/O and MMIO as LITTLE_ENDIAN (Aurelien Jarno) 8b4b3a7: qapi-types.py: Fix enum struct sizes on i686 (Cole Robinson) 41900b0: pc_q35: Initialize Xen. (Anthony PERARD) 755ec4c: pc: Initializing ram_memory under Xen. (Anthony PERARD) dc0973b: qxl: fix local renderer (Gerd Hoffmann) b6d163f: ehci: save device pointer in EHCIState (Gerd Hoffmann) a1991d0: ne2000: mark I/O as LITTLE_ENDIAN (Aurelien Jarno) 1110014: exec: check offset_within_address_space for register subpage (Hu Tao) 2a93d3d: Revert "memory: Return -1 again on reads from unsigned regions" (Jan Kiszka) 7ab1044: memory: Provide separate handling of unassigned io ports accesses (Jan Kiszka) e8601a4: w32: Fix access to host devices (regression) (Stefan Weil) 96b14d0: usb: parallelize usb3 streams (Gerd Hoffmann) 9dbfbb8: xhci: reset port when disabling slot (Gerd Hoffmann) 57ea2d2: exec: always use MADV_DONTFORK (Andrea Arcangeli) 1cd7138: virtio_pci: fix level interrupts with irqfd (Michael S. Tsirkin) 9fab8e1: exec: fix writing to MMIO area with non-power-of-two length (Paolo Bonzini) 2ffbe03: adlib: sort offsets in portio registration (Hervé Poussineau) f9fd82e: target-i386: fix disassembly with PAE=1, PG=0 (Paolo Bonzini) da4e203: block: expect errors from bdrv_co_is_allocated (Paolo Bonzini) c09a463: Revert "usb-hub: report status changes only once" (Gerd Hoffmann) c0a5eb8: xhci: fix endpoint interval calculation (Gerd Hoffmann) 358bb0d: virtio: virtqueue_get_avail_bytes: fix desc_pa when loop over the indirect descriptor table (yinyin) 3fe494e: pseries: Fix stalls on hypervisor virtual console (Anton Blanchard) a73c74f: pc: fix regression for 64 bit PCI memory (Michael S. Tsirkin) 964e0d4: scsi: Fix scsi_bus_legacy_add_drive() scsi-generic with serial (Markus Armbruster) 11b0ab7: usb/dev-hid: Modified usb-tablet category from Misc to Input (Marcel Apfelbaum) d6dcfd6: scripts/qapi.py: Avoid syntax not supported by Python 2.4 (Peter Maydell) 2607906: rdma: silly ipv6 bugfix (Michael R. Hines) 52f99b0: target-ppc: fix bit extraction for FPBF and FPL (Aurelien Jarno) c0c080c: gdbstub: Fix gdb_register_coprocessor() register counting (Andreas Färber) 670599a: block: ensure bdrv_drain_all() works during bdrv_delete() (Stefan Hajnoczi)
I have not done a build as of yet.
(this is a guest post from Tenox)
#197 – Aclock ARM Windows RT by Peter Godwin
#198 – Alock M68K LynxOS by Plamen Mihaylov
#199 – Aclock PDP11 DEMOS by Dima Naumov
And long long long awaited…
#200 – Aclock PowerPC WindowsNT HAL Driver by myself
No cheating with numbers! Compiled and ran today on my ThinkPad 860. Just realized it’s #200. I think celebration with BSOD is in order! The screenshot was made using IP KVM. I will make an actual photo of the laptop screen another day.
Again thanks for everyone for contributions!
Last but not least there is a screenshot of previously cross compiled Aclock PowerPC OS/2 running on ThinkPad 850. Both the port and picture are courtesy of Michal Necasek of OS/2 Museum. Hope he won’t kill me for leaking the photo:
