Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!vsi1!octopus!stever From: stever@Octopus.COM (Steve Resnick ) Newsgroups: comp.os.msdos.programmer Subject: Re: stealing an interrupt Message-ID: <1990Dec18.235342.7473@Octopus.COM> Date: 18 Dec 90 23:53:42 GMT References: <90351.150210TOMIII@MTUS5.BITNET> Reply-To: stever@octopus.UUCP (Steve Resnick ) Organization: Octopus Enterprises, Cupertino CA Lines: 66 In article <90351.150210TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes: >Hi there. Would some kind soul please tell me why my machine hangs when >I run this TSR? What am I doing wrong? > >------ Code Begins ------ > >INT_NUM equ 9h > >code segment > org 0100h > assume cs:code,ds:code,es:code [Init Code Deleted] >new_int proc far > jmp short go > >old_int dd ? > >go: > jmp [old_int] ; Jump to old int routine I'm not sure, but I think that this is DS relative. In other words, when your ISR is called, DS may be pointing elsewhere. >new_int endp > > >code ends > end start > >----- Code Ends ------ A much better (IMHO) way to do this, is to borrow the interrupt from the system, call the original ISR, do your own dirty work, and return. The way I do this in a couple programs is to save the old ISR address in the same way you have, but call it differently. new_int proc far jmp short go old_int dd ? go: pushf ; Pushing the flags before a FAR call simulates ; an INT instruction. The ISR being called will ; then IRET to here. call DWORD PTR cs:[old_isr] . . ; Do something usefull here. . IRET new_int endp This gives you the flexibility of handling the original ISR, as well as your own code. Hope this helps.... Steve -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick Flames, grammar errors, spelling errrors >/dev/nul The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0