• Please review our updated Terms and Rules here

DOS TSRs

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,428
Has anybody out there written a DOS TSR? I'm looking for a tutorial or a good book to reference before I dig in. (I have a few that cover it, but only as a tangent.)


Thanks,
Mike
 
I wrote one in the early nineties. I used the book:

Memory Resident Programming on the IBM PC
Thomas A. Wadlow
1987
413 pages with about half of those pages containing appendices of the BIOS and DOS interrupt services
ISBN 0-201-18595-2
 
i wish i could help. i was wondering, might this be for turning your mTCP stack into a TSR?
 
I believe that the Al Williams "DOS 5: A developer's Guide" and "DOS 6: A developer's Guide" both have a TSR chapter. Herb Schildt's "Born to Code in C" has a TSR chapter as well (in addition to chapters on a multi-tasking DOS kernel and an icon-based "GUI").

I'm sure there are other sources as well but these are the books I have at hand.
 
IIRC, It seems that after Borland came out with SideKick, pretty much everyone jumped on the TSR bandwagon.

I'm pretty sure just about every book on 8088/6 Assembly language produced in the early to mid-80's had a chapter or two on TSR's. I'll check after breakfast and see which of my books have TSR coverage.

As an aside, I picked up some vintage software a month or two ago, and one of the packages included (with floppy disks and manual!) was a library called "resident C", which allows you to more easily create MS-DOS TSR's from C. It works with both Microsoft C and Borland Turbo C (not sure about MS Quick-C, it doesn't specifically mention it). I haven't given this library a test yet, but may in the near future.

Update:
Well heck! I checked all of the 8088/6 Assembly language book I own, and none of them do more than just mention TSR's! One of them did have a page on INT 27, and also mentioned the preferred method of calling INT 21 with AH=31h. I could have sworn I read some books on this, with at least one or two chapters on TSR creation. Must be age creeping up on me ;-)
 
Last edited:
I ordered "Memory Resident Programming on the IBM PC", the two "Developer's Guide" books (overkill, I know), and a parallel port interfacing book. I love Amazon ...

Thanks for the recommendations!


Mike
 
Resident C sounds interesting .. you should try it out for me. :)

I coded my TCP/IP in Borland Turbo C++ 3.0 which is a great little compiler but it also requires anybody who wants to use the code to be able to accept one of my libraries. So that eliminates other variants of C, Pascal, BASIC, etc. as possible users of the code.

I understand the concept of 'terminate and stay resident' and I also understand how to 'take over' a software interrupt to provide services like the packet drivers do. I need to learn some details specific to my code. For example, I'm sure it's not safe to use the DOS heap from a TSR so I'll have to have the client code allocate buffers instead. And my tracing functions and error messages go to a file or stderr so those have to be eliminated. After I do some more reading I'll know if this is worth it or not.
 
Ahh, I'll be watching this thread closely. Years ago I wrote a 'screen saver' for DOS in Turbo Pascal 5 (I think it was 5, it was a long time ago now), but it wasn't much of a screen saver, because the .exe had to be run from the DOS prompt to get it to activate. I had a hard enough time getting it to detect mouse activity (that version of TP didn't support the mouse at all from memory), and couldn't find any info on TSRs and how to make them, or else I would have made it into a TSR (and probably switched from TP to asm code).

Having just recently got back into programming when I've got some spare time (right now tinkering with Atari BASIC on the 8-bit 400/800/etc., I'm amazed how rusty my skills are!), I'd love to tinker with TSRs on a DOS machine!
 
mbbrutman said:
Resident C sounds interesting .. you should try it out for me. :)

I coded my TCP/IP in Borland Turbo C++ 3.0 which is a great little compiler but it also requires anybody who wants to use the code to be able to accept one of my libraries. So that eliminates other variants of C, Pascal, BASIC, etc. as possible users of the code.

I understand the concept of 'terminate and stay resident' and I also understand how to 'take over' a software interrupt to provide services like the packet drivers do. I need to learn some details specific to my code. For example, I'm sure it's not safe to use the DOS heap from a TSR so I'll have to have the client code allocate buffers instead. And my tracing functions and error messages go to a file or stderr so those have to be eliminated. After I do some more reading I'll know if this is worth it or not.
Click to expand...

excellent! you've got a beta tester for sure right here. :)

NTCPDRV is really starting to @#$@#$ #$@#$ ME OFF! so unstable when used as a server interface. and it's not me or my code, it's like this with every trumpet-based DOS server app i've ever found online.
 
Mike Chambers said:
excellent! you've got a beta tester for sure right here. :)

NTCPDRV is really starting to @#$@#$ #$@#$ ME OFF! so unstable when used as a server interface. and it's not me or my code, it's like this with every trumpet-based DOS server app i've ever found online.
Click to expand...

...which is exactly why I want to write a TCP/IP implementation of my own in QB, although if Mike Brutman can get his EXCELLENT TCP/IP implementation into a decent TSR, I might not have to...

I'm just as pissed off at NTCPDRV as you are. I hate it when I have to reboot my IRC server several times a day because NTCPDRV bombed out. I thought it wouldn't be so annoying at first, but now it's really getting on my nerves.
icon8.gif


The fact that Peter Tattam is not likely to do anything about it is almost as infuriating, but I understand that he has a really busy life, so he can't really be bothered to try and fix it when he has so many bigger fish to fry.
 
I'm looking into it. But a lot of the reasons that I went with my current approach (a statically linked library) still stand:

  • Ability to use DOS heap. If it is a TSR I have to rely on the user to allocate/manage buffers correctly.
  • Performance: Call overhead with a software interrupt mechanism is high. It will hurt code like mine that requires polling to move the packets.
  • Limited function: I don't think I'll be able to do things like the log file for debugging tracing. That makes debug much more difficult. Even things like 'time of day' might be restricted.

You guy's problem with TCPDRV might be related to your usage of QB or a programming error on your part. It is not really fair to throw rocks at the author for something that might be your doing. It is also not terribly fair to throw rocks at code 10 years past it's prime .. if Peter is done with the code and doesn't want to support it, I wouldn't second guess his reasons.

Matt - try a simple UDP implementation in QB. UDP should be well within reach.


Mike
 
mbbrutman said:
I coded my TCP/IP in Borland Turbo C++ 3.0 which is a great little compiler but it also requires anybody who wants to use the code to be able to accept one of my libraries. So that eliminates other variants of C, Pascal, BASIC, etc. as possible users of the code.
Click to expand...

If you turn your stack into a .COM file that accepts a custom interrupt for getting and sending data, I swear to you I will write a program that supports it (like a CGA and/or PCjr VNC client).

You will have to compile using the small model of course, to get a .com file.

I'm sure it's not safe to use the DOS heap from a TSR so I'll have to have the client code allocate buffers instead.
Click to expand...

You can use DOS to allocate some memory for you, because you'll then issue the terminate-and-stay-resident interrupt and DOS will not take back the memory.

While you're programming your utility, inevitably you will need to UNload it to try again. Grab a copy of RESPRO to help manage TSRs (if you need a copy, email me).
 
That's what I'm looking into. Something like TCPDRV's interface that any programming lanugage can use seems to be the best way to share the code.

The code itself is small enough to fit in 64K - that is no problem at all. Especially after the tracing is compiled out - I don't think I can include the tracing function in a TSR. And if I make my end user allocate the memory for me then I don't have to worry about the heap problem.

I'd love to see a VNC client out of you .. based on prior exchanges we've had, I can guarantee everybody that it would be fast enough to be useful. Maybe not on a PCjr though - 16 colors in 320x200 is kind of limiting. This might require an XT with VGA.

(Do X servers even support 1 bit color anymore? That's an option ...)
 
mbbrutman said:
That's what I'm looking into. Something like TCPDRV's interface that any programming lanugage can use seems to be the best way to share the code.

The code itself is small enough to fit in 64K - that is no problem at all. Especially after the tracing is compiled out - I don't think I can include the tracing function in a TSR. And if I make my end user allocate the memory for me then I don't have to worry about the heap problem.

I'd love to see a VNC client out of you .. based on prior exchanges we've had, I can guarantee everybody that it would be fast enough to be useful. Maybe not on a PCjr though - 16 colors in 320x200 is kind of limiting. This might require an XT with VGA.

(Do X servers even support 1 bit color anymore? That's an option ...)
Click to expand...

Awesome! Finally, there will be an alternative to the two other free implementations (the WATTCP TSR that only handles up to 6 simultaneous open connections OR NTCPDRV, which bombs out after 12-24 hours :p)

Though not essential, I'd actually like it even more if you could adhere to the TCPDRV specifications with your TSR (http://www.pld.ttu.ee/~priidu/library/net/tcp201.spe.html) so that it can essentially be a more reliable and superior drop-in replacement for NTCPDRV. This would eliminate the need to redo the TCPDRV access routines in programs that use it, or at least make it easier to modify them. It would also eliminate the need to come up with your own specification. If you don't want to do that, though, I understand. The way TCPDRV is accessed might not be the ideal way to do it, and your TCP/IP implementation probably works in a way that would make it extremely difficult.

(going slightly off-topic...)
I'd love to play with your TCP/IP implementation in Borland Turbo C++ 3.0 (and possibly Microsoft QuickC with modifications?), but I can't find any source code on your site... did you forget it? am I not looking hard enough? ...or is it not out yet?

BTW do you think would it be at all possible to compile it into a Quick Library with Microsoft QuickC and use it in QuickBASIC? In my situation, it would reduce the interrupt calls by about half (and in theory, make it a little faster) because I wouldn't have to make interrupt calls to a TCP/IP driver. How extensive would the modifications be just to get it to compile in QuickC as opposed to Borland Turbo C++? I'd test it out myself, but there's no source code on your web site (and if there is, it's buried so far that I can't find it)
 
I would take a closer look at the WATTCP TSR. I haven't dived deep into it, but I had a nice long conversation about implementing TCP on a PC with Eric last year. (His original site for it disappeared while it was being relocated and I panicked slightly .. he contacted me with the new location, and then we traded notes.) My approach to the library is very similar to what WATTCP did years ago.

If I do this I'm not even going to look at the TCPDRV spec. Different designs, different goals, and I don't want my hands tied by something else.

Source code: None is posted. This is a work in progress and it's not extensively tested and definitely not documented yet. That's why I keep doing new apps with it - to test it better and to gain experience 'eat my own dog food'.

I don't have QuickC. It would be a porting job.
 
So doing some late night googling and ran across this thread from a decade ago. Did anything ever come of this? Mike did you implement the TSR and did Trixter deliver VNC for DOS?
 
(Almost 15 years later ...)

I decided not to go down the TSR path for mTCP; it would have imposed a lot of constraints and it would have been more difficult to make it reliable.
 
You must log in or register to reply here.
Back
Top