PE> which blows that theory out of the water.  So no matter what the file 
PE> number, it is storing them sequentially in the file array. However!  It is 
PE> still possible that it is CHECKING the file number, instead of the number 
PE> of elements available in the array. That would still explain the phenomena.  
PE> What I need is the MSC CRT, the bit where it calls DosOpen(), to find out 
PE> if there is a silly check there, and if there is, then I can just NOP out 
PE> that code (if I can find out what hex code is generated for that series of 
PE> instructions, and then go and find that same sequence in my no-source 
PE> program (ie CL itself!)).

PE> In the meantime I'll see if I can debug it via assembler.  BFN.  Paul.

Ok, first of all, a surprise result!  If I run the program under cvp,
regardless of whether I compiled with debugging on, HEY PRESTO, I can open
15 files (remember that on my machine I was only getting 13 before, even
with SetMaxFH(60)). Of course the real problem is on a different machine,
where the maximum is 9, but I am not in a position to test that at the
moment, so I'll have to get back to you on that one.

Now the reason that cvp let's me open 15 files, is because it allocates
fileno's of 5-19, this time WITHOUT skipping 6 and 12!

Now, can anyone explain WHY cvp would do such a thing, and secondly, given
that it CAN, does this mean that I can write a utility program to replace
cvp that will reset all the file numbers?

[light bulb]

I went into cvp, and then did an os shell, and it still had the numbers
reset!  Although there was a downside, it decided to take away number 5
from me, so I am down to 14 files, but that could be the break I need.

Enough of the suprises - the real hacking - attempting to fix the bug in the CRT.

I compiled my test program, debugged the assembler, and found that fopen()
is a call to 072A, which is a call to 06F6, whcih has a call to 08FC, which
has a call to 110E, whcih has a call to 1E73:0000. I then found that cvp
had a convenient "calls" facility which told me that the names of
these functions were fopen(), _fsopen(), _openfile(), open().  I assumed
that 1E73:0000 was DosOpen(), because
it created the actual file, but I'll have to investigate that further.
There was a test after that call, which does a compare and complains if it
is greater than a certain value.  I decided to dummy up that jump, and make
it always succeed.  To do this, I looked at the code, which was bytes:

E907F5
E98C00
8B46FE
3B061301
720D

and changed that last "720D" to "EB0D" to always jump
(succeed) as oppose to only succeeding if the number was less than 20.

This enabled me to get up to 17 open files, however the ones with a fileno
> 19 were unusable.  In other words, the change that I
made to the CRT was incorrect.

I therefore need to know:

1. Exactly what code there is in open(), and whether that really is a call
to DosOpen().

2. What that file number is being used for.

This is going to be a virtually impossible task without the source code. 
Could someone who has the source code help me out here. Thanks + bye. 
Paul.
@EOT:

---