SQL Server 6.5 running on Windows 10
In the same effort as getting SQL Server 4.21a running on Windows 10, I found that SQL Server 6.5 will run as well. For what it’s worth, SQL Server 6.0 runs, but the enterprise manger will not run, giving this fun error:
And SQL 7.0 just bombs out with this:
Which clearly means I’m missing something in trying to transplant settings. However for some reason SQL 6.5 I can register the SQLOLE type, and boom!
SQL 6.5 in action
On Win64 vs Win32 and COM objects
I should mention that when registering a COM object you typically run something like this:
Which picks up the one in the default path. What about system32?
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:
And you should get:
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.