35 Years Later, a Retro Computing Enthusiast Puts Windows 1 Back to Work – InApps 2022

What was programming on Windows like 35 years ago?

One man decided to find out.

New York-based developer Michael Casadevall ventured all the way back in time to when Microsoft released its very first version of its GUI-based operating system, Windows 1.0 — building a virtual system where he could install its original 1985 Software Development Kit, and then investigate the legendary sample code that came with it for a simple “Hello World” program.

Casadevall’s fascinating experiment offering glimpses of where we came from, showing not only how much things have changed, but also how much has been preserved.

And of course, getting there is half the fun…

Historical Recreations

Casadevall used Oracle’s x86 virtualization tool, Oracle VM VirtualBox, where he first loaded IBM’s PC DOS 3.3 — not Microsoft DOS 3.3, he pointed out in a recap on Soylent News. “The reason is that DOS didn’t exist as a standalone product at the time. Instead, system builders would license the DOS OEM Adaptation Kit and create their own DOS such as Compaq DOS 3.3.”

It’s obvious that Casadevall brings a lot of technical expertise to this experiment. He describes himself on his Twitter profile as a “Retro tech enthusiast” and “Dabbling InfoSec hacker.”

“It’s not exactly a secret that I have a personal interest in retro computing,” he posted to the site, “and documenting the history and evolution of the Personal Computer.” In a later video he calls himself “a child of the ’90s” who was surprised one Christmas with a Packard Bell computer running Windows 3.1.

But for this video, he went back in time even further…

The project came with some challenges.

“Windows 1.0 pre-dates the existence of a computer mouse as a standard piece of computer hardware,” he wrote. In fact, early on Casadevall discovered that he’s not able to emulate a serial or bus mouse. He came up with a fix that involved copying mouse drivers from the Windows 2.0 installation floppies onto the Windows 1.0 installation disks so they’d appear as a choice in the setup screen.

“The second option, which I was unaware of until after producing my video is to use the PS/2 release of Windows 1.0,” he wrote on Soylent News. “Like DOS of the era, Windows was licensed to OEMs who could adapt it to their individual hardware.” This was a forgotten time so primitive that Windows still had to be launched from the DOS command line by typing the command “win.” Casadevall wrote, “there was talk that Windows would be ported to run on top of XENIX, Microsoft’s UNIX-based operating system.”

Of course, there was an easier way to do at least some of this. You could use PCjs.org‘s browser-based emulator, which already has working mouse support.

He calls Windows 1 “essentially a graphical bolt-on to DOS although, through deep magic, it is capable of cooperative multitasking. This was done entirely with software trickery…”

See Disk 2

After partitioning the disk and installing DOS and Windows 1, it was time to set up the dev environment. “Unfortunately, there is virtually no online documentation on how to do this,” he wrote. Fortunately, the OS/2 museum had scanned some of the original reference binders, and “on closer examination of the disks, I found an installation batch file.” It’s appropriately named INSTALL.BAT, and warns users they must have at least 512K of memory. Also required is a floppy disk drive configured as drive A and a graphics monitor (either monochromatic or color).

“If you do not have the equipment or software above, abort this batch file,” the docs warned. “A mouse is recommended but not required.”

In his post on Soylent News, he notes the more-verbose interface. “This bit of polish was likely due to the fact that most users would be expected to install Windows themselves instead of having it pre-installed…”

But it’s a glimpse of a world where there were no web pages to share information. “For a complete listing of files in the Software Development Kit, see the file FILELIST.TXT on disk 2…” explained one screen.

“For reasons that probably only made sense in 1985, both the script and the README file were on Disk 2, and not Disk 1.”

In fact, the SDK was spread across seven disks — four of which were inserted during the installation process. This was all triggered, of course, by a file named INSTALL.BAT.

The fifth disk had debug builds of the Windows kernel, and the remaining two disks had sample programming code, including the infamous Hello World sample.

And users needed to perform even more installations. “Unlike later SDK versions, it was the responsibility of the programmer to provide a compiler…” his post noted. The installation screen warned that three options were supported:

• Microsoft C compiler, version 4.0
• Microsoft Pascal compiler, version 3.3 or later
• Microsoft Macro assembler, version 4.0

“Unofficially (and unconfirmed), there were versions of Borland C that could also be used,” Casadevall writes, “although this was untested, and appeared to not have been documented beyond some notes on USENET. More interestingly, all the above tools were compilers for DOS, and didn’t have any specific support for Windows.”

Finding Microsoft C 4.0 wasn’t hard, he noted in the video, though he needed to do another scan of manuals to figure out how to set it up properly.  Because hard drives were not common in 1985, Microsoft supported running the compiler from floppy disks. The hard disk installation required editing those crucial CONFIG.SYS and AUTOEXEC.BAT files, as well as manually copying over all the necessary libraries and executables.

Writing the code also involved dealing with near pointers (“functionally identical to normal C pointers within a given segment”) and far pointers (“the 8086 had special opcodes for using these.”)

“Callback functions always had to be declared FAR as Windows would need to load the correct segment when jumping into application code from the task manager.”

And there were also the oddities of how Windows 1 cleaned up the stack.

He noted that 16-bit Windows applications “existed in a general soup of shared address space.” At the time Windows didn’t immediately reclaim memory that was marked unused. Pieces of the application could remain in memory even after it was terminated.

Nonetheless, after much swapping floppy disks through the disk drive and some troubleshooting, Casadevall wrote a quick Hello World program (in C) using the text editor, and then compiling it with Microsoft’s C compiler. It apparently also created an .EXE version of the file which could be executed just by typing the file name without the suffix: “hello.” The program instantly printed out NCommander’s test message.

“Hello from DOS!”

Way Back Compatibility?

There was one more experiment Casadevall wanted to try: would a “Hello World” program written for Windows 1.0 still run on a modern system?

Some research revealed that compatibility for legacy DOS and 16-bit Windows programs could be achieved by running the NT virtual DOS mode (or NTVDM) combined with Windows on Windows (known as “Wow.”) Casadevall points out that even today, NTVDM is still a part of some versions of Windows 10, though noted the move to 64-bit dropped legacy 16-bit support entirely from Windows, and does not include NTVDM.

But Microsoft does still make available a 32-bit version of Windows 10 — which still includes NTVDM. Casadevall grabbed what is now version 1909 of Windows and installed it into a virtual machine, and then tried to install his Windows 1 Hello World application. He wrote: “Double-clicking Hello prompted Windows to download and install NTVDM, a promising first step. And on the second try, I can confirm: it’s possible!

“35 years of backward compatibility!”