The world once ran on hardcopy, and when the digital age started to bring new tools and ways of doing things, documents were ripe for change. Today, word processors and digital documents are so ubiquitous that they are hardly worth a thought, but that didn’t happen all at once. [Cathode Ray Dude] has a soft spot for old word processors and the journey they took over decades, and he walks through the Olivetti ETV 2700.
The ETV 2700 is a monstrous machine; a fusion of old-school word processor, x86-based hardware, and electric 17 inch-wide typewriter.
With it one could boot up a word processor that is nothing like the WYSIWYG of today, write and edit a document, and upon command, the typewriter portion could electronically type out a page. A bit like a printer, but it really is an electric typewriter with a computer interface. Characters were hammered out one at a time with daisy wheel and ink ribbon on a manually-loaded page using all the usual typewriter controls.
While internally the machine has an x86 processor, expects a monitor and even boots MS-DOS, the keyboard had its own layout (and even proprietary keys and functions), did not support graphical output, and in other ways was unusual even by the standards of the oddball decades during which designers and products experimented with figuring out what worked best in terms of functionality and usability.
It’s a piece of common knowledge, that MS-DOS wasn’t capable of multitasking. For that, the Microsoft-based PC user would have to wait for the 80386, and usable versions of Windows. But like so many such pieces of received Opinion, this one is full of holes. As [Lunduke] investigates, there were several ways to multitask DOS, and they didn’t all depend on third-party software.
A quick look at DESQview and Concurrent DOS was expected from this article, but of more surprise is that IBM had a multitasking DOS called TopView, or even that Microsoft themselves released the fully multitasking MS-DOS 4.0. We remember DOS 4 as being less than sparkling, but reading the article it’s obvious that we’re thinking of the single-tasking version 4.01.
From 2023 it seems obvious that multitasking is a fundamental requirement of PC use, but surprisingly back in the 1980s a PC was much more a single-application device. On one hand it’s surprising given the number of multitasking DOS products on the market that none of them became mainstream, but perhaps the best evidence of the PC market simply not being ready for it comes in the fact that they didn’t.
AI-powered chatbots are clearly the future of computing, and it’s only a matter of time before you’ll see them appear on every internet-connected gadget. If you thought you were safe from this by sticking to an ancient MS-DOS PC though, think again: [Yeo Kheng Meng] has recently written a ChatGPT client that runs on DOS.
[Yeo Kheng Meng] didn’t cheat by simply running MS-DOS on a modern PC, either: he tested the client on a real 1984 vintage IBM 5155 Portable PC. This semi-portable PC/XT model sports a 4.77 MHz 8088 CPU, 640 kB of RAM and a CGA video card with a built-in monochrome monitor. An NE2000 ISA network card, running in 8-bit mode, enables the Portable to connect to the internet.
Running the client couldn’t be simpler: just run doschgpt.exe and type in your question. [Yeo Kheng Meng] developed this program using the Open Watcom C/C++ compiler, which was the compiler of choice for most DOS game developers back in the day. Networking support was provided by an era-appropriate packet driver together with MTCP, a TCP/IP stack developed by [Michael Brutman] for DOS-based internet applications.
Connecting to the ChatGPT API and parsing the results was pretty straightforward, but implementing the required TLS encryption was not. Even if there was a library available for MS-DOS, the 5155 wouldn’t have enough CPU power to run it in real time, so [Yeo Kheng Meng] decided to run that bit of the networking stack on a modern PC and send an unencrypted HTTP stream to the DOS client.
Building a complete operating system by compiling its source code is not something for the faint-hearted; a modern Linux or BSD distribution contains thousands of packages with millions of lines of code, all of which need to be processed in the right order and the result stored in the proper place. For all but the most hardcore Gentoo devotees, it’s way easier to get pre-compiled binaries, but obviously someone must have run the entire compilation process at some point.
What’s true for modern OSes also holds for ancient software such as MS-DOS. When Microsoft released the source code for several DOS versions a couple of years ago, many people pored over the code to look for weird comments and undocumented features, but few actually tried to compile the whole package. But [Michal Necasek] over at the OS/2 Museum didn’t shy away from that challenge, and documented the entirely-not-straightforward process of compiling DOS 2.11 from source.
The first problem was figuring out which version had been made available: although the Computer History Museum labelled the package simply as “MS-DOS 2.0”, it actually contained a mix of OEM binaries from version 2.0, source code from version 2.11 and some other stuff left from the development process. The OEM binaries are mostly finished executables, but also contain basic source code for some system components, allowing computer manufacturers to tailor those components to their specific hardware platform.
Compiling the source code was not trivial either. [Michal] was determined to use period-correct tools and examined the behaviour of about a dozen versions of MASM, the assembler likely to have been used by Microsoft in the early 1980s. As it turned out, version 1.25 from 1983 produced code that most closely matched the object code found in existing binaries, and even then some pieces of source code required slight modifications to build correctly. [Michal]’s blog post also goes into extensive detail on the subtle differences between Microsoft-style and IBM-style DOS, which go deeper than just the names of system files (MSDOS.SYS versus IBMDOS.COM).
The end result of this exercise is a modified DOS 2.11 source package that actually compiles to a working set of binaries, unlike the original. And although this does not generate any new code, since binaries of DOS 2.11 have long been available, it does provide a fascinating look into software development practices in an age when even the basic components of the PC platform were not fully standardized. And don’t forget that even today some people still like to develop new DOS software.
The recent flurry of projects based around Internet Relay Chat (IRC) should be a fair indication that the beloved protocol is not going anywhere. Now, thanks to [Mike Chambers], you can add to the IRC ecosystem by hosting your very own MS-DOS based IRC server.
This port of ngIRCd (Next Generation IRC Daemon) has already been spun up on 8088-based PCs running at just 4.77MHz, but you’ll still need at least 640KB of RAM. If your vintage IRC server takes off, you might want to think about dropping in an 10MHz V20 for a bit of a performance boost. Even so, it’s impressive that this server can get up on the 40-year-old IBM 5150, and should absolutely scream on an AT-class system.
The limitations of the 16-bit platform means that SSL and ZLIB are unsupported, and Mike has capped total connections at 50 in his port (however, this limitation can be adjusted by rebuilding from source, should you want to find out how far 640KB of RAM can take you). You’ll also need a few other things to get your server up and running, such as a packet driver for your network card and an mTCP configuration file.
Setting up your own IRC server is arguably a right rite of passage for most hackers and tinkerers, but getting this up and running on a decades-old beige box would make for a fun weekend project. [Mike] has all the juicy details on GitHub, and you can check out a test server running the latest build over at irc.xtulator.com.
Also, don’t forget to visit the #hackaday IRC channel over on irc.libera.chat.
“Bring our home computing out of the 1970s and into the 1980s and beyond” is the irresistible promise made by the creator of 8088ify, a piece of software which translates CP/M executables from their 8080-based originals to assembler code that should run on an 8088 under MS/DOS. How can we resist such a futuristic promise here in 2021, even though the code wasn’t written to the sound of Donna Summer or the Village People back in the day but here in 2021 for PCjam, a celebration of the original IBM PC’s 40th anniversary.
As the writer of this code [ibara] points out that Intel intended the 8088 to be a ready upgrade path for the 8080, and designed its instruction set while not directly compatible, to make translation between the two a straightforward process. There was commercial software for the task at the time, but to this day there remained nothing with an open-source licence. It’s written in ANSI C for portability across platforms and compilers, and can even be compiled under CP/M itself.
Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.
So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.
We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.