SQL Server 2000 on Windows 10

I have to admit it, that when I first heard about this I was HIGHLY skeptical, but sure enough it actually works.

Enterprise Manager looking at the infamous PUBS database

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 ‘’.
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 ‘’ to listen on ‘\\.\pipe\sql\query’.
17/09/21 19:40:24.83 ods Using ‘SSMSSOCN.DLL’ version ‘’ 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?

Not really.


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

Seriously, it turns out that 2015 can’t just link to ODBC, that the libc thing that gave me SDL grief is deeply entrenched all over the place.  So in this case you need to link against legacy_stdio_definitions.lib. Fantastic.

I get my DLL, and yes, it’s a Windows 32bit ODBC driver!

FreeTDS Access failure

And yeah, lots of failure.

A red-herring was seeing this in the trace:

net.c:741:Sending packet
0000 01 01 00 2b 00 00 00 00-53 45 4c 45 43 54 20 43 |…+…. SELECT C|
0010 6f 6e 66 69 67 2c 20 6e-56 61 6c 75 65 20 46 52 |onfig, n Value FR|
0020 4f 4d 20 4d 53 79 73 43-6f 6e 66 |OM MSysC onf|

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)
INSERT INTO MSysConf(Config,nValue,Comments)VALUES(101,1,’Prevent storage of the logon ID and password in linked tables.’)

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.

SQL Server 2000 (Dev) on Windows 10

And then I saw this epic thread, Windows 10 & My SQL Server 2000 Personal.

I managed to install following these steps:

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
Run as administrator

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.

Access 2016 with SQL 2000 via ODBC

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.

26th anniversary of Linux!

As the joke goes:

Happy 25th birthday, Linux! Here’s your f-ing cake, go ahead and compile it yourself.

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:

  • linux-0.10
  • linux-0.11
  • linux-0.12
  • linux-0.95c+
  • linux-0.96c
  • linux-0.97.6
  • linux-0.98.6

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!

Download Ancient Linux on Windows
Download Ancient Linux on Windows

MIDI Mayhem on Windows 10

So I know it’s ‘probably’ the super cheap generic USB to MIDI dongal I got on the cheap, but it just doesn’t work on Windows 10.

Using DOSBox, I get the following output when cycling between devices on the console:

MIDI:Opened device:win32
MIDI:win32 selected Microsoft GS Wavetable Synth
MIDI:Opened device:win32
MIDI:win32 selected USB2.0-MIDI
MIDI:Opened device:none
MIDI:win32 selected MIDIOUT2 (USB2.0-MIDI)
MIDI:Opened device:none

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:Opened device:win32
MIDI:win32 selected USB Audio Device
MIDI:Opened device:win32
MIDI:win32 selected USB Audio Device [2]
MIDI:Opened device:win32
MIDI:win32 selected Microsoft GS Wavetable SW Synth
MIDI:Opened device:win32

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.

QinHeng USB MIDI adapter

QinHeng USB MIDI adapter


Ported UAE 0.7.6 to MinGW!



I can’t find any source of the 0.5 versions, and I had issues with 0.6.x  but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?).  I suppose with this version working I can go back and take a stab at resurrecting 0.6.x

What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.

I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta.  So now you can actually use the CLI, and change disks.  Double clicking is an impossibility as it simply runs far too fast.  I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.

I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast.  UAE is from an era where a 100Mhz computer was a luxury item.  Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.

For the 2/3 people who care, I put the binary & source tree on sourceforge here. UAE 0.4 & UAE 0.1 are also available for download, plus all the source code I’ve been able to find.

GCC 1.40 on Windows

I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right!  I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!

Where can I turn away from all this so called progress!  I don’t like my C compilers to be C++ programs that require massive HOURS to compile.  Can’t we just go back to the good old days?

And the answer is YES, you can!

While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms!  Well isn’t that fantastic!

So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?

Well ancient versions of EMX are very difficult to track down.  Somehow I did mange to find this hybrid of 0.8B & 0.8C.  The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B.  And the best thing is that the 0.8B is based around GCC 1.40!  So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW!  Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows!  So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.

Compiling & Binding

Compiling & Binding

Now with my executable, I can run it on MS-DOS & OS/2!



and OS/2 2.0!

OS/2 (on Qemu)

OS/2 (on Qemu)

Well isn’t that fantastic!

However when running RSXNT’s bind, NTBIND I got this error:

D:\emx_w32\infocom>..\bin\ntbind info2
No relocations in file:
you have not linked the NT library

Great.  Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries.  So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:

io.o: Undefined symbol __streams referenced from text segment

And looking at the stdio.h there is this:

extern struct _stdio _streams[];

No doubt, the headers & libraries are tied together.  So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).

Running on Windows 10

Running on Windows 10

Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory.  I suppose it’s a fair trade off.  Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days.  GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!

For comparison, GCC 5.10 produces a 55,906 byte interpreter, while GCC 1.40 produces a 88,576 byte interpreter.

For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles.  It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!

Nethack 1.3d on Windows 10 x64

Nethack 1.3d on Windows 10 x64

I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.

How about some speed comparisons?  I dug out the ancient dhrystone.c, and gave it a shot.  I had to define 500,000,000 passes, as my computer is fast.  GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.

Dhrystone(1.1) time for 500000000 passes = 57
This machine benchmarks at 8771929 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 40
This machine benchmarks at 12500000 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 43
This machine benchmarks at 11627906 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 14
This machine benchmarks at 35714285 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 11
This machine benchmarks at 45454545 dhrystones/second

As you can see, GCC 1.40 produces the slowest code.  While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away.  And again GCC 5.1 beat out the older 1.40 for executable sizes.

29,960 gcc510_O.exe
29,996 gcc510_O2.exe
30,472 gcc510.exe
70,656 gcc140_O.exe
74,752 gcc140.exe

And this time by over a 2x lead!  It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.

For anyone who’s read this far, I guess you want to take it out for a test drive?  Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk.  I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.

You can download the exe’s and combined source here: gcc-1.40_EMX-OS2_RSXNT.7z

Stack corruption in MSYS with Windows 10

I’m sure it’s happened in other versions of Windows too.  Everything will be fine, then out of the blue you start getting errors like this:

0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x3B0000, State 0x10000
d:\mingw\bin\sh.exe: *** Couldn’t reserve space for cygwin’s heap, Win32 error 0
make: *** [all] Error 1

Well MSYS like Cygwin uses persistent shared memory locations, and if they become corrupt, it’s game over.

So yeah, reboot.

DR-DOS 5.0 and Windows 3.0

So I’ve always heard about the incompatibility, and I thought I’d give it a try in PCem.  I know I used to run DR-DOS 5.00 and Windows 3.0 (because of the CGA driver) and it worked fine.

So just to prove it works, here I am installing Windows 3.0 on DR-DOS 5

Installing Windows 3.0

Installing Windows 3.0

And even better, running Word 2.0! Although I did install a whopping 4MB of ram on this virtual 286.

MS Word 2.0

MS Word 2.0

And to make it all the better, I changed to a 386, and re-installed Windows 3.0 and yes it runs in enhanced mode.  And I can run DR-DOS in a windows.

386 enhanced mode

386 enhanced mode

Of course there was the AARD code, in the Windows 3.1 betas, but as far as I know that didn’t make it to release.  I was able to upgrade to a virtual VGA adapter, and update to Windows 3.1 in standard mode on a 286, just fine

Windows 3.1 standard mode on a 286

Windows 3.1 standard mode on a 286

And DR-DOS worked through the standard mode task swapper

DR-DOS in standard mode

DR-DOS in standard mode

But Windows 3.1 in enhanced mode always locked up during setup.  Maybe a PCem bug?  I’m not sure.  But Windows 3.0 works great.

Snoopy – a basic packet sniffer for Windows

(this is a guest post by Tenox)

A few days ago I wrote a basic packet sniffer / analyzer for Windows for fun. I was working with raw sockets for another application and out of curiosity winged a small packet sniffer in just 200 lines of code. I actually used it already several times to resolve some firewall port blocking issues, instead of spinning up Wireshark, so I decided to release it to public.

The good:

  • Portable, a single, tiny exe
  • Easy to use
  • Doesn’t install any driver like libpcap
  • Extensible, just 200 lines of simple code

The bad:

  • It’s very basic and doesn’t allow anything outside of simple unicast TCP, UDP and ICMP, most importantly layer 2, broadcasts, multicasts, etc are out of question
  • Currently it doesn’t directly support filtering, however you can just pipe it to findstr to filter for anything you want

Raw socket limitations are possibly the biggest issue, but if you just want to find out simple stuff like traffic going to a given port or ip address it’s a perfect little handy dandy tool to carry around.

To use snoopy you specific IP address of the interface on which you want to listen:

snoopy1There also is a verbose mode which shows some more detailed protocol information:

snoopy2Today I decode ICMP message types, TCP flags, sequence, ack and window numbers and DSCP, ECN, TTL and Dont Fragment flags for IP. I’m thinking of embedding /etc/protocols and /etc/services in a .h file to resolve them on the fly.

Bug reports and suggestions most welcome!

Available here: http://www.tenox.net/out#snoopy


OpenNT – Windows NT 4.5

(This is a guest post from Tenox)

Just stumbled across this: someone has forked Windows NT 4.0 and created an open source version of it. But wait, forked what? Windows source code doesn’t live on Github. Is it ReactOS? No! Upon some digging, it was apparently born from the leaked source code of NT4.0, some W2K bits and 2003 WRK.

Enter NT version 4.5:

NT45Test-2015-04-27-18-20-37More screenshots here: http://www.opennt.net/projects/opennt/wiki/Screenshots

The main project site: http://www.opennt.net/

Looking at activity the project seems to be alive and well. There is some background information and discussion going on BetaArchive for those interested.

I wonder what Microsoft has to say about this 🙂

“warning: Invalid parameter passed to C runtime function.”

So while debugging Dynamips I got this fun message under GDB.  Of course it doesn’t tell you WHAT function did it, or HOW it was trying to do it.  Fantastic.

Thankfully Dennis Yurichev’s blog gave me the hint to put a breakpoint on ‘OutputDebugStringA’ and sure enough I could see Dynamips trying to treat a socket like a stdio file handle.  Something you can’t do in Win32 world.

On the plus side, I just had to do a small re-write of some functions and I can talk to the Dynamips hypervisor!  Idle and JIT are working too!  Along with WinPcap and UDP transports.