After much fighting, and apparently being blocked by one of my ISP’s, I got back onto HECnet! Even better I was able to verify operation with HECnetNT!
Like last time I was able to bind Pathworks 32’s DECnet onto a MS Loopback adapter, and then use the bridge to connect onto that loopback to a local Linux bridge (which is also hosting a virtual SIMH VAX instance).
The big problems I ran into is that I originally had setup SIMH to use a tap interface, and connect into a bridge, as mentioned on the raspberrypi.org forums, however the HECnet bridge program seems to have difficulty injecting packets onto the bridge interface. I suspect the ‘correct’ thing to do is to remove libpcap from the bridge, and re-write it to be a tuntap client. There is enough examples, I should be able to do this, but I just wanted the thing to work, so I didn’t want to tackle this just yet.
Instead I had SIMH attach to the Linux lo adapter (typically where 127.0.0.1 lives), and the HECnet bridge program, and success! Even better the interface has been up now over 12 hours since it was brought online.
Well wasn’t that fun?
Want to learn more about HECnet? simply check it out! But as the short order goes it’s a hobbyist DECnet of machines spread out across the globe running the ancient DECnet protocol on various legacy style systems.
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.
The first thing is the hard disk. I was lucky in that this machine came with a 40GB disk, the Hitachi Desktar 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!
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, The 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.
You will have patch the INITIAL.IN_ and SETUP.IN_ files to allow installation on any new processor.
STF_PROCESSOR = “” ? $(!LIBHANDLE) GetProcessor
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.
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!
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!
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.
I know it’s utterly pointless… But yeah GCC 2.8.1 + EMX 0.9d, hosted (running) on Win32. The main reason is that I wanted to be able use use my substantially faster Win64 machines to build stuff for OS/2. And since I have a 4 core (+4 hyper thread), I want to be able to use make with the -j 16 flag, and say compile QuakeWorld/2 in under two seconds.
I was able to get the binutils 2.6 derived stuff to compile, along with the ‘ancient’ binutils which is notably the linker that EMX depends on. I would imagine this ought to be able to compile PDOS, although my own simple attempt at InfoTaskForce met with spectacular failure. While it does compile fine using an older EMX 0.8h based release.
Well it turns out that this ‘system32’ directory is actually the 64bit system directory! And attempting to do this will just result in the error:
The module was loaded but the call to DllRegisterServer failed with the code 0x80040005. Well great. This typically goes back to a permissions issue, or the wrong regsvr32.exe being called.
However on a Win64 based OS, you actually need to specify the Win32 version of regsvr32 which actually lives in the SysWOW64 directory, and run the command prompt at administrator! So you would run it like this:
With this COM object registered, you can now launch the Enterprise manager!
Also I found a semi fun way to rename the SQL server:
sp_configure ‘allow updates’, 1
reconfigure with override
Running this and it renamed the local SQL instance, and shut it down. Restarting and it connected to itself just fine. Naturally change YOURSERVERNAME to whatever your hostname is. SQL server always wants to be called whatever the actual hostname is, otherwise things break in strange and confusing ways.
Is this terribly useful? Probably not. But I think it’s kind of interesting to run 90’s era server software in the 21st century. Sure I wouldn’t want to run any of it in any type of production environment, but it shows at it’s core how Win32 has not drifted. However looking at the Microsoft Management console of SQL Server 7.0, and how it will not either run on Windows 10, nor will the snapin run show just how fragile the house of COM turned out to be, and meanwhile good old fashioned Sybase/Win32 code still runs from 1993 onward.
I suppose the next thing to do is to try it on Wine, or a fun enough debugger/syscall trace to see what on earth SQL 7.0’s problem is. I don’t have any doubt that it’s nothing that can’t be fixed, although back to the root point, would you really want SQL 7.0 in 2016… or even SQL 2000 for that matter.
I don’t do advertising, as I know I don’t get that much in the way of traffic. If anyone cared it’s just over 1.7 million hits a year (break it down, it’s not much! Were only talking about slightly more than three hits every minute!). But I saw that my Apache on Windows NT 3.1 is averaging 100 hits a day, and I saw that I’d been scraped and mirrored on 126kr.com ..Oddly enough they didn’t scrape the Apache site.
First I was pissed, but you know as they say you can’t keep anything original on the internet, so just embrace it. Inadvertently they do link back to the NT Apache, which then links back to me. I guess I only care that there may be other things that readers may find interesting that 126kr hasn’t mirrored yet.
I had a request to help get a GCC+Binutils running as native win32 exe’s something comperable to the ancient ‘ultra’ N64 toolchain done by Kyoto Microcomputer (resume pdf). One interesting thing about their toolchain is that they used a common object format for MS-DOS, DOS/V and MS-DOS on the PC-98 format, along with Win32. However the Win32 runtime doesn’t like Win64 environments. On Win64 the exew32 driver just complains:
Can’t allocate memory (Error Code=487)
However the stubs in all the exe’s reference exegcc98 exegccv DOS extender’s along with a exegcc. However googling around yields nothing.
Running on a x86 version of Windows, however the tools run and report gcc 2.7.2 release 1.2 and the binutils version is simply 2.6 with BFD version 2.6. So going with this, and the request to keep it 1997 vintage I went ahead with Gcc 22.214.171.124 and Binutils 2.8.1 as they are the end of the line in both trains of code.
To configure is really a snap, as both support the Windows NT platform directly
sh configure --host=i386-winnt3.5 --target=mips-elf
Binutils 2.8.1 notes:
make sure this uses MS-DOS rb wb type constraints!
There is no sbrk on my MinGW32 … so comment out all the sbrk stuff.
My sed LOVES UNIX style text files, so this one shouldn’t be in MS-DOS CRLF format.
mkdir only accepts the path on Win32. Also there is now chown.
Gcc 126.96.36.199 notes:
‘__inline’ for is_reserved_word needs to be commented out.
Set like the following for both ASM_FINAL_SPEC to prevent the t-mips from trying to be run.
#define ASM_FINAL_SPEC “\
Just because we are on Windows NT, doesn’t mean we want an .obj object suffix.
__spawnv : __spawnvp work better as _spawnv : _spawnvp
*((void **)__o->next_free)++ = ((void *)datum);
confuses newer compilers, with this error message:
obstack.h:341:32: error: lvalue required as increment operand
replace it with with:
*(__o->next_free)++ = ((void *)datum);
So at the end I have a cross compiler, and I can generate object files, and link files that the final tool MILD can then use and produce N64 ROM images. It’s not a 100% solution, as I don’t see any mention of MILD being GNU, however the compiler and binutils is running on Windows 10 x64!
Unlike Windows Vista, the setupdll.dll from Windows NT 4.0 will not work. I used the one from Windows NT 3.1, and it will run the setup program fine, but the file copy bombs out. I went crazy and modified the setup.inf to not actually copy files, take an xcopy of the raw files from an old install, and it won’t even try to install the service, it just builds a master database, and exits.
Trying to run the SQL Server directly, and you get this fun error:
16/10/13 21:19:08.40 kernel Unable to start due to invalid serial number.
Well isn’t that great. So naturally you either have to install it, or just import an existing registry key setup like this SQL.REG file.
If you are so inclined, you can even remove named pipe support, and have it listen only on TCP/IP. Or the other way around. Or even change the TCP port.
In the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQLServer\Server key there should be a Multi-String key called ListenOn … and it’s just the network transport DLL, and how they listen. As you can see SSNMPNTW is the named pipe transport, and SSMSSOCN is the TCP/IP transport.
SQL Server really wants to load the TCP/IP trasnport DLL from the Windows\System32 directory. On 64bit versions of Windows, however that means copying the SSMSSOCN.DLL file to the SysWOW64 directory, in order to have TCP/IP networking.
SQL server is not terribly useful in it’s current state as it turns out that master database is actually empty. So without stored procedures or much of anything you really can’t do anything with it. However looking at the install directory there is a bunch of SQL scripts. Even better on the VM where I’ve installed it, there is some output files, that by their date & time tell me in what order to run them!
First things first, I copy the following files from the C:\SQL\DLL diredctory to the C:\SQL\BINN directory so I don’t have to mess with paths:
Now I can run the SQL server from the C:\SQL\BINN directory
And now it’s running. If there is any issues, or your master database is either damaged, or just plain doesn’t exist, you can create one with the BLDMASTR.EXE program.
C:\sql\BINN>BLDMASTR.EXE Buildmaster 4.20a NT : Wed Jan 26 12:37:00 1994
Master disk name? (default is master.dat) :
Master disk size (in 2k blocks)? (default is 6144) :
Configuration only? (default is N) (y or n) : n
Databases only? (default is N) (y or n) : n Master device: master.dat writing configuration area writing the MASTER database writing the MODEL database writing allocation pages for remaining 7 MB, (3584 pages) 7 MB Buildmaster complete
It’s that simple! Move the master.dat file into the C:\SQL\DATA directory and if the server doesn’t find it by itself, you can just tell it where it’s located:
START SQLSERVR.EXE -d ..\DATA\master.dat
And it should start.
Now the file CONFIG.SQL needs to be modifed (if you have a prior config) or created.
The two key lines are:
update master.dbo.sysdevices set phyname=’C:\SQL\DATA\MASTER.DAT’ where name = ‘master’ sp_addserver YOURMACHINE,local
Which as you can imagine simply sets where the master database lives, and what the machine name is, as SQL server LOVES to know the correct machine name. With that done, here is my simple script for populating the master database:
And once this has finished it will have populated all the tables in your master database. Hit CTRL+C in the SQL Server window, and it’ll shut down. Re-launch it, and it’ll be initialized.
Assuming this all went according to plan, you can now launch SQLADMIN, the SQL Administrator, and then you can get a connect screen like this (I only got it running with the named pipes transport…)
Remember by default the sa user has no password!
And we are good to go! Feel free to grab SP4, and apply it by unzipping, and copying the files & dll’s to their respective places. So there we go, from January of 1994, to October of 2016, SQL Server still running!
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
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.