So I’ve had a few pre-releases, and I’ve not ported anything to it as yet so it’s been kind of silly. So at any rate I figured I’d clean up dungeon to run. So I managed to get the source onto the drive under qemu (-hdb fat:\temp\zork), and from there I got it to compile, and it crashed out.
Well that was painful!
So I took a que from the sample directory, and saw how it built a simple hello world, and took notice of the ‘cvtomf’ process… No doubt this early pre-release stuff is not anywhere near as stable as what NT was when it was around late 1992 or when it shipped in 1993. So spending some 30 minutes with the makefiles I got an exe that didn’t bluescreen the OS…
But still crashed. If only I had a debugger… Oh wait, what is this? Some kind of built in debugger?
I’ve never used NTSD, or the “NT Symbolic Debugger” before. It’s like debug from MS-DOS days, just with far more bells and whistles… Although the pre-release versions are lacking a lot of these features, I did manage to find the #1 thing I end up using, and that is the callstack, it’s bt in gdb speak, but it’s nice to see who called who before it exploded.
Here you can see how the program flowed from the mainCRTStartup which then catapults into main, then we see it calling sigcatch & signal, then it dies. Well I’m pretty sure that Zork doesn’t need signals, and that Windows NT around 1991 was far from feature complete and I bet emulating Unix signals wasn’t exactly high on the priority list.. If anything they were going nuts about meeting some kind of Comdex show deadline, and trying to bring the MIPS port up to parity with the i386. So I did the logical thing, which was to remove the signal portions from f2c & libf2c, and recompile.
So here we go, All the hallmarks of 1991 and Windows, we’ve got solitare, reversi and Zork (Dungeon) translated from fortran into C, and actually running!
So here is October of 1991, and December of 1991. Both needed long filenames to compile, I just used a HPFS slave disk. I just used Windows NT 3.51 to transfer stuff in & out as it’s got TCP/IP to make it easy, as it’ll also read HPFS. I guess you could use the MS-DOS pkunzip and fix the filenames yourself but I’ll leave that to the reader. The source trees ought to be identical, I left the object files & executables in there.. Naturally the December pre-reelase won’t run the October executable… Or link correctly with it’s object files.
I’d also imagine it’ll work on any version of NT that ships with a cl386 SDK… and probably any modern one by fixing the reference to cl386 in the makefile.