Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!usenet.ins.cwru.edu!cwlim!trier From: trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) Newsgroups: comp.os.msdos.programmer Subject: Re: TSR PROGRAMMING PROBLEM Message-ID: <1991Feb12.064710.25412@usenet.ins.cwru.edu> Date: 12 Feb 91 06:47:10 GMT References: <1991Jan31.185355.10599@everexn.com> <1570@pdxgate.UUCP> Sender: news@usenet.ins.cwru.edu Reply-To: trier@po.CWRU.Edu Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA) Lines: 31 Nntp-Posting-Host: cwlim.ins.cwru.edu In article <1570@pdxgate.UUCP> mwizard@eecs.cs.pdx.edu (Craig Nelson) writes: > Anyone telling you DOS is not reentrant is blowing off cobwebs they >collected the last time they tried to think. Thank you, Craig. I appreciate the compliment. DOS is not "reentrant" in the same sense as an operating system like OS-9. In such an operating system, almost everything is reentrant. (Certain portions of device drivers do not need to be.) If MS-DOS were reentrant to that extreme, writing a TSR would be trivial. Of course, some portions of the real-world MS-DOS are reentrant. I would hope they were, since it is very hard to write an operating system that has no reentrancy. However, the reentrancy is, in general, of a limited nature. The most useful calls, like the file handle I/O functions, are _not_ reentrant. It's this deficiency that makes TSR programming tricky. Essentially, the statement "DOS is not reentrant" probably refers to the MS-DOS function-call interface, which is largely _not_ reentrant. I think that any person making such a statement would know as well as you that some portions of MS-DOS are reentrant. It's just that other parts of MS-DOS, the high-level parts most useful to a programmer, are not. Incidentally, your point could have been made just as effectively without the insult. -- Stephen Trier Case Western Reserve University Work: trier@cwlim.ins.cwru.edu Information Network Services Home: sct@seldon.clv.oh.us %% Any opinions above are my own. %%