I picked this 20 disc set recently and ugh the cringe is just… insane. And yes, that is Bill Nye…
STUDS from Microsoft . (Video in MPEG-1/Audio MPEG-2 care of JSMpeg).
I had this ages ago, although I couldn't remember if the NT 3.5 SDK/DDK had shown up at this point, but it's only the Japanese version in this set. Since I'm having such a PITA in tracking down a 3.5 set, and I'm not sitting on this, I may as well archive it.
So you too can find the early Video for Windows, and all kinds of other things from the mid '90's on archive.org.
Or Wallpapers like this 'puppy' from the Japanese version of Windows 3.1
I stumbled onto these three disks, seemingly out of place in history. Windows/386 version 2.0 is a strange one in that it shipped to OEM’s in late 1987, making it & Xenix part of the initial 386 wave of Operating Systems/Environments and beating out not only the OS/2 launch in 1988, but taking advantage of the 80386’s v86 mode, something that OS/2 wouldn’t be able to do in a shipping product until 1992.
This version itself appears to be a retail version of Windows/386 lacking any clear OEM identification that was so prevalent for the era. Indeed setting it up it offers a few interesting platforms:
Getting this to run was a little bit of a challenge as much as I prefer Qemu, these older 2.0x versions of Windows/386 have a BIOS/disk incompatibility with the hypervisor resulting in errors reading the hard disk. Although PCem/86Box have no such issues. I think it’ll run off floppy/CD-ROM/Network without any issue though.
The PCjs version of 2.03 has 138 setup files (not counting the PIFs), compared to the eBay’s 141, while the PCjs 2.01 has 59 files.
That said, well it’s Windows/386 mostly from 1987 with slightly updated EGA/CGA VMM drivers from early 1988 that just didn’t quite make the cut. To me what is confusing, is that it identifies as 2.03 while it’s closer to 2.01 in file count and functionality, unlike 2.03 it really ought to have been a 2.02, if there even was such a thing.
Otherwise it’s really not all that interesting short of the timestamp. It’ll run on CGA/EGA *IF* you have the proper adapter in place, although VGA is compatible, the environment will detect that it’s not actually the proper card and refuse to run. I tried to put in the 2.01 CGA/EGA drivers, but that resulted in an OS version mismatch (I didn’t check if 2.01 was locked to the Compaq OEM of MS-DOS)
I installed the infamous pair Word & Excel. Despite Word 1.1a demanding at least Windows 2.11, it appears to run okay. Excel 2.1d loaded without complaining. There isn’t very much convential memory for either, but they both can use expanded memory, which the hypervisor can create and share out without any emm386 or any equivalent driver. I can only imagine the incompatibles of trying to balance these drivers at the time, and how much the coming DPMI specification was needed.
And as the old saying goes the three top problems in Windows version 2 is memory, memory and memory. Trying to run anything graphical will exhaust convential ram, forcing you to single task anything graphical which kind of defeats the whole point of Windows. You go from this:
Oh well it’s 1987, and users were kind of used to being disappointed as such. It’s really no wonder why Windows 3.0 became the smash it it was.
And of course you can't talk about Windows/386 without this gem. (Video in MPEG-1/Audio MPEG-2 care of JSMpeg).
I had a single issue with the code, d_copy.s the following line was giving me trouble:
changing it to the following however, let my version of GAS happily assemble it.
After a while of messing with the Makefile, and adding in the DOS components, it was easy enough to get an executable. And even better it’ll run with the data/music from the demo disc!
I used Daemon tools to mount the MDS/MDF image, and just pointed DOSBox to the CD drive letter with a simple:
mount d: f:\ -t cdrom
And now when I fired up Quake, it’ll play the music tracks from the CD.
One thing that caught my interest was that when you exit the game, I get the “couldn’t load endscreen.” message.
Well it turns out that someone was naughty and had modified common.c on January 20th 1997, and made the following addition:
if (h == -1)
Con_Printf ("Playing shareware version.\n");
// if (com_modified)
// Sys_Error ("You must have the registered version to use modified games");
So yeah, since they had double commented out that return statement, it’ll fall out the logic, and set the game to registered, which is why the endscreen message is missing. Uncommenting them all will restore the default execution behavior. Speaking of registered, on the CD there is a file QUAKE.MJ3, which is 25MB, which looks like an encrypted version of the registered game. I guess it’d be ‘neat’ to have version 1.01, although the Steam version I have is 1.06 and I don’t know how much difference it’d really make. Although I guess 22 years later it doesn’t matter much.
On the one hand I’m really impressed that it works. For anyone who is slightly interested I guess, you can find my re-build of the source here:
So as promised, a while back I had built a GCC 22.214.171.124 / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME. Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.
Why not use a more up to date version of both GCC/Binutils? Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too. And it was easier to just get the older tool chain working.
It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.
Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.
Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable. And the best part is checking via DOSBox, it runs, with sound!
Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.
So I quickly built it with my MinGW32-DJGPP using GCC 3.4.5. And this version needs the Allegro library as it has sound effects audio! Although building Allegro needed GCC 126.96.36.199 and Binutils 2.8.1. Using other versions just led to nothing but trouble. I ended up just installing DJGPP on DOSBox to build Allegro which took … a whlie to build. Although being able to cross compile dosdoom from Windows was far far far quicker.
So yeah, it runs. With sound. It’s great. Allegro integration isn’t anywhere as near complete at this point it’s just the sound files. I took a much later version of dosdoom’s MIDI code, which required the Allegro timer, which interfered with my older timer IRQ hook. Converting the whole thing to use the Allegro timer, and keyboard wasn’t too difficult, and that gives my DooM source fork a really full feeling when using DJGPP v2.
Although I’m having issues uploading from China at the moment.
Links 386 is one of those programs that is very easy to love to hate. It was 1992, and PC’s were mostly being used for business, and high powered 32-bit machines were still insanely expensive. And then Links 386 happened. Before there was DooM, Links 386 was the ‘must have’ executive ball clacking device. And the specs that you needed to run this game were really over the top. At it’s heart was the Phar Lap 386 Dos extender, along with the virtual memory module.. Which most people would have to rely on. Links 386 really needs over 8MB of RAM to run. Yes, that is correct, in 1992 you were recommended to get 8MB (which should have been about $400-800 USD) So you can golf at your desk. But as the name implies you also needed a 386 classed computer, although ideally you would have one of those new 486’s! Links 386 also pushed the edge by wanting a VESA capable SVGA card that could use mode 101, 103, or 105. Although the higher resolutions modes just ended up with logos everywhere, it really didn’t take enough advantage of the higher resolution modes.
Another interesting thing is not only does Links 386 have sound drivers (which means you need a sound card!) but it’ll do voice through the AdLib card. Also it has a driver model, the WLZ, which I don’t know if they ever published or if people wrote additional sound drivers.
The installer is kind of cute, in that it’s flat shading is so old it’s now modern. How’s that for crazy?
Installation is a snap, at only four diskettes. They sold additional courses, and I only have one additional course, although oddly enough finding others online is pretty trivial. However I had far less luck finding the program. One nice tip to Infocom is that the courses include a score card, like the ones you would get on actual courses. It really tied the package together.
Although for me, I really bought it for the manual.
And I have to admit it, Access Software did a great job. Even all these years later, it looks great. But no doubt scaling and placing all the textures is SLOW. Incredibly slow.
Back in the 90’s I had a lowly support job, and I’d get flown all over the country to help out with issues, and it’d never fail that the regional director would have ‘issues at home’ and amazingly they’d always ask about running Links 386 Pro. No doubt a lot of people upgraded machines, and got to brag to their buddies on how fast Links would now load. Running at actual 386 speeds will take nearly a minute to render the screen between shots.
The DOS Extender was forever very touchy. It took a bit of work to get around it’s issues, with the continuous conflicts with TSR’s, drivers, sound cards, video cards.. It was a nightmare of compatibility issues. Not to mention that although Phar Lap 4.1 was DPMI compatible, it really didn’t play that nice with OS/2 or Windows. Microsoft would later come to the rescue for this costed gamer market in the form of buying Links away from Access software, and putting out Microsoft Golf. And much like SimCity, being able to run this under Windows make it immensely popular in the workplace, as all you needed to find were Windows drivers for your hardware, which vendors did actually support, unlike games.
It’s amazing how companies like Phar Lap, or Rational never did try to make an actual gaming platform for their extenders, leaving it all up to individuals. My older self says that Microsoft’s rise to prominence in the 90’s was mostly due to their competitors incompetence, rather than their brilliance.
Although DOS Extenders like Phar Lap have been around since the introduction of the 80386, Links 386 Pro is the oldest one I know of. If you like programs that try their best to bend the limits of what you can or should do, certainly check out Links 386 Pro!
I saw this the other day, although haven’t had a chance to write about it.
EtherDFS just needs a packet driver on MS-DOS, and it implements it’s own re-director to communicate with a Linux file-server, using it’s own raw protocol.
It certainly looks cool, and looking at how it works, it should be possible to write other drivers to read/write other filesystems for MS-DOS. It’d be more interesting (to me anyways) if you can write an INT 14 re-director using a 32bit DOS extender to make things easier regarding filesystem ports.
When I get back home, I’ll have to test this on my retro machine, as the idea of just needing a packet driver + TSR sure sounds like a LOT less memory than the Microsoft re-director.
No really, it’s Catacomb 3-D: The Descent. First ported to 32-bit SDL by NotStiller. Me being the person I am, I fixed a slight bug regarding binary files on Windows, and MS-DOS, then cleaned up some of the C++ syntax (yuck!) making it far more C89 friendly. And of course, hot off the heels of DooM for GO32 DPMI, I was able to get it to build and run using GCC 1.39 and GO32.
I know most people really won’t care, but I found it kind of interesting. I should try to see if it’ll run on actual hardware, just as a comparison of tightly optimized Borland C++ / Assembly vs 100% pure C on DJGPP. The best tech of 1991 for sure!
I also put up the source for my ‘null doom‘, for anyone who ever needs some massaged source to DooM that will compile with a C compiler, instead of needing something that can understand C++ style comments, although I know in cccp.c there is the ability to turn on cplusplus style processing. However since I did want something that would compile without altering the compiler (too much) I thought it was best to just change all the comments.
And a quick download link to the zip file with the source & binaries.