Path: utzoo!utgpu!attcan!uunet!steinmetz!control!dixon From: dixon@control.steinmetz (walt dixon) Newsgroups: comp.sys.ibm.pc Subject: Re: Answers!!! not questions Keywords: Files=xxx Message-ID: <11890@steinmetz.ge.com> Date: 18 Aug 88 14:02:54 GMT References: <22648@amdcad.AMD.COM> Sender: news@steinmetz.ge.com Reply-To: dixon@control.steinmetz.ge.com (walt dixon) Organization: General Electric CRD, Schenectady, NY Lines: 73 There are really two separate issues here. Each program segment prefix (PSP) contains the address of a data structure known as the Job File Table (JFT). The default JFT is itself part of the PSP, but it can be moved. [DOS 3.3 function int 21h ah=67h does this. In older DOS versions one could alter the JFT address within the PSP; this change causes problems when the PSP is cloned.] Each JFT entry is one byte long and contains either a System File Number (SFN) or 0xff. The SFN is an index into another DOS data structure known as the System File Table (SFT). The handle returned by open and create services is an index into the JFT; a JFT value of 0ffh indicates the corresponding handle is unused. Each program has its own PSP, but there is only one copy of the SFT. [There is a separate SFT for FCB access.] The SFT is the focal point for device independent I/O. Each SFT entry contains the file name, (the path portion of the name is removed), file position, owner, reference count, flags, and device driver/device control block (DCB) address. [The DCB is an intermediate data structure for block devices. The DCB contains the address of the block device driver.] Each SFT entry is 35h bytes long. DOS will expand the SFT upto the files= value from config.sys. SFT entries are allocated in groups, but basically form a linked list. The initial block of SFT entries can be found using the undocumented int 21h ah=52h service. ES:[BX+4] contains the address of the first SFT block. When one opens/creates a file, DOS allocates a handle by scanning the JFT until it finds an unused entry, and then allocates an SFT entry. DOS records the current PSP in the SFT owner field and initializes the reference count to 1. If the "no inherit" bit is set, DOS sets the SFT flags field appropriately. After locating the file/device, DOS examines perviously used SFT entries looking for duplicate entries. If an SFT entry already exists, the newly allocated SFT entry is released and the reference count is incremented. Note that only one SFT entry exists for an open file or device no matter how many times it has been opened. When a file/device is closed, DOS uses the handle to get to the SFN which in turn locates the SFT entry. The reference count is decremented. When this count goes to zero, the SFT entry is deallocted. Only the file owner can cause the SFT entry to be deallocated. When you run a program, COMMAND.COM uses the int 21h ah=4bh load service. The load service makes the program resident from disk, clones the parent (in this case command.com) PSP, makes the new program the current PSP, and sets up a termination address. Any files opened by command.com are propagated to the child program. Normally command.com opens stdin, stdout, stderr, stdaux, and stdprn. When a program terminates, DOS scans the PSP and closes all its files and deallocates any memory blocks owned by the PSP. Closing the files inherited by command.com mereley decreases the SFT reference count. When a TSR terminates and stays resident, its open files are not closed. COMMAND.COM and any resident TSRs take up SFT entries. Since an SFT entry takes up a relatively small amount of memory, it is normally not a problem to set files= to a reasonable number. If you like living dangerously, a program which needs an abnormally large number of SFT entries can increase the SFT table size itself and decrease it when it terminates (watch out for TSRs which open files). A more complete description of these data structures can be found in Chapter 4(?) of the revised MS DOS Developer's Guide which will be published sometime soon (Howard Sams is the publisher). [Although I am the author of this chapter, I get no royalties. Just citing a good reference.] Walt Dixon {ARPA: dixon@ge-crd.arpa } {US Mail: GE Corp. R&D } { PO Box 8 } { Schenectady, NY 12345 } {Phone: 518-387-5798 } Standard disclaimers apply.