So I came across this recently, and unlike the previous version I had for Windows 3.1, This version is for Windows NT. And unlike the Windows 3.1 version this version does actually run on the shipping version of Windows NT 3.1, and thus will work all the though including Windows 10 on x64. The setup program unfortunately doesn’t complete leaving it ‘unlicensed’ however it’ll still run.
The diskettes for the Windows 3.1 version I have are dated 11-23-93, but once installed the compiler is actually from February of 1993, with the Windows NT version being dated October of 1993.
So the nice thing with the Windows NT version is that you don’t have to mess with the compiler, and linker, it’ll just run. And just like Visual C++ 1.0 / 1.10 for NT the linker doing a release build will always result in an exe being at least 2 megabytes in size.
I know that this is pretty much useless for 99.9999% of people. Yes it’s ancient Fortran. Yes Fortran PowerStation 4.0 is far more comprehensive. Yes after it was sold to Compaq as part of some deal over the collapse of Dec & Windows NT, then sold out to Intel. And GFortran is free.
(This is a guest post by Antoni Sawicki aka Tenox)
In a recent blog post Wanted: Console Text Editor for Windows I lamented about lack of a good console/cmd/PowerShell text editor for Windows. When researching for the article I made rather interesting discovery. There in a fact has been a native Windows, 32bit, console based text editor. It was available since earliest days of NT or even before. But let’s start from…
…in the beginning there was Z editor. Developed by Steve Wood for TOPS-20 operating system in 1981. Some time after that, Steve sold the source code to Microsoft, which was then ported to MS-DOS by Mark Zbikowski (aka the MZ guy) to become the M editor.
M editor
The DOS-based M editor was included and sold as part of Microsoft C 5.1 (March 1988), together with the OS/2 variant, the MEP editor (perhaps M Editor Protected-mode). The official name of M/MEP was simply Microsoft Editor. The same editor was also available earlier (mid-1987) as part of the MS OS/2 SDK under a different name: SDKED. Note that normally SDKED insists in operating in full screen mode. Michal Necasek generously spent his time and patched it up so that it can be run in windowed mode for your viewing pleasure.
SDKED on OS/2
However my primary interest lies with Windows NT. The NT Design Workbook mentions that in the early days a self-hosting developer workstation included compiler, some command line tools and a text editor – MEP. Leaked Windows NT builds sometimes include IDW, Internal Development Workstation, which also seem to contain a variant of the same editor. In fact some these tools including MEP.EXE can be found on Windows NT pre-release CD-ROMs (late 1991) under MSTOOLS. It was available for both MIPS and 386 as a Win32 native console based application.
MEP on Windows NT Pre-Release
The editor was later also available for Alpha, i386, MIPS, and PowerPC processors on various official Windows NT SDKs from 3.1 to 4.0. It survived up to July 2000 to be last included in Windows 2000 Platform SDK.
M editor from NT SDK 3.1 running on Alpha AXP
MEP from NT SDK on Windows NT 4.0
The Win32 version of MEP also comes with an icon and a file description which calls it M Editor in NT 3.1 SDK and later Microsoft Extensible Editor.
From time perspective, it was rather unfortunate that this gem was buried in the SDK rather than being included on Windows NT release media. However I can understand that the editor wasn’t very user friendly or intuitive, compared to say edit.com from MS-DOS. It came from a different era and similar to VI or Emacs, didn’t have “PC user friendly” key bindings or menus.
But that’s not the end of the story. The editor of many names survives to this day, at least unofficially. If you dig hard enough you can find it on OpenNT 4.5 build. For convenience, this and other builds including DOS M, OS/2 MEP and SDKED, NT SDK MEP can be downloaded here.
Digging through the archive I found not one but two copies of the editor code, lurking in the source tree. One under the name MEP inside \private\utils\mep\ folder and a second copy under name Z (which was the original editor for TOPS) in\private\sdktools\z folder. MEP was included in Platform SDK, while Z was only available as part of IDW.
Doing a few diffs I was able to get some insight on the differences. Looks like MEP was initially ported from OS/2 to NT and bears some signs of being an OS/2 app. The Z editor on the other hand is a few years newer and has many improvements and bug fixes over MEP. It also uses some specific NT only features.
Sadly the internal Z editor was never released anywhere outside of Redmond. All the versions outlined so far had copyrights only up to 1990, while Z clearly has copyright from 1995. Being a few years newer and more native to NT I wanted to see if a build could be made. With some effort I was able to separate it from the original source tree and compile stand alone. Being a pretty clean source code I was able to compile it for all NT hardware platforms, including x64, which runs comfortably on Windows 10. You can download Z editor for Windows here.
Z editor on flashy Windows 7 x64
But how do you even use this thing?
Platform SDK contains pretty solid documentation in tools.chm.
Here is a handy cheat sheet:
Last but not least there is a modern open source re-implementation of Z editor named K editor. It’s written from scratch in C++ and LUA and has nothing to do with the original MEP source code. K is built only for x64 using Mingw. There are no ready to run binaries so I made a fork and build.
K editor on Windows 10 x64
The author Kevin Goodwin has kindly included copies of original documentation if you actually want to learn how to use this editor.
I have this P4 I got for super cheap in Hong Kong, that came with Windows 98 of all things. Naturally I want to load something more useful like Windows NT 3.1 onto it, so I did have to do some tweaking first.
Storage
The first thing is the hard disk. I was lucky in that this machine came with a 40GB disk, the Hitachi Desktar IC35L060AVV207-0.
HGST Deskstar 180GXP IC35L060AVV207-0
Now what makes this disk great, is that it can be jumpered down to act like an 8GB disk, so that things like MS-DOS and older OS’s like Windows NT can recognize the disk. Â Even nicer that the jumper settings are on the disk!
Disk jumpers
My board supports booting from IDE, which is nice as I could paritition and format the disk from MS-DOS 5.00, and make sure things were working fine.
However it really doesn’t matter as over on Beta Archive, TheCollector1988 has made an ATAPI driver available for not only Windows NT 3.1, but also various beta versions as well! Â You can find the post, and the links to download here! (mirror here). Â Now you can install from the boot diskette & a driver diskette and load the rest of the OS from CD-ROM.
Processor
You will have patch the INITIAL.IN_ and SETUP.IN_ files to allow installation on any new processor.
Change
STF_PROCESSOR = “” ? $(!LIBHANDLE) GetProcessor
to
STF_PROCESSOR = $(ProcessorID_I586)
You can leave the files expanded, but this is needed if your CPU is newer than a Pentium (Yes a Pentium 60/66 type processor, so that is Pentium Pro, Pentium II, Pentium III, Pentium 4 and beyond…). Â But yes, this is great! Â No need to try to dig up old SCSI cards, SCSI disks, and SCSI CD-ROM drives.
Network
And much like Qemu and VMware, the AMD PCnet is a great go to PCI card, and I was able to find this IBM 11H8130 Type 8-Z 10BaseT PCI Network Card which works!
IBMÂ 11H8130
The card works great with 11265315.exe set of drivers, OR disk image pcnet.7z .  But for sure the key is the in the chipset!
AMD AM79C970AKC PCnet(tm)-PCI II
As this chipset, the AMD AM79C970AKC is the one that is explicitly listed as compatible.  This IBM card provides an AUI port, along with a 10baseT port.
Post install, service packs
Of course when installing Windows NT 3.1, you’ll want service pack 3, the last update to the OS.
Windows NT 3.1 will allow you to install on FAT, HPFS, and NTFS v1 partitions and disks. Â The TCP/IP is a 3rd party, from Spider that does not support DHCP. Â Outside of doing it just because, it really is better to go with NT 3.5 or 3.51 as they have better SMP support, are much faster, and have a much more robust network stack.
Unlike Serweb 0.3, Apache is HTTP 1.1 compliant, which means that I can put it behind haproxy, and enjoy the fact it doesn’t need a dedicated IP address.
Although I can’t imagine anyone wanting it, here is the binary/source and my htdoc dump. Download it here: apache-NT-31.zip & unzip.exe
Apache console mode
I had to pull out some stuff, like some of the service features, so it really only runs as a console app.
I’ve compiled it with /Zi meaning full debug and no optimization. If you want to re-compile you’ll probably want either the Win32 SDK, or Visual C++ 1.0 32bit, and replace the headers and libraries from the Windows NT 3.5 SDK. Much like trying to build GCC 2.6.3 on Windows NT.
Also in a silly way, thanks to Qemu, I’m now running both OS/2 & Windows NT on the same server, running Linux.
I don’t know what I was expecting, but I thought I’d try to install Windows NT 3.1 Advanced Server in a KVM virtual machine. Â No doubt the processor is just too new. Â The -cpu 486 / -cpu pentium flags didn’t help things out at all. Â However using Qemu has it running just fine.
I also had this crazy idea that haproxy could front HTTP 1.1 requests into serweb so I could go back to having a Windows NT 3.1 web server. Â Naturally that didn’t work.
502 Bad Gateway
The server returned an invalid or incomplete response.
Oh well.
The useless update, is that I managed to get Apache 1.3.4 to compile and run on Windows NT 3.1!
When most people think of old PC networking, they think ethernet, and of course most people I know think of the NE2000. Â This card from Novel was cloned, and quite popular as time went on. Â Its amazing how many variations of this card there was, and there is even a PCI version of this card, the RTL8029AS!
But that is not what this is about, as most OS stuff from the early 1990’s relies on another card, the 3com Etherlink II.
Notably products like IBM TCP/IP 2.0 for OS/2, Lan Manager for OS/2, Windows NT Pre-releases, Xenix, do not ship with NE2000 drivers, but they all support the Etherlink II card.
Now before you start jumping on fleabay, or scrounging around the Etherlink III card is *NOT* the same as the II, nor is it compatible!
My eight bit Etherlink II
Looking at the card, you can see it has *SOME* jumpers, that configure the IO Base, and where to locate its shared memory (or disable it). Â But notice there are no jumpers to select the IRQ, the DMA channel! Â I went in circles for a while looking for a softset utility for this card, and spent HOURS basically showing up with nothing. Â So I figured at this point I’d just download some drives, and see how long it’d take to magically get it working.
On my first attempt, I used the packet driver, so I could load up some QuakeWorld for MS-DOS. Â But something amazing happened, it worked on the default settings! Â Experimenting more, as I changed IRQ it always worked unless there was a conflict .. Â I then tried a Novel Netware client, but it didn’t work. Â Also I loaded the lanman client for OS/2 on OS/2 1.21 and it didn’t work ether. Â I was perplexed. Â Then I found out two important things from an ancient usenet posting:
There is no softset program, because the device driver configures the card, and can change any/all of its hardware characteristics
Some drivers don’t detect if they should be using the internal transceiver, or an external one, and have to be told.
So I looked at the protocol.ini for lanman OS/2 and sure enough there was this entry, commented out:
TRANSCEIVER = EXTERNAL
And the Netware client just needed the following statement added:
CONNECTOR DIX
And now I can happily mount NetBEUI shares, mount my NetWare server, and of course use WatTCP programs from DOS without issue!
Donor time!
I was going to load an early Windows NT Preview onto my Aptiva, but then all it would do was crash with a kernel panic of 0x00000032. Then it hit me, the hard disk I have is 2GB and this early version can only handle disks up to 512MB. Â So I was looking around where to get a small enough disk, and then I thought what the heck, and took apart a ‘new’ machine I scored last week, an IBM PS/1!
The IBM PS/1 was kind of a disappointment as it cannot run OS/2!  Can you believe it, IBM made a machine that can’t run their flagship Operating System??  As far as I can tell the heart of the matter is that the IDE controller doesn’t live at the default port/irq that any other PC uses, so OS/2 or any other protected mode OS can’t detect it.  I only have 2MB of ram, so loading OS/2 2.0 is out of the question.  So for the sake of the experiment, I took the disk out of this poor IBM PS/1 2121 and put it ‘on’ the Aptiva.
Pentium 150Mhz, 32MB of ram, and an 80MB disk!
First I really wondered if the 80MB disk would be big enough, but surprisingly after a format, and installation of IBM DOS 4.00 (its what the PS/1 runs in ROM and really really likes!) and using the network to bootstrap the files, it happily fit with the SDK in 40MB! (it adds another 20MB for swap…).
Its amazing just how large OSs have gotten over the years, but yeah at the same time, this version of NT is not ready for prime time that is for sure!
So I load it up, and notice two things… One its insanely slow, and secondarily I can’t figure out how to configure the network card. So for some reason I just tried to start up the server/workstation, and do a net view and…
Early Windows NT preview with networking
It worked!
The best part was loading up the October 1991 Windows NT Preview, and it just magically worked, after starting the server/client services!
On the heels of my OS/2 upgrade path, I thought I’d take on Windows NT.
Windows NT 3.1
Originally planned as OS/2 3.0, OS/2 NT, or Portable OS/2, Windows NT began life as a portable version of OS/2 2.0 for RISC processors.  Even in the early design phase, it was decided that it was going to have multiple OS personalities.  With the arrival of Windows 3.0 everything changed, and it was decided to use WLO, or project porthole the port of Windows 3.0 to OS/2 1.2 as the basis of what would become Win32, the primary personality for OS/2 NT, however they could keep all the kernel work, as none of the initial design would have to be changed when they dumped the OS/2 2.0 cruiser personality.
Because NT was going to be the successor to OS/2, it naturally supported the FAT & HPFS file systems, but in addition it also supported the NTFS filesystem which included the journaling capability allowing it to survive some data loss, and to be able to quickly check the disk.
The NT 3.1 desktop
So after all the betas NT finally shipped in July of 1993.  The first thing that I was amazed by was the sheer size of it.  There was an incredible amount of floppy disks, and fully installed it could easily consume some 50MB for the OS + space for a swapfile. What was also amazing, and confusing for the users is that NT 3.1 looked just like Windows 3.1.  Even the same games/accessories were included and the look and feel was so much the same that most people couldn’t tell NT from Windows.
Windows NT 3.1 could run MS-DOS applications via the NTVDM (which is still around in 32bit versions of Windows 7!), OS/2 16bit text mode applications, specially compiled POSIX applications (vi was popular among unix people), Win16 applications which again rain inside of the NTVDM, along with a ‘speical’ version of Windows 3.1 which would then translate the system calls to the Win32 subsystem via thunking so that the applications could run seamlessly on the desktop, without requiring complicated drivers, unlike OS/2. And of course it could run the new breed of Win32 executables which included console, gui and service applications.
The ability for Windows NT to support multiple user accounts was a big change from the typical Microsoft one user / one computer approach, but it also changed the playing field with being able to run server programs on Windows that you didn’t have to login to the machine, and start yourself.  The best part being that you could manage these applications with Windows programs!  While it may seem impossible to imagine now, the big ‘database’ program at the time was Oracle, and if you didn’t have a mainframe or a mini computer to run it on, but wanted to go down the microcomputer path you either ran Oracle for MS-DOS, or you ran it on Novell Netware.  While networking was in Novell’s blood, setting up networking on MS-DOS could prove a chore.  Windows NT 3.1 may have shipped without  a netware requester, but it did include support for DLC, IPX/SPX, TCP/IP and NetBEUI.  This meant that Microsoft SQL Server could talk to more network types than a typical Netware setup. Another game changer was that the networking support, and namely TCP/IP was included in the box!  Up until this time TCP/IP solutions were typically 3rd party for both Windows, Netware, and even some UNIX (like Xenix!).
It is also worth noting that the TCP/IP in this version is from a 3rd party, SpiderTCP although once Microsoft was ready they did release their own stack which was in NT 3.5, an update for Windows for Workgroups that supported things like DHCP.
One major annoyance of OS/2 was that command prompts were either full screen or windowed, but they could not be switched, and some programs were flagged as full screen, so if you ran them from a window the system would flash to full screen, sawn a full screen session, maybe kick out some text, then switch back to the graphical screen. Â It was VERY annoying for tools that expected flags, as then you’d have to switch to a full screen session to even see what was going on. Â Windows NT addressed this off the bat, that VGA based systems could switch between fullscreen & windowed sessions by simply hitting alt+enter, and RISC / framebuffer video systems would be stuck in ‘windowed’ command prompts much like Windows Vista and other systems won’t let the ‘Command prompt’ window go full screen.
One big annoyance about Windows NT 3.1 is that all the Win16 applications (which was what almost everyone was using) ran in a SINGLE VM which meant that a single rouge application could crash out the VM, losing all the other Win16 applications work.  It wasn’t any better than what Windows 3.0/3.1 users were facing, and only OS/2 allowed people to run Windows application in separate sessions.
Another serious shortcoming in Windows NT is that the POSIX subsystem is basically brain dead, it doesn’t support any networking calls. The inability to port any networking UNIX code to NT made it pretty much worthless, and all I ever saw people do was setup vi on it.
Other than that, for a 1.0 release it supported an incredible amount of printers, sound cards, and even network cards the OS was far more stable than MS-DOS+Windows, although it did need a LOT of memory.. Â Microsoft gave away a TONNE of boxed copies of it back in the day, for all intents and purposes NT 3.1 was a commercial bust, lots of people I know tried it but nobody really used it, it was too slow, and too resource hungry at the time. Â But NT wasn’t written with 80386’s in mind, but rather the future. Â Windows NT 3.1 shipped with support for the MIPS R4000 CPU, and the Intel i386/i486/Pentium. Â The Dec Alpha had not shipped at this point so Alpha support was held back, and offered as a coupon upgrade.
For a test, I thought it’d be a good test to install Microsoft Word 5.5 for MS-DOS / OS/2 as a test, SQL Server 4.21, and Excel 3.0a for Windows. For fun I even installed Doom 1.1 for MS-DOS, which plays however there is no music as NTVDM has no pass through support to the sound hardware ports (unlike OS/2, I suspect it’d violate the whole principal of a ‘secure’ OS) and since there isn’t any soundblaster emulated devices there won’t be any sound.
Here is some videos of installing Windows NT 3.1 (from within MS-DOS because the CD-ROM support in NT 3.1 is all SCSI based that Qemu doesn’t emulate), and using Windows NT..
Windows NT 3.1 was later replaced by the smaller & more capable Windows NT 3.5 .
I just found out about, PX00307.pdf, basically its when Microsoft was thinking about breaking away from OS/2 and making the future all Windows based….
Its funny how they say that OS/2 PM has a better API, and at the same time were talking about having NT continue using an INT 21 interface for Windows.. No doubt this is all high level talk, Cutler would have killed anyone for even mentioning INT 21… lol
As mentioned in the great book Showstopper!, the first public demonstration of Windows NT was at the 1991 Fall Comdex.
And apparently it must have been quite a show.. In retrospect, but for stuff written down at the time there isn’t a heck of a lot to go on. I do find snip its like this after the fact:
But how about a good review? How about someone to kick the tires? I guess it was just too far fetched? Anyways I did find this ONE writeup in Infoworld:
And it is just gushing about SMP support. But if you think about it, SMP support around 1991 was almost non existent. It either fell into people who took UNIX and tried to make it more SMP friendly (ie giant spinlocks) or people who offloaded specific tasks to different CPU’s (Novell Netware). NT was like Mach in that it was going to be something totally different written for SMP hardware in mind, and presenting a personality much like an old trusty OS, be it POSIX, Win32 or the NTVDM running other stuff. The other thing the article mentions is that 300 of these developer discs were made.
So with some luck, someone actually sent me an installed copy of this historic version of Windows, so let’s take a look shall we?
The only thing I really can compare this to is the later December 1991 release, but here goes.
So first here we are booting up. Not surprisingly, like all version of Windows NT we start with a blue screen. And here we know it’s the official “32-Bit Development Kit October 1991.” version. I wonder if they even sold/gave these out at Comdex to some selected people… But I’d imagine they didn’t.
And here we are at the login screen. Just like the December 1991 version there is no passwords, and you can even login as SYSTEM. The background & color scheme was set in the image, I bet changing them is trivial.
Here we are at the desktop. It feels more like Windows 3.0 then 3.1, it may very well be mixed in with the beta Windows 3.1 program manager for all I know.
Here is the command prompt. It looks very OS/2 like with the square brackets around the prompt. Just like December.
So I figured, let’s search through ntoskrnl.exe for any trace of OS/2…
And here it is!
Buried in the binary is the true name of Windows NT, NT OS/2. Not that it matters. Also notice all the NT api calls. It looks like these early kernels weren’t to scared to share their interface names..
Now this is a big deal, look at all the multitasking! In 1991 getting this kind of tasking out of Windows 3.0 was an impossibility! I’ve got 6 copies of WinBez open, along with Winshap bounding around minimized. I’ve got a command prompt open, and I compile some code, and it keeps on going.
But really pictures don’t speak words for it, here is it in action!
I know it’s small, it’s blogspot’s formatting, but you can always view the direct video on youtube here. And you too can watch me compile & kill a troll. Very exciting!
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.
Hard.
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.
