This is super cool, building on Takeda Toshiya’s excellent MS-DOS Player, is a fusion of the MS-DOS emulation with portions of Wine to run Win16 applications on Win32 capable OS’s.
Yes, it really can run Excel 3.0a. I don’t know how much people will want a 27 year old spreadsheet, but here we go! It’s incredibly buggy, and many Microsoft programs don’t like their accelerators, or menus, more things don’t run than do, but when they do it’s great.
The releases on the github page are quite old, and you’ll really want to bulid this from source. You will need Visual Studio 2017 to build this, and I used the Community Edition. While trying to compiling I got this error:
Performing Custom Build Tools
The system cannot find the path specified.
Well that doesn’t help us at all!
Setting the Tools -> Options -> Build and Run, MSBuild sections to both detailed verbosity revealed:
“C:\Users\neozeed\source\repos\winevdm-master\Release\convspec” “krnl386.exe16.spec” KERNEL > “krnl386.exe16.asm” && “C:\msys32\mingw64\bin\as” –32 -o “krnl386.exe16.obj” “krnl386.exe16.asm”
Performing Custom Build Tools
The system cannot find the path specified.
So it turns out it is using GNU GAS to assemble itself. So I just copied in an ‘as.exe’ from another MinGW install I have lying around.
GNU assembler 2.17.50 20060824
So it doesn’t even have to be a hyper modern version, as you can see with the –32 we are building 32bit based stuff anyways.
And with that all done we have a release build.
I had no luck with Sim City, but Sim Life & Sim Earth load at least, but not being able to use the menus means you can’t really use them. Microsoft Word 1.1 won’t load at all, while Word 2.0 will load but again no menus, and it’s unable to register enough OLE to open documents so it’s not very useful again. Although my ancient QuickC for Windows F2c port of Dungeon, works okay, although QuickC for Windows itself does not currently run.
Another great thing is that you can run WinHelp for all your ancient documenation fixes! Also MS Write from the ancient days of Windows 3.0/3.1 works as well
So while cruising the junk market in Hong Kong I found this little ‘roomba’ looking machine. Looks pretty neat, and because it has video & crashing issues I was able to get this thing for $500 HKD or about $75. I mostly felt bad for the guy as the disk had died in the thing, and he had spent the money to get a SSD into this thing, and had been nice enough to upgrade the Windows 7 to Windows 8, and onward to Windows 10 for me, all legit.
But to start the adventure what the heck is this thing? Naturally SONY has several things that look like model numbers. Normally I’d just flip it on it’s back and reveal..
A model of PCG-2G2P. However looking at it’s side I find…
That this thing is also a VGX-TP3G. Way to complicate things SONY!
So searching SONY seems kind of funny as it bounces me to America first for some reason, then tells me to go to the APAC site.
I don’t know why these kinds of ‘main corp, but not really main corp’ companies drive me crazy. And wouldn’t you know it, no manuals, and the downloads are only for the SONY applications built in for BlueRay playback that aren’t on the SD.
And then I find this fun support article, 00188888.
Dear Valued Customers,
Please be informed that Sony’s support has ended for VAIO computers which were shipped with the following Microsoft Windows operating systems preinstalled:
• Windows 95
• Windows 98
• Windows 98 SE
• Windows ME
• Windows 2000
• Windows XP
• Windows Vista
As of March 1, 2018, we will no longer provide drivers and software for download for these computers.
That’s right! Even though they already offer no drivers, BIOS updates or anything they will kill all downloads for all the older machines in less than 2 weeks. Great. So avoid any old SONY salvage guys.
So I decide I’m going to wipe the machine, and re-install Windows with the x64 variant, and I also wanted it in English. The OS installs just fine, and everything looks good. Even though this is a 10 year old machine, I thought I’d try something simple, like compiling a Linux kernel, and that is when I saw the weirdest thing. While unzipping the archive, the disk usage hit 100%, but there was no blinking on the disk LED (this machine is so old, it has one of those things!), and in the task manager, no program was using the disk at all.
So a quick search led me to this article, 3083595.
Task Manager might show 100% disk utilization on Windows 10 devices with Message Signaled Interrupt (MSI) mode enabled
Task Manager shows the disk to be at 100% utilization despite a light or no workload, and the system may experience lag or become unresponsive. In addition, the system event log contains numerous events with Event ID 129, which represent resets of the disk controller.
While device resets can be caused by a varying number of factors, we are aware of issues with some Advanced Host Controller Interface PCI-Express(AHCI PCIe) models that causes these symptoms in Windows 10 when running with the inbox StorAHCI.sys driver. Due to a firmware bug, the Solid-state drive (SSD) does not properly complete input/output when Message Signaled Interrupt (MSI) mode is enabled. As a result, the Windows storage stack attempts to reset the device after waiting on unresponsive reads or writes for a period of time.
Well isn’t that interesting! So it turns out that a firmware update could solve this, but I’ll be damned if I can find one. So the solution was to turn off MSI, and it works. Although the disk is certainly slower, but I guess not softlocking from disk errors is a good thing though.
I loaded up Kerbal Space Program, but it’s ancient Intel® Core™2 Duo Processor T8300 & NVIDIA® GeForce® 8400M GT GPU really show their age. But it does run, so that is nice. It runs Edge & YouTube just fine, and handles all the general media stuff I wanted so that’s a win for me.
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 ‘18.104.22.168’ to listen on ‘\\.\pipe\sql\query’.
17/09/21 19:40:24.83 ods Using ‘SSMSSOCN.DLL’ version ‘22.214.171.124’ 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:
[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)
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.
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.
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.
However it’s not terribly useful 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.
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)
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’
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.