Hacker News Reader

Comment by JayGuerette | Hacker News Reader

"... a terminate-and-stay-resident program (or TSR) was a computer program running under DOS that uses a system call to return control to DOS as though it has finished, but remains in computer memory so it can be reactivated later. Needless to say, this was extremely unreliable."

There were very likely some hacky TSRs that caused problems, but in my experience most were extremely reliable. We used an off-the-shelf TSR to enhance a motion control system that laser scribed ceramic vacuum checks for silicon wafer fabrication. Those things cost $5k in 1990, and took ~20h of processing, increasing their value to $15k; we wouldn't screw around with something that was inherently "extremely unreliable".

View on HN

I loved TSRs - I wrote two of special note:

stop_clock: All it did was stop the real time clock of the system from counting up when you pressed the alt key and started it again on a 2nd press. However, this was enough to stop the timer of a typing speed program we used in high school. Magically, I was a VERY fast typist. :-)

stay_on: When you pressed a certain key sequence it would start the floppy drive motor and a 2nd press would turn it off. The goal was to speed up floppy accesses by not needing to spin up the motor all the time. Unfortunately, I got up one day to find my floppy drive motor dead. I suspect I forgot to turn off the motor (there was no idle timeout...I was a kid, never even crossed my mind!)

I had one TSR that let you allocate RAM and switch between up to 3 programs. Of course, they had to be small programs due to the 640KB limit. But it was still quite useful in the days before hard drives, to be able to have a couple of utilities (like a text editor) loaded without having to keep swapping floppy disks.

Also wrote a couple of TSRs of my own as a kid learning to program. Sure you could crash the system, as you could with any program, but they were as reliable as anything else.

The only thing special was that you generally didn't want to run two TSRs that naively hooked the same interrupt without chaining properly. But back then we didn't have thousands of mysterious background processes always running in the background. You knew what few programs you had run, so it wasn't really a problem.

Yes. DOS itself came with several TSRs, for example keyboard drivers. They were absolutelt commonplace and, if written properly, nowhere as unreliable as claimed.

Interestingly, the author updated the post, which now says "this was not 100% reliable".

There isn't anything inherently unreliable with TSRs; DOS even provided interrupts for this specific operation (although some malware would not use them).

I think (although not entirely sure) that some mouse drivers were, for example, TSRs.

The problem is that there was a wide range of purposes and implementations, including malware, so the argument is similar to "BTC is mostly used for dirty money, so BTC is inherently criminal".

All DOS mouse drivers were TSRs. The driver would hook INT 33h (which is the mouse driver "API" entrypoint) and whatever IRQ (ie. 4 or 12) that the actual hardware used. The IRQ handler would then update the driver's internal state according to data received from the mouse and if enabled draw the mouse cursor into frame buffer and/or call registered user event function (which runs in the interrupt context).

TSRs were unreliable when they interacted with games and other graphical applications.

Eg, things like a calendar tool trying to pop up a reminder mid-game would often not end well.

My 486 had boot sector protection in the BIOS. It would pop up a Y/N confirmation in text mode during boot sector overwrite.

This froze the windows 95 setup in graphical mode. Although the text prompt appeared for whatever reason the Y/N didn’t work and we could never continue.

So was never able to upgrade that machine.

Yes, I remember that! But at least on my board it could be disabled.

> There were very likely some hacky TSRs that caused problems, but in my experience most were extremely reliable.

Programming TSR's as a teen was where I learned to hit ctrl+s every line, at most!

Was kinda hard to debug given the "terminate" part and the tools at the time.

I used a TSR to run protected mode software under early Microsoft Windows back in the day. Effectively it was letting me have the big allocations I needed while using Windows as a portable display driver.

Just because the one you used worked doesn't mean the concept was safe. Viruses also loved the concept.

No more than third party drivers.

The concept was safe enough that DOS officially supported it, and development tools like Borland Pascal and C++ had special support to implement TSRs.

Reply on news.ycombinator.com