PE> I have a new theory.  The theory is that the MSC CRT has a fixed array 
PE> of 20 FILE's.  Now instead of doing as I would have 
PE> expected, ie store the file number as one of the 
PE> elements of the FILE structure, and not have any 
PE> restriction on the number itself, e.g. 5975, what it 
PE> is doing is getting the file number from DosOpen, e.g. 
PE> 7, and then going to the 7th element of the array, and 
PE> storing it there!  And if it gets a return file number

PF> This is true (and so do all of the other CRT's i've seen the source code
PF> for; it's an easy way to get the fileno(), getc(), etc macros to work).

My tests show that the FILE *'s are being allocated sequentially, not being
plonked into their relative DosOpen() position.

PF> Do you have a lot of baggage running?  I simple test is to run:

PF> void nextfh(void)
PF> {
PF> FILE *f = fopen("out", "wb");
PF> fprintf(stderr, "fh = %u\n", fileno(f));
PF> fclose(f);
PF> }

PF> If your system has no file-handle-bagage,  and you run this from main(),it 
PF> should display 3.

It does indeed display 3.  However, when I run maxtest, my fileno's start
at 5 not 3, and then miss 10 + 12.  The reason they are starting at 5
instead of 3 is because I was doing a printf first.  Bizaare! I would have
expected to see it using the preallocated fh 1.

Anyway, I decided to suppress printf's right to the end, to see what would
happen, and guess what, my printf didn't come out!!!  It did open one extra
file though.  This particular window was opening 13 files all the time,
until I made the printf only happen last, then it went up to 14.  Here are
the file numbers it allocated...

fileno is 3
fileno is 5
fileno is 6
fileno is 7
fileno is 9
fileno is 10
fileno is 11
fileno is 13
fileno is 14
fileno is 15
fileno is 16
fileno is 17
fileno is 18
fileno is 19

Ok, so from this I conclude that 4 + 8 + 12 are being allocated by
something in the system somewhere.  My file handles start at 3, but printf
takes one of them away from me.  Here is the program I was using (that
doesn't display the results of printf!!!):

/* Test maximum number of files that can be opened */
/* Written by Paul Edwards and released to the public domain */

#include 

int main(void)
{
    int x;
    char fnm[FILENAME_MAX];
    FILE *fq;

    for (x = 1; x <= 200; x++)
    {
        sprintf(fnm, "maxxx.%d", x);
        fq = fopen(fnm, "w");
        if (fq == NULL)
        {
            printf("max is %d\n", x - 1);
            return (0);
        }
        fprintf(fq, "fileno is %d\n", fileno(fq));
    }
    printf("max is at least %d\n", x - 1);
    return (0);
}


Now, let's see what happens when I do both a printf and an fprintf to
stderr before opening the first file!

Back to 13, but not to 12.  First number allocated was 5.  In other words,
stderr isn't taking my file number.

PE> And actually, the objective of all this is not to 
PE> create a program that 
PE> opens >14 files, the objective is to get MSC 6.00 
PE> to compile a program with 
PE> >5 include file depth in a TCP/IP environment,

PF> Try moving all of the tcpip RUN= and CALL= from config.sys into a batch 
PF> file (as DETACH for RUN=) that you run later.  I'll bet the problem goes 
PF> away.

Ok, I'll find out what is being used on the TCP/IP machine.  I was under
the impression that it was a DEVICE=, not a RUN or CALL.

BFN.  Paul.
@EOT:

---