Fog Creek Software
Discussion Board




Obscure DOS question

I have an article from 1989 that discusses a DOS utility.  It's a word processing utility, something like a grammar checker. 

The article mentions that the utility can either be started in normal mode or in "memory resident mode."  I'm strictly a Windows 95-and-later guy, so I'm not familiar with this term.

From what I've found online, memory resident mode seems to be an early form of multitasking -- you can load two or more programs in memory (RAM permitting), and task switch between them.  Is this more or less accurate?

Also, would there have been any ability for the utility while in memory resident mode to communicate with the word processor, such as through some early form of DDE or COM?  Or would it have been more equivalent to having two separate virtual machines running on one CPU, with no ability for interop?

Thanks for the pointers!

Robert Jacobson
Tuesday, July 13, 2004

Yeah - that was the beginning of multi-tasking

http://en.wikipedia.org/wiki/Terminate_and_Stay_Resident

DJ
Tuesday, July 13, 2004

It's been a long time, but I think you're referring to what used to be called TSR (terminate and stay resident) programs, of which one of the most well-known was Sidekick. IIRC, these used to leave themselves lying around somewhere above 640k, and were activated by various keystrokes (Ctrl Alt for Sidekick I think). Typically they would pop up some utility such as a calculator, calendar, etc. The process involved playing unspeakable tricks with the keyboard buffer, and if you had more than one of the things involved was a great way to crash your machine. I don't recall any way of communicating between a TSR and other program, but if there was it would probably involve various ad hoc mechanisms, and make your machine even more likely to crash.

Why do you ask?

as
Tuesday, July 13, 2004

You're talking about a "TSR" (terminate and stay resident" program).

This is a program that you run (from the DOS prompt): when it runs it installs itself (in RAM) and terminates (without freeing the RAM). You now see the DOS prompt again, and can launch another application. When it ran, the TSR will incidentally have installed hooks into the DOS and/or BIOS interrupt handlers.

You can invoke it to make it do something (e.g., pop a window on your screen) while it is resident, for example by hitting some application-specific hot key combination (like <Ctrl-D> or something) if it has hooked the keybaord interrupt and is watching for that hotkey combination.

> Also, would there have been any ability for the utility while in memory resident mode to communicate with the word processor, such as through some early form of DDE or COM?

Yes, for example a TSR can hook itself into the multiplex interrupt. The foreground application can then write specific values into the CPU registers and invoke the multiplex interrupt using a signature (specific register values) that indicate that it wants the TSR to do something (e.g. read and process some block of memory that one of the registers is pointing to).

> Or would it have been more equivalent to having two separate virtual machines running on one CPU, with no ability for interop?

No, the TSR is more like a DLL or a device driver. It runs in the same (real-mode) address space as the foreground application (and the same video buffer if the TSR ever writes to the screen). Also the TSR doesn't get any forground CPU time: it only runs when the foreground application calls it as if it were a subroutine ... and/or it may run at interrupt level, e.g. if it has hooked the keyboard or timer tick interrupt.

Christopher Wells
Tuesday, July 13, 2004

Some examples:

TSR terminal emulators toggled by an odd key combination such as <SHIFT/SHIFT> sharing a box with WP or Visicalc with block cut/paste between the two. These were very popular.

TSR to watch the video buffer and keyboard to catch words on input, spell-check, and popup suggestions or ring a bell (maybe not so popular).

TSRs that prestuffed the keyboard buffer with keystrokes allowing apps to be run "unattended" - KEYFAKE was a good one (from a big field).

Tiny miracles of ingenuity, most of them.

Biggest of the lot was called MSDOS though that was more of an SRT (Stay Resident and Terminate).

hugh
Tuesday, July 13, 2004

... and I learnt all that in the past... It really seems useless by now.

Me
Tuesday, July 13, 2004

TSR, now that's a TLA I haven't heard in a while....

Steve Jones (UK)
Tuesday, July 13, 2004

But you've gotta love the fact that the old DOS legacy lives on... I swear that when I boot my machine it still says something like "640K base memory, 1047936K extended memory".

John C.
Tuesday, July 13, 2004

The old DOS legacy? What do you mean, old?? If your machine talks about "extended" rather than "expanded" memory, it's clearly some new-fangled nancyboy device that real men wouldn't have a bar of.

And does anyone out there remember the days of Windows version 2, when the difference between the 64k and 256k expanded memory buffers determined whether you could "multitask" between one application or just the none?

as
Tuesday, July 13, 2004

There's still active DOS development on embedded & control computers (like 486's with ethernet, LCD/VGA ports and 1GB flash-disks on a palm-sized board). DOS keeps everything simple.

Bob
Tuesday, July 13, 2004

Ahh, TSRs. That was just the tip of the iceberg.

DOS development became absurdly frustrating, gnarly and irritating when Windows 3.0's introduction whetted the public's appetite for GUIs, client/server computing, and multitasking. After Windows became a mainstreamish platform, anyone doing DOS development had their back pushed against the wall to equal Windows within DOS's constraints. 

DOS development in the early 90s (up til Windows 95's introduction) quickly became a frustrating mess of dealing with time slicers and real mode multitaskers, DOS extenders, and various GUI/windowing managers for DOS. It became the case that you absolutely needed an ICE, Soft-ICE, or at least a hardware level debugger like Periscope to debug ordinary applications.

The imperative at most SW product companies was to look like Windows without "making" your customers buy and install Windows. I am *not* proud of the stuff I had to develop in that time frame just to stay employable... :-(

Bored Bystander
Tuesday, July 13, 2004

TSRs usually intercepted (and therefore changed) some interrupts, usually the keyboard and the timer -- that would be the only way for them to get the control flow.

When a DOS program runs and exits leaving some interrupt vectors changed, Windows detects that and shows a message to the effect "your TSR is now loaded, use the appropriate keys to use it", and then effectively halts (doesn't return to the command prompt.

Native DOS programs created without awareness of Windows can't use the Windows clipboard or any mechanisms such as DDE. Though I recall the later versions of DOS Navigator were Windows-aware and could share the clipboard with Windows.

Alex
Tuesday, July 13, 2004

Anybody else feel old reading this? lol...

Joe
Tuesday, July 13, 2004

Thanks for all of the info, guys.  Makes me glad I had a Mac back then... ;-)

Robert Jacobson
Wednesday, July 14, 2004

*  Recent Topics

*  Fog Creek Home