mbbrutman

I got lucky here with the compiler detecting the problem given that it wasn't just limited to using a null pointer. Depending on the buffer offset being handed back, it could have hit anywhere in the data segment.

Where is that published? I was using Github for references on DOS 4 as 3.3 isn't there yet.

(Thanks in advance!)

I looked at the call before and after to see what they had set the buffer to, and they clearly set the buffer to point into what is code. The executable is only 5KB and it's tiny; they had plenty of space in the segment to use a different part of the segment without purposefully blasting their own code.

While it's common, it was still a terrible practice. If whatever was filling in that buffer changed, they could be blasting more code than they intended. (As indicated in what I wrote, I know it was common if they wanted to reuse the space. Device drivers do something similar when they are done with their init code.)

Some day ... It took me months even just to get around writing up what I found ...

I'm still puzzled by the jump on the segment register values. I need to trace through the entire path.

Cute article, but I'm not quite sure how you missed the mTCP HTTPServ program ...

I took 30 seconds of video with the beeping and the screen scrolling for posterity. I'll get it posted somewhere.

I'm sure I can go for a few more years until the next patch ...

On a more serious note, the web server is the problem here. I've tried to run long periods of time before but eventually it would crash. I finally found a 10+ year old parsing bug that wasn't handling quoting correctly, and it was some sort of crypto coin mining JSON request that tripped the bug. So even what I thought was bullet proof years ago turned out to be broken by changes in the user traffic.

Sadly the project is mostly unrelated to my day job. I started mTCP at least 6 years before joining Google and at most of my time at Google is spent on much less fun things.

On the plus side, when I finally do get around to building a cluster of these and a load balancer I'll know what to do. ;)

Maybe, with some qualifications. A machine that is powered on but serves almost no traffic would also qualify but not be terribly interesting.

I'm just happy it's been surviving the hug of death for 12+ hours now. Given the age and software that might be the true accomplishment.

Thanks ... I think people are having time-outs so it's not anywhere near close to perfect, but the machine has been running at 100% for five hours or so now and it is not crashing, so I'm happy.

There were several speeds of the V20, including the base version at 5Mhz. Using it as a drop-in replacement and keeping the system clock speed the same the NEC V20 would still give you a 15 to 20% performance bump because it used less clock cycles when executing many insgtructions.

(This machine has not been altered to speed the clock.)

There is a fan internally in the machine, but it was placed to cool the 5.25" floppy drive when it was in use.

I have more open space in this machine because I am using a 3.5" drive instead. I also replaced the original fan with a quieter Noctua. The jrIDE is running naked on the side of the machine because I think it was having heat issues.

In a later iteration of this machine it will get more direct cooling; the slots in the case are kind of restrictive.

The machine continues to receive the hug of death .. especially with our friendly Europeans waking up. Have faith, it's still running. (And it's been surviving like this for four hours now.)

I've turned down the logging level a little bit and turned off the beeper. On this machine, a 50ms beep on the motherboard buzzer is 50ms of delay. :)

I bought my first NEC V20 in 1986 or 1987. It was my first time touching the motherboard of a computer which made it nerve wracking, but they were very popular at the time. I bought mine mail order through the Exec PC BBS, which I think was in Chicago.

http://floppy.museum also running mTCP HTTPServ, but on 80286 class hardware.

(That was featured earlier this year on HN.)

Yeah, far too much for a little CPU like this. Never mind the horror of trying to port all of the libraries and keep them up to date.

Although there are people are using Apache in front of their vintage computers to terminate SSL for them while still having the vintage computer handle the request.

486? Nah. 4.77Mhz NEC V20, which is just slightly faster than an 8088.

This should tide you over: http://www.brutman.com/PCjr/pcjr_web_server.html

The main page is the best link. You might want to try back later after the initial rush; the machine is getting pounded.

The Xircom is pretty bad, as it costs a lot to do the I/O through the parallel port. Just using TCP/IP sockets (no disk access or processing) the machine can send and received about 42KB/sec. A better adapter can do nearly 3x that on the same machine.

Performance measurements here: https://www.brutman.com/mTCP/mTCP_Performance.html

A few things to consider here:

  * It's getting hammered.  I didn't expect it to be this bad.
  * If it can't process things fast enough packets might be dropped.  So the TCP/IP error rates are probably pretty high right now.
  * It's logging all of this crap too ...

Normally it can do the handshake in tens of milliseconds. Right now the load on it is basically "crush." But it's queuing and answering as best as it can.

No, it's a 2009 creation. When I started mTCP I did netcat first because it was simple. My first iteration of an IRC client wasn't much better than netcat. It has improved since then though.

Yep, a PCjr. No parity bit on the memory even.

I have a love/hate relationship with the Xircom adapter. It's portable and great for machines without ISA slots, but the max throughput is about 40KB/sec. A nice, real ISA card like a WD8003 can do over 100KB/sec on the same machine.

FreeBSD is crusty, but is it really bad enough to compare to DOS 5.02?

Besides, who needs 32 bits when 16 will do ...

(Not serious.)

100+ days of runtime on nearly 40 year old hardware not designed as a server exposed to all of the garbage coming in on port 80.

Remember, this is a home computer from the mid 1980s. This thing is way outside of it's duty cycle. And the software is holding up pretty well too, even during what is effectively a DoS attack on a DOS machine.

Yep, at this point it's just continually busy.

For the next iteration I've got to put a better Ethernet card on it. The Xircom PE3-10BT device is nice because it's convenient, but the bandwidth would be 2x higher with a real Ethernet card on the bus.

And normally this machine is idle so the speed and bandwidth are not a problem. Right now it's very popular. :)

I have a small IRC client for that 286 if you still have it. Even has some Unicode support, but being limited to CP437 kind of limits it. ;-0

It's still beeping ... busy != dead. Right now it's getting hammered pretty hard. I haven't implemented the clustering and load balancing yet.

It can serve 8 concurrent connections but that slows it down. It will queue a few more too; be patient and you will be rewarded.

(Sorry, I forgot to preface this with Show HN)

  ** 2023-07-14 18:38 PDT The DOS machine is getting DoSed.  It's still beeping and happy but it's busy. **

This website is hosted on a 39 year old PCjr running at 4.77Mhz and it has been running over 2,500 hours continuously now. No reboots or program restarts ... you can see the current runtime stats by visiting http://brutmanlabs.org/status .

The machine specs are:

  - IBM PCjr w/ NEC V20 CPU (the V20 gives a small speed bump compared to the original 8088)
  - jrIDE sidecar providing expansion RAM to bring the system up to 736KB and an IDE port
  - Kingston SSD w/ a Startech SATA-IDE bridge
  - Parallel printer sidecar, modified to be bi-directional
  - Xircom PE3-10BT Ethernet adapter hanging off of the parallel port
  - IBM PC DOS 5.02 and mTCP HTTPServ
  - APC UPS (45 watt power draw with networking equipment)
  - Dynamic DNS is being handled by my home router, which forwards port 80 to the machine.

All of the upgrade parts are there for performance or convenience; you could use period correct parts and everything would work the same. (The IDE adapter would be a homebrew MFM adapter and you'd have to use something like a 3Com 3C503 on a bus adapter, but all of that existed in the mid 1980s when the machine was new.)

The web server is my own work, part of the mTCP project. Here are some of the features:

  - serves HTTP 0.9, 1.0 and 1.1 requests to be friendly to vintage browsers
  - Maps "normal" looking paths and resources to DOS 8.3 file format
  - HTTP 1.1 requests can be pipelined.
  - can serve up to 8 concurrent connections
  - logging to local disk and over UDP
  - can serve pre-compressed content
  - basic auth
  - runs on DOS 2.1 and up
  - built in SNTP client for time syncing

Besides the UPS it needs the SNTP client to achieve long run times, otherwise dropped interrupts cause the machine to lose time. Without the SNTP client it was losing up to a few minutes per day depending on the system load. The SNTP client also helped it transition through the daylight savings time change in March.

The limiting factor is going to be disk space for logging; it is generating logs and eventually that disk partition will fill up. (I need to add log rotating and compression.) This machine was running when the ChatGPT client for DOS was announced, and it was hosting the mTCP networking pages at the time, so it got quite a bit of traffic. I learned after that to leave a lot of space for logs.

It beeps when somebody visits - enjoy!

The machine has been featured here before but it has achieved a fun milestone: more than 1,000 hours of continuous runtime without restarting the software, rebooting, etc. See the stats at http://brutmanlabs.org/status .

The machine is a 4.77Mhz IBM PCjr probably made in 1984 running IBM PC DOS 5.02. A Xircom PE3-10BT Ethernet adapter (originally designed for laptops) on the parallel port allows it to connect to network. It has a modern-ish IDE controller and an SSD but those are only needed because of the amount of content; the machine could happily serve pages from RAM indefinitely. (Serving from the floppy disk would be painful, and probably short lived for the floppy disk.) I am cheating slightly and sending large, multi-megabyte requests for PDFs to another machine because I don't want those to tie up the machine for so long.

The software is my the mTCP HTTPServ web server. It runs on everything from DOS 2.1 up, supports up to 8 concurrent users at a time, supports filename and path mapping so you don't have to look at horrible DOS 8.3 paths and files, supports BASIC auth, logging, and a few other fun features. I've been working on it for nine years now. (mTCP is even older at 14 or 15 year now.)

The tricks to keep it running this long are a small UPS system and an SNTP client so that it can keep the clock synced with the rest of the world. The UPS protects the machine, router, and fiber ONT for a total load of 45 watts. The machine loses a few seconds here and there due to lost interrupts for the SNTP client is a necessity for longer runs. The SNTP client also helped it transition through the daylight savings time change in March.

The limiting factor is going to be disk space for logging; it is generating logs and eventually that disk partition will fill up. (I need to add log rotating and compression.) This machine was running when the ChatGPT client for DOS was announced, and it was hosting the mTCP networking pages at the time, so it got quite a bit of traffic. I learned after that to leave a lot of space for logs.

It beeps when somebody visits - enjoy!

It runs on anything from an 8088 to an emulated virtual machine.

Read the manual ... It's all explained.

Oh, I understood - I've been a professional programmer for close to 30 years, and I've done a lot of operating systems work.

On this platform you have the burden of ensuring that the C runtime is thread safe, or putting locks around it. The same with BIOS calls. And DOS function calls too; you can't have those other CPU cores just blundering in on something that is not reentrant.

And besides, I target this at 16 bit DOS on vintage machines. I've never seen a PCjr or an AT class machine with multiple cores. There were some super expensive 386s at the time that were multi-processors, but those are a fairly rare item.