I have a new theory. The theory is that the MSC CRT has a fixed array of
20 FILE's. Now instead of doing as I would have expected, ie store the
file number as one of the elements of the FILE structure, and not have any
restriction on the number itself, e.g. 5975, what it is doing is getting
the file number from DosOpen, e.g. 7, and then going to the 7th element of
the array, and storing it there! And if it gets a return file number from
OS/2 > 19, it can't put it anywhere, and fails! So in the extreme, a
device driver may have set the maximum file handles to 500, and then
proceeded to open 50 files, getting numbers 5-55 allocated to it (e.g.),
and then the MSC application won't be able to open a SINGLE FILE!
This is only a theory mind. The actual evidence I have is:
1. It fits the weird results as documented before (and below)
2. I printed out the file handles (using MSC's fileno() function) and the
last file allocated went in at 19, with 6 and 12 being skipped, implying
that only 0-19 are valid.
3. On my current testing machine, I can open 13 files via fopen. However,
by increasing the number of file handles via an explicit call via
DosSetMaxFH(60), although I can still only open 13 files via fopen(), the
14th file IS actually created, implying that a call to DosOpen() is done
FIRST (which succeeds, since OS/2 has enough file handles), but the number
returned is almost certainly 20, and that upsets the MSC CRT.
Hmmm, I just went to get a bit more evidence, ie printing out the location
of the FILE pointer, and got...
file number is 5 001F:0190
file number is 7 001F:019C
file number is 8 001F:01A8
file number is 9 001F:01B4
file number is 10 001F:01C0
file number is 11 001F:01CC
file number is 13 001F:01D8
file number is 14 001F:01E4
file number is 15 001F:01F0
file number is 16 001F:01FC
file number is 17 001F:0208
file number is 18 001F:0214
file number is 19 001F:0220
which blows that theory out of the water. So no matter what the file
number, it is storing them sequentially in the file array. However! It is
still possible that it is CHECKING the file number, instead of the number
of elements available in the array. That would still explain the phenomena.
What I need is the MSC CRT, the bit where it calls DosOpen(), to find out
if there is a silly check there, and if there is, then I can just NOP out
that code (if I can find out what hex code is generated for that series of
instructions, and then go and find that same sequence in my no-source
program (ie CL itself!)).
In the meantime I'll see if I can debug it via assembler. BFN. Paul.
On 1996-10-01 20:58, Paul Edwards of 3:711/934.9 wrote:
PE> With a 16-bit MSC 6.0 compiled program, I only appear to be able to open 14
PE> files via fopen, even when I use "fh" (a program to
increase the maximum
PE> number of file handles). When I run a program that calls DosOpen instead
PE> of open, the restriction goes from 14 to 44.
PE> I would therefore assume that it is a CRT restriction that is holding me
PE> back to 14 files.
PE> However, under a different environment, the maximum number of files that
PE> can be opened is 9!
PE> I would therefor assume that is an OS/2 file handle restriction that is
PE> holding me back to 9 files (since I know the CRT can do 14).
PE> Can anyone explain this anomaly?
PE> And can anyone suggest a fix?
PE> And actually, the objective of all this is not to create a program that
PE> opens >14 files, the objective is to get MSC 6.00 to compile a
program with
PE> >5 include file depth in a TCP/IP environment, without complaining that it
PE> can't find the 6th include file!
PE> Summary:
PE> MAXTEST - program that opens files via fopen()
PE> MAX2 - program that opens files via DosOpen()
PE> FH - program to increase maximum file handles
PE> CL - MSC 6.0
PE> testing on a machine that uses TCP/IP
PE> -------------------------------------
PE> FH MAXTEST = 9
PE> MAXTEST = 9
PE> FH MAX2 = 40
PE> MAX2 = 9
PE> FH CL = 5 levels of includes
PE> non-TCP environment
PE> -------------------
PE> FH MAXTEST = 13
PE> MAXTEST = 13
PE> FH CL = 9 levels of includes
PE> Thanks + bye. Paul.
@EOT:
---
* Origin: X (3:711/934.9)
|