A course at UCLA in the Computer Science Department is catalogued as CS 33, "Systems Programming", also known as the assembly language course. As of Fall 1999, the course still uses a fictional chip called CUSP (Carleton's Utterly Simple Processor), created by Gerald M. Karam and John C. Bryant at the University of Carleton, in Ottawa, Canada, (thanks to Clayton Scott, a former student there, for that info).
Since the academic quarter before I took CS33 (That'd be March 1997), I ran (and am still running) a complete, high-speed, low-resource Free operating system called GNU/Linux (running on a Pentium/100 48MB RAM, if you must know). In short, it's a completely Free act-alike of the Unix operating system. (FreeBSD is a Free version of Unix. An outright version, not just a "similar version".)
There is one problem, however. The CUSP machine, being completely fictitious is implemented as an emulator. However, the original emulator (untouched since... 1992???) was written in Turbo Pascal, and compiled for MS-DOS only. No source code available.
Linux, being an entirely different kernel, and built with the concepts of a Real Operating System in mind, does not operate the same way as MS-DOS. Therefore, MS-DOS executables will not work under Linux without some heavy duty mucking.
Enter DOSEMU, the MS-DOS emulator. With a disk image containing MS-DOS binaries (utilities), DOSEMU runs under Linux to run MS-DOS programs within an emulated MS-DOS environment. Instead of a mere disk image, I had a FAT partition back from my Windows-using days, which I gave DOSEMU complete control over (raw disk access). Well, I was desperate to get DOSEMU up and running by any means necessary. This was how I ran CUSP for the class. (If you want to make this sound sick, yes, I was running two levels of emulation.) However, something went terribly wrong. Somehow DOSEMU crashed. MS-DOS, being the good little obedient set of service routines it is, went on and trashed the disk. My final CS 33 project was blown away, and all I could manage was the feeble incomplete sources before I copied it to the disk image for completion.
So, here I am, very peeved over the fact that I pretty much failed CS 33 because CUSP fell over, causing DOSEMU to choke, and blowing away my final project (which was a fairly hefty chunk of the final grade). I place the blame primarily on CUSP's binary-only (no source code available) nature. And so I intend to change that. Sort of.
Towards the end of CS33, a classmate of mine pointed out that his machine was too fast for CUSP. What he and the professor concluded was that the host machine ran so fast that CUSP's interrupts were coming out incorrectly... tripping over itself, if you will. Not only does PHFC run way slower, but such problems can be correctable, with the source freely available.
Windows 2000 is now the Next Big Thing from Microsoft, the heir apparent in their line of operating systems, descended from MS-DOS. Well, maybe not exactly. Hearsay goes that W2K is based on the NT lineage, which would suggest that many ``clever tricks'' of MS-DOS won't work in W2K (protected memory and all that hubbub). I don't think the original CUSP used such ``clever tricks'', but one can never know [if CUSP will fail to run under W2K].