nathan@eddie.MIT.EDU (Nathan Glasser) (06/27/87)
Suppose I've got a procedure set up as an interrupt handler, and I either make its containing program resident (Dos fn 31h), or make its containing program run (spawn) another program. (These two cases are really very similar). And suppose I wish the handler to open a file and leave the file open between invocations of the handler, eventually closing it on some other invocation. Just doing it in the straightforward way doesn't work. I set up the handler to be resident, and had another program X cause interrupts (based on keystrokes). I found that the handler could successfully open, write, and close the file as long as we don't exit X. If I exit X after opening the file, the file is automatically closed. This leads me to believe that Dos thinks that the file is one of the ones opened by program X, and therefore closes it when X exits. (Strictly speaking, I was using MSC, and it may be its exit() call that closes all the files. I'm not sure on this point, but I don't think it matters). Someone told me I might have to deal with the PSP (program segment prefix) in order to make the files work right. Could someone who knows how to make this work please explain the steps necessary to do it. Hopefully it will be something simple, like just telling Dos that that it should look at my handler program's PSP instead of X's PSP, and then putting things back again. I don't know where the PSP for a running program is located, nor do I know how does knows where its "current" PSP is located. Thanks, -- Nathan Glasser nathan@mit-eddie.uucp (usenet) fnord nathan@xx.lcs.mit.edu (arpa) "A tribble is the only love that money can buy."
mark@imagen.UUCP (Mark Peek) (06/29/87)
In article <6207@eddie.MIT.EDU>, nathan@eddie.MIT.EDU (Nathan Glasser) writes: > > Suppose I've got a procedure set up as an interrupt handler, and > I either make its containing program resident (Dos fn 31h), or > make its containing program run (spawn) another program. (These > two cases are really very similar). And suppose I wish the > handler to open a file and leave the file open between invocations > of the handler, eventually closing it on some other invocation. > > Just doing it in the straightforward way doesn't work. I set up > the handler to be resident, and had another program X cause > interrupts (based on keystrokes). I found that the handler could > successfully open, write, and close the file as long as we don't > exit X. If I exit X after opening the file, the file is > automatically closed. > > This leads me to believe that Dos thinks that the file is one of > the ones opened by program X, and therefore closes it when > X exits. (Strictly speaking, I was using MSC, and it may be its > exit() call that closes all the files. I'm not sure on this point, > but I don't think it matters). > > Someone told me I might have to deal with the PSP (program segment > prefix) in order to make the files work right. > > Could someone who knows how to make this work please explain the > steps necessary to do it. Hopefully it will be something simple, > like just telling Dos that that it should look at my handler > program's PSP instead of X's PSP, and then putting things back again. > I don't know where the PSP for a running program is located, nor do > I know how does knows where its "current" PSP is located. > > Thanks, > -- > Nathan Glasser > nathan@mit-eddie.uucp (usenet) > fnord nathan@xx.lcs.mit.edu (arpa) > "A tribble is the only love that money can buy." This made the rounds in the newsgroup in the past month or two but it it probably worth going over again. Also, Micro Cornucopia (June/July'87) has a pretty good article about this same subject. Ths PSP for an MS-DOS program contains some interesting information for dealing with file handles. At location PSP:0034H there is a far pointer to a table of bytes (the pointer is usually set to PSP:0018H) and there is a word at PSP:0032 that contains the maximum number of handles per program (defaults to 20). By default, the first five files are pre-opened by DOS. These are stdin, stdout, stderr, stdaux and stdprn (the last two might be switched around) Therefore, the first 5 bytes at PSP:0018H contain indexes into the DOS global file table (which should be FCB's). The other 15 bytes contain 0xFF. These numbers set the limits for maximum open files, etc. The FILES=XX entry in CONFIG.SYS set the size of the Global file table and the maximum number of files per program is 20 (hardcoded by DOS). Supposedly, a larger maximum files opened per program can be accomplished by allocating your own table, modify the number at PSP:0032 to a new maximum and change the pointer at PSP:0034 to point to the new table. Now, after all of that...when you have a TSR program that opens and closes files, you MUST switch to the TSR's PSP in order for DOS to maintain those files across other programs starting and exiting. If you do not, then the files are opened in the applications PSP (as opposed to the TSR's PSP). Thus, when the application exits, you will not have a valid file handle because DOS just closed it. This could also cause problems later on with other applications if they have a files handle open numbered the same as the one your TSR has open. To switch PSP's around, you use the following code sequences. These assume that the TSR's PSP has already been saved into a variable when the TSR installed itself. Also, be careful about using DOS in interrupt routines, DOS is NOT re-entrant. Our TSR does not have to check the in-dos flag but yours might. ; On entry into the interrupt routine: ; Switch out psp and switch ours in push bx mov ah, 62h ; get current psp (the applications PSP) int 21h mov cs:old_psp, bx ; save the applications psp mov bx, cs:our_psp ; get our (the TSR's) PSP mov ah, 50h int 21h ; switch to out PSP pop bx ; End psp change ...Do file I/O now .... ; On exit from the interrupt routine ; Restore old psp push bx mov bx, cs:old_psp mov ah, 50h int 21h ; switch back to the applications PSP pop bx ; Done restoring psp Anyway, I hope this helps...Please, no flames about undocumented functions and hard coded locations. This is the only way that I know how to get around these limitations. ---- Name: Mark Peek Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101 Santa Clara, CA 95052-8101 AT&T: (408) 986-9400 UUCP: ...{decvax,ucbvax}!decwrl!imagen!mark ARPA: mark@ford-scf1.arpa