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

PE> Now, can anyone explain WHY cvp would do such a thing, 
PE> and secondly, given that it CAN, does this mean that I

PF> I'll bet it has nothing to do with cvp directly (someone else up the parent 
PF> tree is using those file handles already),  but has to do with the 
PF> equivalent of a "start /i".

PF> What happens if you start a session with "start /i" and
run your compile 
PF> from there?

Well, I ran maxtest from a window created with "start /i", and it
only opened 14 files.  Starting from within cvp gave me 15.  This is on my
non-TCP/IP machine, where the difference between the two is only slight.

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

PF> And now you are _for sure_ overwriting some memory beyond
PF> the crt's statically allocated _files[20] array.

I don't think so.  The files are allocated sequentially, regardless of
their DosOpen file handle number.

Also, if that was the case, then my maxtest program would keep opening
files up to the 50 limit of "fh", or trap, whichever came first. 
It doesn't, it only allows me to open 17 files, which is exactly what the
doco of the MS CRT suggests that it does.

PF> I don't think it is possible to get around this problem by patching cl.exe.

It appears to be working fine (c1.exe).  BFN.  Paul. 
@EOT:

---