spinrad@rigel.ucsb.edu (Sanford Spinrad) (01/31/91)
I'm having a problem with TSR programming with MSC. My final goal is write something which catches DOS int 21 read string so that you can do history and file completetion. So I started out by writing a TSR which gets activated from int 60H. The interrupt handler calls a simple c function (_interrupt type) via a jmp (This was done because MSC automatically inserts a return from interrupt after the fucntion completes). The c function only contains 1 printf statement. When I generate the int 60H from the program which installed the int 60H interrupt, everything works fine. But after I TSR the handler and generate int 60H from debug, the print statement prints out garbage and then returns. I am just about positive that this is NOT a re-entrant problem. I know at the time that the int 60H is occuring that the cpu is executing my code, not dos, so it can't be re-entering dos. This leads me to believe that there's something going wrong with the printf library function. I traced through the beginning of the printf fucntion and saw that it did get the correct pointer to the string that it was supposed to print, and the string still contained the correct data. So I'm beginning to belive that I need to do somekind of environmental restoration in order to get the c library to behave correctly. But I don't know what needs to be done. I tried restoring various register values but none of this helped. So I would like to know if my guess is correct in that the c library needs some pointers restored. If so, which library functions are affected (i.e. is only the print routines?). Also what needs to be done to restore the environment? Many thanks, Sandy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sandy Spinrad Internet: spinrad@cornu.ucsb.edu UUNET: uunet!hub.ucsb.edu!spinrad@cornu
yang@ys2.uucp (Yangmin Shen) (02/03/91)
From article <8646@hub.ucsb.edu>, by spinrad@rigel.ucsb.edu (Sanford Spinrad): > I'm having a problem with TSR programming with MSC. ..... > .....The c function only contains 1 printf statement. ..... This is your problem. If you use printf or a number of other MSC funtions which use malloc, memory for the function will be allocated from what the TSR thinks is free memory, only the memory being allocated is actually from whatever is above the stack area of the TSR, which in most cases is in the application which you have invoked from the DOS prompt following the loading of the TSR. You can avoid this by using cprintf if redirection is not important. If you are using MSC6.00, use quick help to look up the malloc function, where you'll find a list of library functions which use malloc and are therefore not suitable for use in TSRs. Also, look up the example program ALARM.C for a good example of a TSR written in C. Good luck! _ Yangmin Shen UUCP: ...!sun!ys2!yang VOICE: +1 408 446 2210 x140 (Day) +1 408 262 4017 (Eve) FAX: +1 408 942 8732 -- Yangmin Shen UUCP: ...!sun!ys2!yang VOICE: +1 408 446 2210 x140 (Day) +1 408 262 4017 (Eve) FAX: +1 408 942 8732
orenalex@bimacs.BITNET (oren alex) (02/08/91)
>not important. If you are using MSC6.00, use quick help to look up the >malloc function, where youll find a list of library functions which use malloc >and are therefore not suitable for use in TSRs. Also, look up the example >program ALARM.C for a good example of a TSR written in C. First, i allways thought that DOS reentrancy problems caused this, as far as i know, printf uses INT 21 (aka DOS) Second, tried to use cprintf inside an ISR (TC++) - blowed the program away. Third, can you email me this ALARM? Bye, Alex
spinrad@rigel.ucsb.edu (02/12/91)
Originally I wrote an article which described that I had problems with printf from a TSR written in MSC. I got many responses which said that this was a reentrantcy problem. Believing that I correctly handled the reentrancy issue, I wrote an assembly language routine which invoked int 21 print string. I used this function instead of using MSC's printf in my TSR and everything worked fine. Thus the problem was due to printf and not to reentrancy. One reply I got (sorry I lost this persons name so I can't give him proper credit), suggested that this was due to printf calling malloc and getting assigned "free" space which was outside the TSR space. I belive this reply was correct. So now I have the option of rewriting the library functions which call malloc, or I can just rewrite the malloc routine. I believe the first method would be easier since I don't need to use too many library functions. However, if someone has already rewritten a malloc to work with MSC's TSR, then the latter method would be easier. So if anyone knows of such a malloc routine, I would appreciate learning more about it. Thanks, Sandy -- Sandy Spinrad Internet: spinrad@cornu.ucsb.edu UUNET: uunet!hub.ucsb.edu!spinrad@cornu
cur022%cluster@ukc.ac.uk (Bob Eager) (02/12/91)
In article <9042@hub.ucsb.edu>, spinrad@rigel.ucsb.edu writes: > Originally I wrote an article which described that I had problems with printf > from a TSR written in MSC. I got many responses which said that this was > a reentrantcy problem. Believing that I correctly handled the reentrancy > issue, I wrote an assembly language routine which invoked int 21 > print string. I used this function instead of using MSC's printf in my > TSR and everything worked fine. Thus the problem was due to printf > and not to reentrancy. I would hazard a guess that your INT 21H call was the one with AH-9. Low numbered calls tend to work OK (whether they're actuallty re-entrant or use a different stack I'm not sure). printf almost certainly uses the UNIX-style 'write' call which is around 40H (don't have the docs here). Why not write your own printf, using a fixed buffer and vsprintf? Then output the generated string with INT 21H AH=9? -------------------------+------------------------------------------------- Bob Eager | University of Kent at Canterbury | +44 227 764000 ext 7589 -------------------------+-------------------------------------------------