Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!nosc!cod!bmarsh
From: bmarsh@cod.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Limits on MSDOS file handles (was: File handles, ProComm and MS C)
Message-ID: <512@cod.UUCP>
Date: Fri, 20-Feb-87 11:09:20 EST
Article-I.D.: cod.512
Posted: Fri Feb 20 11:09:20 1987
Date-Received: Sat, 21-Feb-87 15:51:33 EST
References: <1511@im4u.UUCP>
Reply-To: bmarsh@cod.nosc.mil.UUCP (William C. Marsh)
Distribution: world
Organization: Naval Ocean Systems Center, San Diego
Lines: 26

In article <1511@im4u.UUCP> jai@im4u.UUCP (Jai Srinivasan) writes:
>
>The conclusion would appear to be that closing standard files (or at
>least stdprn and stdaux) does not free handles for the system limit.
>Anyone care to comment?
>

Sure!  Since the first 5 file handles are opened for everybody, they are
basically dup'ed (sys call 45H) instead of re-opened for each child task.
All dup'ed file handles refer to the same system file handle, (if you look
up the lseek sys call 42H, you will notice that it has only one read/write
pointer per open file, even if it is dup'ed), these standard file handles
only take up 'user' file handles and not 'system' file handles.  Closing
these file handles only freed up user handles, not system handles.  As Peter
the cinic (or whatever he called himself, sorry I didn't save that part ;-)
mentioned, system file handles are cheap, only 48 bytes.

Bill

-----------

Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@cod.nosc.mil
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh

"If everything seems to be coming your way, you're probably in the wrong lane."