Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!agate!usenet
From: raymond@math.berkeley.edu (Raymond Chen)
Newsgroups: comp.os.msdos.programmer
Subject: Re: How to change Number of Open Files
Message-ID: <1991Apr2.000459.23232@agate.berkeley.edu>
Date: 2 Apr 91 00:04:59 GMT
References: <1991Mar31.011139.8147@news.arc.nasa.gov> <1991Mar31.213543.28347@news.iastate.edu> <1991Apr1.023910.22196@hellgate.utah.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: raymond@math.berkeley.edu (Raymond Chen)
Organization: U.C. Berkeley
Lines: 26
In-Reply-To: bwilliam%peruvian.utah.edu@cs.utah.edu (Bruce R. Williams)

In article <1991Apr1.023910.22196@hellgate.utah.edu>, bwilliam%peruvian (Bruce R. Williams) writes:
>It isn't a matter of how many buffers you have, it's a limit set inside DOS.

Actually, it's a limit that Borland stupidly hard-coded into their
library support routines.  If you study the library source code,
you'll see a line that says

	#define NFILES 20

and then external arrays _openfd and _iobuf declared to be NFILES
elements long.  (I may have the array names wrong; I'm working
from memory.)  The number twenty is HARD-CODED into all of the
I/O support routines (fopen, read, seek, etc.), so the only way
to get around the limit is either

[1] Buy the TC source code, change the #define and recompile.
[2] Reverse-engineer the library object code and change the 20 to
    a larger number in all of the functions where it appears,
    as well as deleting the OBJs that declare _iobuf and _openfd
    and adding replacements that declare them with a larger size.
[3] Avoid the supplied functions and talk to DOS directly.
[4] Switch to a different compiler.  (MSC comes with instructions
    in one of its README files on how to increase the number
    of open files.)

I can probably help anyone who wants to try method [2].