What the heck is this? It sure could have been made a little more legible but it means that your BIOS needs to have the hardware assist turned on for virtualization. This kind of thing just reminds me so much of OS/2 and it’s SYSXXXX errors from back in the day.
Speaking of, once VMWare was running the display was incredibly tiny. This image really doesn’t do it justice, but it’s frankly impossible to read.
There isn’t much in the way of help for VMWare Player (aka freeloader) version users, however some playing around and I found an acceptable solution.
Simply find the shortcut’s location and jump to the compatibility tab, and set the “Override high DPI scaling to “System (Enhanced)”, hit OK and you are now good to go!
Now you can actually read what is going on. Also for anyone who cares, MS OS/2 1.21 really should be on a 100MB disk or so.. large disks & VMWare’s IDE don’t play along so well.
I have to admit it, that when I first heard about this I was HIGHLY skeptical, but sure enough it actually works.
Although I have gotten SQL Server 4.21a & 6.5 running on Windows 10 (The core from 6.0 works, but it’s pre-release COM objects for the Enterprise manager don’t like Windows 10) There were two stumbling blocks I never could get around. The first one turned out to be something trivial, which is SQL 4.21 would never listen on TCPIP.
Fixing SQL 4.21
It turns out that this actually was a simple fix.
17/09/21 19:40:24.00 server server name is ‘JADERABBIT’ 17/09/21 19:40:24.00 server Recovering database ‘model’ 17/09/21 19:40:24.00 server Recovery dbid 3 ckpt (45,26) 17/09/21 19:40:24.00 server Clearing temp db 17/09/21 19:40:24.03 kernel Using ‘SQLEVENT.DLL’ version ‘4.21.00’. 17/09/21 19:40:24.83 kernel Using ‘OPENDSNT.DLL’ version ‘4.21.09.02’. 17/09/21 19:40:24.83 kernel Using ‘NTWDBLIB.DLL’ version ‘4.21.00’. 17/09/21 19:40:24.83 ods Using ‘SSNMPNTW.DLL’ version ‘126.96.36.199’ to listen on ‘\\.\pipe\sql\query’. 17/09/21 19:40:24.83 ods Using ‘SSMSSOCN.DLL’ version ‘188.8.131.52’ to listen on ‘1433’. 17/09/21 19:40:26.04 server Recovering database ‘pubs’ 17/09/21 19:40:26.06 server Recovery dbid 4 ckpt (469,25) 17/09/21 19:40:26.06 server Recovering database ‘ultimate’ 17/09/21 19:40:26.06 server Recovery dbid 5 ckpt (524295,12) 17/09/21 19:40:26.06 server Recovery complete. 17/09/21 19:40:26.12 server SQL Server’s default sort order is: 17/09/21 19:40:26.12 server ‘bin_cp850’ (ID = 40) 17/09/21 19:40:26.12 server on top of default character set: 17/09/21 19:40:26.12 server ‘cp850’ (ID = 2)
The DLL for TCP/IP is SSMSSOCN.DLL, and it turns out it really wants to be located in the C:\Windows\SysWOW64 directory (aka the system path for libraries). Well that’s all great now, isn’t it?
The ODBC drivers in Windows 10 finally made a magical cut off point that they will not talk to any old and ‘vulnerable’ SQL Servers. This means that the oldest version you can connect to is SQL Server 2000. Even SQL 7 didn’t make the cut. Trying to connect to a SQL 7 server, you just get:
Attempting connection [Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context
And then I saw this post, about using FreeTDS to connect to MSSQL. So I followed their instructions, and got nowhere fast just lots of crashing. Turns out the bloodshed environment’s included G++ just fails 100% of the time for me, with a nice crash. So I pointed it to the TDM GCC install, and then had to link the DLL manually and… nothing. No configuration point. In a fit of rage, I took the exist msvc project, opened it in Visual Studio 2015, and built it, except for one issue…
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __vsnwprintf_s referenced in function _StringCchPrintfW
So I was thinking that SQL 4.21 & 6.5 are just too old to have this weird table, and as mentioned over here people would just create it, to get Access to shut up, and get on with their lives.
So, I put in some SQL
CREATE TABLE MSysConf(CREATE TABLE MSysConf(Config int NOT NULL,chValue char(255) NULL,nValue int NULL,Comments char(255) NULL) GO INSERT INTO MSysConf(Config,nValue,Comments)VALUES(101,1,’Prevent storage of the logon ID and password in linked tables.’) GO
And yes, it creates the table, Access get’s it’s result then obviously doesn’t like it and up and dies. Maybe I can burn more cycles on it later, or break down and ask.
Extract SP4 Copy ..SP4\x86\other\sqlredis.exe to ..\originalinstallpath\x86\other (this avoid mdac insall freezing) Create this folder structure (any place): Microsoft SQL Server\80\Tools\Binn Microsoft SQL Server\MSSQL\Binn Find out sqlunirl.dll on SP4 path and copy to Binn folder above Copy dll files on ..SP4\x86\setup to Microsoft SQL Server\MSSQL\Binn (folder above) Copy folder structure (created on step 3) to C:\Program Files (x86) Give full access to user logged to **Microsoft SQL Server** folder Change install compatiblity ..\originalinstallpath\x86\setup\setupsql.exe XP SP2 Run as administrator
Newer versions of Windows 10 don’t include the old Visual C++ runtime, and the install will fail. Just copy the DLL’s into the syswow64 directory.
copy SP4\x86\system\msvc?71.dll \Windows\SysWOW64
This is tested on 17134.112 Version 1803 of Windows 10.
Could that really be it? For some reason I had a file held in the Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\PendingFileRenameOperations registry key, preventing me from installing, but zapping the key & stub program, and I was able to follow the steps (I’m still not sure if you copy the dlls into the MSSQL\Binn or Tools\BInn directories, so I copied them to both!) and yes, it worked. I even could run the SP4 update.
And now I can use Access 2016 with this fine ancient database.
And here we are. As always there is no larger over reaching point to this. I did have to create a linked SQL login for myself to get ODBC to login properly but it’s somewhat simple, and honestly if that sounds bizarre to you, why are you even thinking about something like this?
For me, I’m interested in the DTS of all things. Sure the new ones are fancier, and all that jazz, but I paid good money back in the day for old MS dev tools, and being able to use them without any virtualization, aka running on bare iron is all the more appealing.
So it’s always a fun time for me to push my old project Ancient Linux on Windows. And what makes this so special? Well it’s a cross compiler for the ancient Linux kernels, along with source to the kernels so you can easily edit, compile and run early Linux from Windows!
As always the kernels I have built and done super basic testing on are:
All of these are a.out kernels, like things were back in the old days. You can edit stuff in notepad if you so wish, or any other editor. A MSYS environment is included, so you can just type in ‘make’ and a kernel can be built, and it also can be tested in the included Qemu. I’ve updated a few things, first with better environment variables, and only tested on Windows 10. Although building a standalone linux EXE still requires a bit of work, it isn’t my goal here as this whole thing is instead geared around building kernels from source. I included bison in this build, so more of GCC is generated on the host. Not that I think it matters too much, although it ended up being an issue doing DooM on GCC 1.39.
So for people who want to relive the good old bad days of Linux, and want to do so from the comfort of Windows, this is your chance!
DJGPP & other compilers, such as EMX require that you set needed variables with a UNIX style slash convention. Also it is a pain to hard code the entire path into a command shell. I know this works on Windows 10, although I’m not sure about earlier versions.
The %cd% variable contains the current directory, so it makes it easy to do something like this:
So in this example I set a temporary variable to the MS-DOS style path, and then using the pattern :(match)=(replace) it will then replace \ with /, giving me the UNIX style path. I then just set _tmpdir to nothing, unsetting the variable. So this way I don’t have to hard code any paths, and I can flip the slashes as needed.
Another fun thing is you can do logic blocks.. A simple one if a file doesn’t exist then compile it:
IF NOT EXIST dhyrst. (
echo Executable missing attempting to compile….
@make -f makefile
I’m sure most people knew about this, but for an old guy used to doing things the hard way, it was nice to see that there finally was some way to do this kind of thing.
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.
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!
As you can see it clearly can see the USB device, but when it opens the device it fails. And yes I’ve tried Administrator. And for the hell of it, I fire up Windows XP on VMWare, connect the USB dongal, and amazingly:
MIDI:win32 selected USB Audio Device
MIDI:win32 selected USB Audio Device 
MIDI:win32 selected Microsoft GS Wavetable SW Synth
Yes, I can open the out port just fine. So now I run a virtualizer to run my emulator to drive a physical peripheral… Ugh. Has MIDI been this messed up all along and I never noticed?
Oh yeah, the GS Wavetable Synth works fine, as did MUNT before I uninstalled it, thinking it was somehow interfering with anything.
I know I’m using this fine device, the QinHeng USB MIDI adapter, which apparently is notorious crap, but my recently acquired Yamaha MU 80, works fine with it on Windows XP.
Yes, I know about cygwin, but why run on top of Win32, when it can be a kernel subsystem? I don’t know why they scalled back, and killed SUA/SFU when it was viable, but I guess it being more Linux compatible makes it more friendly for users.
The big improvements is that you can compile Linux without the full MinGW/MSYS install by running the ‘blind’ script which will compile the kernel without make and friends.
The build process for the kernel works as well so now with the included Qemu 0.12.5, no need to link under Linux anymore. I fixed up some of the build processes as I thought I’d re-build and some stuff bombed so it’s all fixed up.
For those interested, I just updated the original download here: