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.