ff76@vaxb.acs.unt.edu (Jhinuk Chowdhury) (12/06/90)
I am required to load a mouse driver (MOUSE.COM) in RAM for many of my application programs (XtreePro Gold, PCWrite, etc.). In order to utilize the maximum amount of RAM, I load the MARK utility in memory first and then the mouse driver with a command like the one below: C:\UTIL\MOUSE C:\MENUS\XTREE.MNU. Finally, I load the application program (Xtree, in this case). The last line in my XTREE.BAT batch file is RELEASE that unloads all TSRs loaded in RAM after MARK. I use the same technique to load any program that requires a mouse driver. The problem is every time this batch file is executed, one file handle gets tied up. In the previous exmple, we would have one file handle associated with XTREE.MNU tied up. If a run Xtree.bat again, more file handle, one for every run and each associated with Xtree.mnu, will get tied up. I need to be able to use as much RAM as possible *without* tying up file handles like this. Any ideas/solutions ? I use a Compuadd 286/12 with 640K, and 384K extended memory (mostly used up), running MS-DOS 3.3. If you prefer, please respond to me directly at FF76@UNTVM1.BITNET and if I have useful responses, I'll summarize. Thanks in advance. - Jhinuk.
dixon@sagittarius.crd.ge.com (walt dixon) (12/08/90)
In <1990Dec6.152246.42736@vaxb.acs.unt.edu> Jhinuk Chowdhury writes >I am required to load a mouse driver (MOUSE.COM) in RAM for many of >my application programs (XtreePro Gold, PCWrite, etc.). In order to >utilize the maximum amount of RAM, I load the MARK utility in memory >first and then the mouse driver with a command like the one below: >C:\UTIL\MOUSE C:\MENUS\XTREE.MNU. Finally, I load the application >program (Xtree, in this case). The last line in my XTREE.BAT batch >file is RELEASE that unloads all TSRs loaded in RAM after MARK. > >I use the same technique to load any program that requires a mouse >driver. The problem is every time this batch file is executed, one >file handle gets tied up. In the previous exmple, we would have one >file handle associated with XTREE.MNU tied up. If a run Xtree.bat >again, more file handle, one for every run and each associated with >Xtree.mnu, will get tied up. I suspect that the problem is not one of losing file handles but one of filling up the system file table. Whenever a file is opened, DOS makes an entry in the System File Table; when the file is closed (or more acurately its reference count goes to 0), DOS deallocates the SFT entry. I suspect that the TSR opens a file (perhaps C:\MOUSE\XTREE.MMU) that is never closed. The first thing I would try is to examine the SFT. The base of the SFT is one of the addresses in the list returned by int 21h ah=52h. The SFT consists of one or more blocks of SFT entries. If there is indeed an SFT entry for an open file, one can either manually remove it from the SFT, or write a program that changes its PSP to that of the program which opened the file (recorded in the PSP), insert the SFT index into an unused Job File Table entry, and issue a close request. Good Luck Walt Dixon {internet: dixon@crd.ge.com } {us mail: ge crd } { po box 8 } { schenectady, ny 12301 } {phone: 518-387-5798 (W) } { 518-875-6203 (H) } Walt Dixon dixon@crd.ge.com
richard@calvin.ee.cornell.edu (Richard Brittain - VOS hacker) (12/09/90)
In article <14625@crdgw1.crd.ge.com> dixon@sagittarius.crd.ge.com (walt dixon) writes: >In <1990Dec6.152246.42736@vaxb.acs.unt.edu> Jhinuk Chowdhury writes >........ >>driver. The problem is every time this batch file is executed, one >>file handle gets tied up. In the previous exmple, we would have one > >I suspect that the problem is not one of losing file handles but one >of filling up the system file table. Whenever a file is opened, DOS >makes an entry in the System File Table; when the file is closed >(or more acurately its reference count goes to 0), DOS deallocates >the SFT entry. I suspect that the TSR opens a file (perhaps >C:\MOUSE\XTREE.MMU) that is never closed. A few months ago I posted a little program to c.b.i.p called "fstat" that does nothing but read the System File Table and display all the files that DOS thinks are still open, along with the name of the program that opened each one. This is exactly the kind of problem it was aimed at diagnosing. Look in the archives or write me. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.ee.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard -- Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.ee.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard