chiang@iris.ucdavis.edu (Tom Chiang) (01/29/91)
following below is asm code for a tsr with a few lines added by me... the tsr basically intercepts int 16 and changes the case of the letter Y whenever it it is typed....now, i added code to send the letter z to printer every time this int occured...but my system crashes from those new lines...any help would be appreciated PAGE 64,132 cseg segment assume cs:cseg,ds:cseg org 100H TSR proc far jmp initialize old_keyboard_io dd 0 new_keyboard_io proc far assume cs:cseg,ds:cseg sti cmp ah,0 je ki0 assume ds:nothing jmp old_keyboard_io ki0: pushf assume ds:nothing call old_keyboard_io cmp al,'y' jne ki1 mov al,'Y' jmp kidone ki1: cmp al,'Y' jne kidone mov al,'y' kidone: push dx ----- push ax | mov dl,'z' | mov ah,5H | ----- these are the instructions i added int 21H | pop ax | pop dx ------ iret new_keyboard_io endp initialize: assume cs:cseg,ds:cseg mov bx,cs mov ds,bx mov al,16H mov ah,35H int 21H mov si,offset old_keyboard_io mov [si],bx mov [si+2],es mov dx,offset new_keyboard_io mov al,16H mov ah,25H int 21H mov dx,offset initialize int 27H TSR endp cseg ends end TSR
yawei@bronze.ucs.indiana.edu (mr. yawei) (01/30/91)
In article <8256@ucdavis.ucdavis.edu> chiang@iris.ucdavis.edu (Tom Chiang) writes: > >following below is asm code for a tsr with a few lines added by me... >the tsr basically intercepts int 16 and changes the case of the >letter Y whenever it it is typed....now, i added code to send the >letter z to printer every time this int occured...but my system >crashes from those new lines...any help would be appreciated This is called the DOS re-entrancy problem which anyone who is teaching you to write TSRs should have told you about. Simply speaking, DOS cannot be entered twice. Since the int 16h request most likely comes from inside DOS, issuing another DOS call destroys the stack of the first call thus causing the system to crash. (Actual situation is more complicated since DOS uses several stacks. Try to get some books on this subject. Unfortunately, I can't think of any good books on writing TSRs. Has anyone seen one?) Changing your code to the following may work: ; push/pop ax/dx as needed... mov ah, 0 ;output char to printer function mov al, 'z' sub dx, dx ;(lpt1) int 17h ;BIOS printer output interrupt > push dx ----- > push ax | > mov dl,'z' | > mov ah,5H | ----- these are the instructions i added > int 21H | > pop ax | > pop dx ------ Good luck! yawei
sonny@charybdis.harris-atd.com (Bob Davis) (01/30/91)
In article <1991Jan29.173752.10045@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: >In article <8256@ucdavis.ucdavis.edu> chiang@iris.ucdavis.edu (Tom Chiang) writes: >> [DELETIONS] > >This is called the DOS re-entrancy problem which anyone who is teaching >you to write TSRs should have told you about. Simply speaking, DOS >cannot be entered twice. Since the int 16h request most likely comes >from inside DOS, issuing another DOS call destroys the stack of the >first call thus causing the system to crash. (Actual situation is more >complicated since DOS uses several stacks. Try to get some books on this >subject. Unfortunately, I can't think of any good books on writing >TSRs. Has anyone seen one?) > Those wishing to learn more about the writing of TSRs might be interested in my evolving software package called TBONES. The current preliminary version is TBONES07, with 08 coming soon. E-mail for a copy. The following is an excerpt from TBONES07.DOC: SOURCES OF FURTHER INFORMATION ON PROGRAMMING TSRs: BOOKS: ----- One of the best treatments I know of on the complex considerations in writing a robust TSR appears in: _Inside DOS: A Programmer's Guide_ Author: Michael J. Young Publisher: SYBEX, 490 pp., (C)1988, 1990. Chapter 11: "Memory Residency" pp. 321-360. A book which contains a wealth of information useful in designing good TSRs is: _Undocumented DOS: A Programmer's Guide to Reserved MS-DOS Functions and Data Structures_ by Andrew Schulman, Raymond J. Michels, Jim Kyle, Tim Paterson, David Maxey, and Ralf Brown. Publisher: Addison-Wesley Publishing Company, Inc., (C)1990. Chapter 5: "Memory Resident Software: Pop-ups and Multitasking" by Michels, Paterson, and Schulman. I also have learned much from the book: _DOS Programmer's Reference, 2nd Edition_ by Terry Dettmann and revised for 2nd Edition by Jim Kyle (C)1989 by QUE Corporation, Programming Series I have found it indispensable as a source for detailed DOS programming information. The Waite Group's _Microsoft Macro Assembler Bible_ by Nabaiyoti Barkakati has been most useful on Assembly Language matters. _____________________________________________________________________________ Bob Davis, UofALA alum \\ INTERNET: sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP: ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER: K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE: (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX: (407) 729-3363 | FOR MYSELF. |_________|
cd5340@mars.njit.edu (Charlap) (01/30/91)
In article <5369@trantor.harris-atd.com> sonny@trantor.harris-atd.com (Bob Davis) writes: >In article <1991Jan29.173752.10045@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: >>In article <8256@ucdavis.ucdavis.edu> chiang@iris.ucdavis.edu (Tom Chiang) writes: >>> > [DELETIONS] >> >>This is called the DOS re-entrancy problem which anyone who is teaching >>you to write TSRs should have told you about. Simply speaking, DOS >>cannot be entered twice. Not quite. DOS re-enters itself all over the place. There is a scheduler interrupt (I forget what it is, though) which is very undocumented, which many hackers use for making re-entrant TSR's. Most notable of these is the DOS PRINT command, which uses the scheduler interrupt in order to do background printing. Does anyone have more info? Something was mentioned in the book "The MS-DOS BIBLE" by the Waite group, but it isn't too detailed. --- Dave (cd5340@mars.njit.edu)
stoeen@solan.unit.no (Asbj|rn St|en) (01/30/91)
In article <1991Jan29.173752.10045@bronze.ucs.indiana.edu>, yawei@bronze.ucs.indiana.edu (mr. yawei) writes: |> This is called the DOS re-entrancy problem which anyone who is teaching |> you to write TSRs should have told you about. Simply speaking, DOS |> cannot be entered twice. Since the int 16h request most likely comes |> from inside DOS, issuing another DOS call destroys the stack of the |> first call thus causing the system to crash. (Actual situation is more |> complicated since DOS uses several stacks. Try to get some books on this |> subject. Unfortunately, I can't think of any good books on writing |> TSRs. Has anyone seen one?) Maybe I am wrong, but I thought that most basic character device DOS functions *were* reentrant... It is true that more complex functions (file, disk handling) are not reentrant. Certainly, function 05H should be okay to call. Perhaps someone out there knows more about this... ------------------------------------------------- | _ | |Asbjoern Stoeen / \ /___ | |Studpost 188 /___\ // | |7034 Trondheim-NTH / \ / \__ | |Norway / \ | | / ___/ | -------------------------------------------------
yawei@bronze.ucs.indiana.edu (mr. yawei) (01/30/91)
In article <2168@njitgw.njit.edu> cd5340@mars.njit.edu (Charlap) writes: >>>This is called the DOS re-entrancy problem which anyone who is teaching >>>you to write TSRs should have told you about. Simply speaking, DOS >>>cannot be entered twice. > >Not quite. DOS re-enters itself all over the place. There is a scheduler >interrupt (I forget what it is, though) which is very undocumented, which >many hackers use for making re-entrant TSR's. Most notable of these is the >DOS PRINT command, which uses the scheduler interrupt in order to do background >printing. You didn't read the rest of my paragraph. :-) It said "actual situation is more complicated as DOS uses several stacks..." To be exact (and make my ends covered), DOS uses 3 stacks for its various function calls. So if you stretch it, you can re-enter DOS for a miximum of 3 times. A few other glitches (restrictions) reduce the maximum to 2 times. DOS itself does not detect that you are trying to trash its stack, so it takes elaborate programming to ensure that the re-entrancies are safe. I am not going to elaborate how to do this as it probably will take a couple of chapters. :-) The interrupt you just mentioned is int 28h. Within interrupt 28h it is safe to access some of the DOS functions which mainly deal with disk i/o etc. If you set the DOS critical error flag you can access all the DOS functions within int 28h. The problem in the original question was DOS re-entrancy, however. yawei
imp@Solbourne.COM (Warner Losh) (01/30/91)
In article <2168@njitgw.njit.edu> cd5340@mars.njit.edu (Charlap) writes: >Not quite. DOS re-enters itself all over the place. There is a scheduler >interrupt (I forget what it is, though) which is very undocumented, which >many hackers use for making re-entrant TSR's. Most notable of these is the >DOS PRINT command, which uses the scheduler interrupt in order to do background >printing. Not quite. :-) There is a wonderful book on the underside and hidden corners of DOS called Undocumented DOS by a whole bunch of people whose names I can't remember (except for Ralf Brown of the interrupt list fame). It goes into enough detail that you can write a TSR that has a prayer of working in many environments (and not just the current machine that you are on). It also goes into lots of other things like network redirectors and trapping interrupts. It comes with two disks full of programs. All in all, a good book. Oh yah, most Waite Group books that I have seen aren't worth the paper they are printed on. They contain enough errors and misleading information to be very frustrating to use. However, the MS-DOS Developers Guide by them is better about this than most. I'd go into more details, but _Undocumented_DOS_ does a much better job than I could possibly do here. Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
dandrews@bilver.uucp (Dave Andrews) (01/31/91)
In article <1991Jan30.050646.7067@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: >To be exact (and make my ends covered), DOS uses 3 stacks for its >various function calls. So if you stretch it, you can re-enter DOS >for a miximum of 3 times. A few other glitches (restrictions) reduce >the maximum to 2 times. > >DOS itself does not detect that you are trying to trash its stack, >so it takes elaborate programming to ensure that the re-entrancies >are safe. I am not going to elaborate how to do this as it probably >will take a couple of chapters. :-) It will do everyone around here some good to run, don't walk, to the nearest technical bookstore and purchase the following amazing book: _Undocumented DOS_ Andrew Schulman, Raymond J. Michels, Jim Kyle, Tim Paterson, David Maxey and Ralf Brown Addison Wesley, 1990, 694 pages ISBN 0-201-57064-5 - Dave
trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (02/12/91)
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. %%