News 39-Year-Old 4.77 MHz DOS Web Server Hits 2,500 Hours of Uptime

[Admin]

A 39-year-old IBM PCjr with a 4.77 MHz CPU has been serving web pages for the last 2,500 hours with no reboots.

39-Year-Old 4.77 MHz DOS Web Server Hits 2,500 Hours of Uptime : Read more

 

[Sceptical87]

Michael Brutman's mTCP suite makes it really easy to use Internet technologies on DOS. With mTCP I can easily connect my 3/486 PCs to my home network and use FTP to pull across games and programs without needing to burn them to CD or copy to floppy disk. Makes retro computing that little bit easier.

I note mTCP had a recent update too, which is great to see.

Not to mention the wealth of information he's compiled on his website.

Thanks Michael for your efforts - keep up the great work.

 

[bit_user]

I feel like it's a little bit cheating that it's running off a SATA SSD.

Somehow, it just doesn't feel that impressive to hit 100ish days of uptime. I know DOS had no memory protection, but still...

 

[InvalidError]

My PCs routinely routinely hit 2-3 months of uptime between OS and driver updates when I'm not screwing around with hardware changes or install games that install outdated stuff Windows Updates overwrites and requires a restart right after.

Running a mostly static web server on an old XT-like PC doesn't sound quite that impressive when you consider that many IP-connected micro-controllers and DSPs with somewhat comparable specs packed into a single chip are doing something similar for their configuration UI.

 

[Gavin Greenwalt]

Running a mostly static web server on an old XT-like PC doesn't sound quite that impressive when you consider that many IP-connected micro-controllers and DSPs with somewhat comparable specs packed into a single chip are doing something similar for their configuration UI.

Yeah I ran a very similar PC for my router in Highschool on my 10Base-T home network when I finally got "broadband" aka a 600kbps wireless uplink to a rural WISP.

I think I was running Coyote Linux off of a floppy

 

[mbbrutman]

Keep in mind that this just isn't about being running for 100 days; I also wrote the TCP/IP library and web server. It's also entirely exposed on port 80 to the entire world. And it has also survived the Hacker News "hug of death."

All of the upgrades could be removed and replaced with period correct hardware. The SSD is there because I don't want to burn up an old MFM hard drive.

Remember this is an 16-bit machine from the 1980s. It is way out of its duty cycle.

 

[InvalidError]

Remember this is an 16-bit machine from the 1980s. It is way out of its duty cycle.

Being "16bits" doesn't mean much when even 8bits micro-controllers can run IP stacks. The killer blow for any sensible application isn't so much the hardware being old as it is that modern chips eliminate the hardware, software and power overheads of adapter-on-adapter(-on-adapter) kludges. You can get the same job done in 1/50th the footprint and 1/100th the power with modern stuff.

10Base-T(X) ISA cards were a thing in the late 80s, that would streamline things quite a bit.

 

[Vanderlindemedia]

In most old computers, the spindle based HDD is usually the first one to go.

 

[mbbrutman]

Being "16bits" doesn't mean much when even 8bits micro-controllers can run IP stacks. The killer blow for any sensible application isn't so much the hardware being old as it is that modern chips eliminate the hardware, software and power overheads of adapter-on-adapter(-on-adapter) kludges. You can get the same job done in 1/50th the footprint and 1/100th the power with modern stuff.

10Base-T(X) ISA cards were a thing in the late 80s, that would streamline things quite a bit.

Which is why it's "Retrocomputing Performance Art" and kind of fun to build and watch. If it were a commercially available micro controller running modern software nobody would care and it wouldn't be showing up in a news feed.

(And yes, ISA cards are available, but not on this machine which has no ISA slots. I haven't finished replicating a bus adapter that I have so it has to use the Xircom adapter for now.)

 

[InvalidError]

In most old computers, the spindle based HDD is usually the first one to go.

SSDs are easily replaceable consumable wear items too and they fail almost as often as HDDs do albeit for different reasons so you still need to have a regular backup strategy for any important files.

 

[mbbrutman]

I feel like it's a little bit cheating that it's running off a SATA SSD.

Somehow, it just doesn't feel that impressive to hit 100ish days of uptime. I know DOS had no memory protection, but still...

It would run fine on period correct hardware. I'm just not really interested in sacrificing an MFM hard drive for a silly project. The memory, floppy drive, IDE controller, SATA device, etc. are there for convenience. The SSD is not needed for performance; the machine can only read at about 300KB/sec at best. It's there for the log file, which is optional.

DOS has no memory protection. No threads. No networking support. No virtual memory. I could keep going ... Basically, except for the code that I wrote and the lower level packet driver to send and receive raw bytes on the Ethernet device, there is not much else running. DOS here is basically the program loader and the library that lets me write to the filesystem.

 

[InvalidError]

DOS has no memory protection.

Kludgy as the 286's protected mode was, x86 didn't really have properly working memory protection until the 386 anyway.

 

[Alvar "Miles" Udell]

To be fair while it may have been prohibitively expensive until more recent times, in the later 90s it was possible to upgrade IDE HDDs to CompactFlash cards via adapter, and was and is a great way to upgrade IDE only computers and handhelds, so the fact it has an SSD isn't really something that should be held against it.

But there is something to be said about old style web pages. No fancy scripts or anything, just blue hyperlinks and black text.

 

[mitch074]

Having actually owned and used a similar machine (Commodore PC-1, 4.77 MHz 8088, 640K of 150ns RAM), the performance of that website is impressive.
We're talking about a machine that was slow enough that typing fast on the keyboard could overflow the input buffer. You could actually follow the cursor drawing the screen in text mode (80x25), Xenon 2 ran on it at 2 fps. As for keeping it stable...
To be fair, if you ran only one thing at once on the machine, it could stay up for a long time - provided the drivers didn't cause an overflow, or a program didn't overwrite another's memory.

 

[InvalidError]

To be fair, if you ran only one thing at once on the machine, it could stay up for a long time - provided the drivers didn't cause an overflow, or a program didn't overwrite another's memory.

Drivers? Back then, most software was practically bare metal besides disk IO.

 

[bit_user]

Drivers? Back then, most software was practically bare metal besides disk IO.

I don't know a lot about the subject of DOS-era drivers, but you did have things like printer drivers.

Perhaps they hooked into the interrupt vector table at a well-known interrupt, or registered some callbacks with DOS.

 

[bit_user]

We're talking about a machine that was slow enough that typing fast on the keyboard could overflow the input buffer.

Depends on what the software was doing. Because it wasn't multithreaded, if the software would go away and do something for a while, you could easily get ahead of it.

To be fair, if you ran only one thing at once on the machine, it could stay up for a long time - provided the drivers didn't cause an overflow, or a program didn't overwrite another's memory.

DOS had TSR's (Terminate and Stay Resident programs - sort of like a UNIX process running in the background), but those tended to be extremely simple so you basically had just 1 program running at a time.

It's hard to believe the 386 launched in 1985 and it took another 10 years for Windows 95 to come along and finally put the first nail in DOS' coffin.

 

[InvalidError]

I don't know a lot about the subject of DOS-era drivers, but you did have things like printer drivers.

Perhaps they hooked into the interrupt vector table at a well-known interrupt, or registered some callbacks with DOS.

You didn't need printer drivers: if all you wanted was to print plain text, all you had to do was pump the characters straight out the printer port, then poll the status port to know when the printer is ready to accept the next character. Fancier dot-matrix printers had buttons on them to select font type and size and their manual may have included the special character sequences to change options from the computer.

Interrupt-driven programming usually involved writing your own interrupt service subroutine and setting the interrupt vector to your own code, usually in ASM if you were worried about register thrashing by higher-level languages, no OS involved unless you were hijacking something else's interrupt vector and meant to pass along everything you aren't messing with. I've written that sort of bare-metal code a number of times as a kid, must have crashed my computer hundreds of times along the way.

 

[bit_user]

You didn't need printer drivers: if all you wanted was to print plain text, all you had to do was pump the characters straight out the printer port, then poll the status port to know when the printer is ready to accept the next character. Fancier dot-matrix printers had buttons on them to select font type and size and their manual may have included the special character sequences to change options from the computer.

We could print graphics on dot-matrix printers from DOS programs. MS Works could print documents with multiple fonts and styles. They certainly weren't limited to unformatted ASCII text.

There were definitely printer drivers. The only thing I don't know is whether there was any standard for them, or whether they were program-specific.

Interrupt-driven programming usually involved writing your own interrupt service subroutine and setting the interrupt vector to your own code, usually in ASM if you were worried about register thrashing by higher-level languages, no OS involved unless you were hijacking something else's interrupt vector

BIOS and DOS established the convention of which interrupts were used for what. So, I was suggesting either they reserved an entire interrupt for talking to a printer driver, or perhaps they might've just given you a way to register a callback.

The whole point of a driver is to provide an abstraction layer over some piece of hardware. So, you would've needed some sort of API or convention for where/how to hook in. According to this, DOS int 21h, ah=05h indeed provided an API for printing:

DOS API - Wikipedia

en.wikipedia.org

Just because you could touch the raw hardware didn't mean DOS & BIOS served no purpose.

 

[HideOut]

So less than a year...

 

[InvalidError]

We could print graphics on dot-matrix printers from DOS programs. MS Works could print documents with multiple fonts and styles. They certainly weren't limited to unformatted ASCII text.

There were definitely printer drivers. The only thing I don't know is whether there was any standard for them, or whether they were program-specific.

What I wrote is that if all you want is plain text, you can just pump the ASCII straight out to the printer port (literally out to 378h on ISA bus), no drivers whatsoever required. In the days of DOS-based WordPerfect, AutoCAD, etc., printer "drivers" for dot-matrix printers in graphics mode were application/suite-specific libraries and each software developer had to write their own printer libraries. If your graphical software didn't have drivers for your specific printer or a similar enough printer family, you were boned.

According to this, DOS int 21h, ah=05h indeed provided an API for printing:

​

DOS API - Wikipedia

en.wikipedia.org

Service 05h isn't much of a print API. All it does is spare you the minimal work of writing your own LPT port byte-banger. It is only useful if you write command-line tools and batch files that need to play nice with other command-line tools and batch files that may pipe things out to LPTx or out through service 05h.

 

[mitch074]

What InvalidError said about printers : exactly true (the PC's character table contained invisible characters dedicated to basic printer control). About drivers : there were few, but still - mouse driver, CGA emulation on Hercules graphics, but also some sound cards (if you had one) or ATAPI drives needed a DOS driver. Stuff like modems or network cards, too. They were usually quite small and you may even have differing boot disks to load only a few of them so as to save RAM for running actual software (multi boot config only appeared with DOS 6.0), but on a 8088 those 640K were all you had - and loading any software in RAM usually meant it stayed there until reboot.

 

[mbbrutman]

Michael Brutman's mTCP suite makes it really easy to use Internet technologies on DOS. With mTCP I can easily connect my 3/486 PCs to my home network and use FTP to pull across games and programs without needing to burn them to CD or copy to floppy disk. Makes retro computing that little bit easier.

I note mTCP had a recent update too, which is great to see.

Not to mention the wealth of information he's compiled on his website.

Thanks Michael for your efforts - keep up the great work.

Thank you, and you are welcome!

 

[mbbrutman]

Drivers? Back then, most software was practically bare metal besides disk IO.

PCjrs *always* have a device driver if you are doing anything besides booting DOS 2.1 on a 128K machine. It's basically required by the architecture; putting a video memory window in the middle of your main memory was a bad design decision.

Then you have the standard device drivers like ANSI.SYS. If you are using a parallel port storage device like a Zip drive you have a driver there. (SCSI adapters on the parallel port were another reasonably popular device.) If your system had any sort of non-standard mass storage device, you had a device driver for it ...

Need a RAM disk? That's a drive. Need a RAM cache to speed up the hard drive? Or perhaps you were foolish enough to use a compression program to extend your hard drive? Or maybe your hard drive was bigger than your BIOS would handle so you needed a BIOS overlay for it? That's a driver too ...

And then there were the extended memory drivers.

Life if simpler if you can stay on bare metal. But most DOS systems had some fun config.sys files.

 

[bit_user]

perhaps you were foolish enough to use a compression program to extend your hard drive?

We used DBLSPACE (Double Space). Don't know if we just got lucky, but had no issues with it. There was a competing program called Stacker that, based on the wikipedia page, it seems won a patent lawsuit against Microsoft's DBLSPACE.