blloyd@bordeaux.axion.bt.co.uk (Brian Lloyd) (12/17/89)
A few months ago someone asked how to have more than 15 files open at a time. Larry Shurr suggested using funtion call 67h, as follows: union REGS inregs, outregs; inregs.h.ah = 0x67; inregs.x.bx = number_of_files; int86(0x21, &inregs, &outregs); (slightly modified for Turbo C) The problem is that this doesn't seem to work, at least for me. It also causes memory allocation problems for ATs under DesqView (ie malloc etc can't reserve any memory). Am I missing something, or is this method wrong? Thanks in advance for any replies. Brian Brian Lloyd, # Via e-mail : blloyd@axion.bt.co.uk RT3152, Rm G44, SSTF, # Via Packet : G1NNA @ GB7NNA.GBR.EU British Telecom Research Labs, # By Phone : +44 (0)473 646650 Martlesham Heath, Ipswich, Suffolk. IP5 7RE
woody@eos.UUCP (Wayne Wood) (12/18/89)
In article <1989Dec17.150044.18175@axion.bt.co.uk> blloyd@axion.bt.co.uk writes: >A few months ago someone asked how to have more than 15 files open at a time. [ stuff deleted ] > >Thanks in advance for any replies. > >Brian why not put FILES=20 in you config.sys file? /*** woody **************************************************************** *** ...tongue tied and twisted, just an earth bound misfit, I... *** *** -- David Gilmour, Pink Floyd *** ****** woody@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/
andy@mks.com (Andy Toy) (12/19/89)
In article <5831@eos.UUCP> woody@eos.UUCP (Wayne Wood) writes: >why not put >FILES=20 >in you config.sys file? Because all it does it change that total number of files that can be opened and not the number of files that each programme can have open. Consider that a programme opens ten files and then spawns another programme that tries to open more files. The total number of files that can be opened will be 20 and not 20 files for each programme. The ``FILES='' cannot give more than 20 files for each programme. The limit is 20 files for each programme, but stdin, stdout, stderr, stdaux, stdprn are automatically open so that leaves each programme with 15 files maximum. You could close stdaux and stdprn for two extra files. -- Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519/884-2251 FAX: 519/884-8861
andy@mks.com (Andy Toy) (12/20/89)
Here's some more information that may be helpful that someone else
here pointed out to me.
--
1) The FILE=nnn in config.sys represents that number of separate opens
on a system wide basis (this doesn't include dup() requests or the
implicit dup() that occurs when a process forks (or exec))
2) The 20 file limit of the file descriptor table per process may be increased
by putting a different pointer into the PSP (currently there is a
seg:offset address inside the PSP to a 20 byte area in the PSP for
the file descriptor codes). This can be pointed to any other location
and a new size given (e.g. 200 open files). The limit is probably
255 because FF is reserved to mean that that entry is closed)
--
Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com
35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy
Ontario, CANADA N2J 2W9 Phone: 519/884-2251 FAX: 519/884-8861pipkins@qmsseq.imagen.com (Jeff Pipkins) (12/20/89)
In article <1989Dec18.164450.3079@mks.com> andy@mks.com (Andy Toy) writes: >In article <5831@eos.UUCP> woody@eos.UUCP (Wayne Wood) writes: >>why not put >>FILES=20 >>in you config.sys file? > >Because all it does it change that total number of files that can be >opened and not the number of files that each programme can have open. >Consider that a programme opens ten files and then spawns another >programme that tries to open more files. The total number of files >that can be opened will be 20 and not 20 files for each programme. >The ``FILES='' cannot give more than 20 files for each programme. > >The limit is 20 files for each programme, but stdin, stdout, stderr, >stdaux, stdprn are automatically open so that leaves each programme >with 15 files maximum. You could close stdaux and stdprn for two >extra files. MS-DOS 3.30 and above allow FILES=20 up to FILES=255. That should be plenty. MS-DOS function 67h can be used to set this dynamically after boot time (i.e. in a program), but you should realize that this function has to allocate some memory for a table. Therefore, many programs must make a call to the DOS SETBLOCK function 4Ah to release some unused memory, since DOS usually allocates all available memory to a newly loaded program. If your program is written in MSC or Turdo C, the startup code will call SETBLOCK for you. If your program must work with all versions of DOS (all means >= 2.0) then you will have to play a little nastier than that. There is some undocumented info in a program's Program Segment Prefix (PSP) that you may want to be aware of. PSP:18h This is a 20-byte translation table for file handles. The length of this table is responsible for the FILES=20 limit. Redirection is handled by the mapping in this table. The handle number used internally by DOS is not necessarily the same as the one used by your program. Since the PSP of a spawned child process is created by first copying the PSP of the parent, the inheritance of open files is a simple operation. PSP:32h This 16-bit word tells the size of the table at PSP:18h. PSP:34h This is a long pointer that is initialized to point to PSP:18h, but it can be changed. If you want to write a program that opens many files at once, you can: 1) Allocate a file handle translation table of sufficient length and initialize the bytes to FFh. 2) Copy the old file table over the new one to preserve access to files already opened. 3) Set the far pointer at PSP:34h to point to the new table. 4) Set the word count at PSP:32h to the number of bytes in the new table. This raises a question about what you want to happen when this program spawns a child process. The usual method causes the table to be copied, not just the pointer to the table. You may want to consider duplicating the table for the child process. Someone asked about inheritance bits on this same newsgroup. One way to prevent a child process from inheriting certain open files is to replace the table entries that correspond to the private handle with an FFh byte, and then restore the byte after the child process terminates. (If you make a copy of the table or if you don't replace the one in the PSP, you can restore it after the child is spawned; if the child shares your table, you'll have to wait until it terminates to restore access to the file if you don't want it to use it.) Good luck. Jeff Pipkins pipkins@imagen.com
ross@cancol.oz (Ross Johnson) (01/10/90)
In article <1989Dec19.161509.10803@mks.com>, andy@mks.com (Andy Toy) writes: > Here's some more information that may be helpful that someone else > here pointed out to me. > -- > 2) The 20 file limit of the file descriptor table per process may be increased > by putting a different pointer into the PSP (currently there is a > seg:offset address inside the PSP to a 20 byte area in the PSP for > the file descriptor codes). This can be pointed to any other location > and a new size given (e.g. 200 open files). The limit is probably > 255 because FF is reserved to mean that that entry is closed) For my own interest, I looked up the PSP description in Thom Hogan's "The Programmer's PC Sourcebook" and can add the following details: (As of DOS3.3): PSP Offset 18H: Handle Table (20 bytes). Usual contents are FFH = slot available. One byte per handle, bit 7 = not inherited (I presume this means you can have 128 files inherited by child processes and 127 files which aren't). PSP Offset 32H: Handle Table size (2 bytes). Usual contents are 14H,00H. PSP Offset 34H: Handle Table address (if not at 12H - 4 bytes). Usual contents are 12H,00H,00H,00H (0000:0012H). (Hope I have the byte orders correct.) +----------------------+---+ | Ross Johnson |:-)| ACSnet: ross@cancol.oz.au | Info. Sciences & Eng.|___| ARPA: ross%cancol.oz.au@uunet.uu.net | Uni. of Canberra | UUCP: {uunet,ukc}!munnari!cancol.oz.au!ross | P.O. Box 1 | CSNET: ross%cancol.oz@australia | Belconnen A.C.T. 2616 | JANET: ross%au.oz.cancol@EAN-RELAY | AUSTRALIA | BITNET: ross%cancol.oz.au@relay.cs.net +--------------------------+