Date: Wed, 22 May 1996 08:42:29 +0200 (IST) From: Eli Zaretskii To: Juanjo Erauskin Cc: djgpp AT delorie DOT com Subject: Re: maximum open files for program In-Reply-To: <31A0845F.92C@jet.es> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 May 1996, Juanjo Erauskin wrote: > When the program call system() function, return this error: > foo.exe: cannot open This is a misfeature of MS-DOS that has (almost) nothing to do with DJGPP. The error message is printed by the stub of the child program when it tries to open `foo.exe' in order to read the COFF info (which it needs to know how the program should be set up in memory). If the parent program has used up more than 20 file handles, that DOS Open call will fail. The reason is that the child inherits the open files of its parent, so it too has 20 used handles. While DJGPP allows you to open much more than 20 files, it does so only when you call one of the high-level library functions (like fopen and open); the stub cannot call these because it reads the .exe file before it even switches into protected mode. And while the parent might have increased its maximum file handle count beyond 20, the DOS Exec call used to spawn the child arranges it to have only the default 20 handles (so only they are really inherited). The bottom line is that when the stub calls Int 21h/AX=3D00h, DOS finds that all the 20 file handles are in use and returns with an error. Your test program doesn't tell enough to know what kind of application needs to keep a large number of files open when it calls `system'. If that is a real need, I can think of a few work-arounds: 1) If you can get away with less than 15 open files, you should have no problems. 2) Close one of the unused standard handles (3 and 4, connected by default to AUX and PRN, come to mind) *before* you begin opening the real files you need. This will work if you only need 16 or 17 files open when you call `system'. 3) Open a few dummy files *before* you open the real files. Close those dummy files immediately before you call `system'. This will cause some of the handles in the first 20 slots to be free, but push some of the real files into the portion of the handle table that isn't inherited by the child (a rare program needs to inherit any handle but the first 3 standard ones, though). Note that I didn't have time to test the above work-arounds, so I cannot promise that they really work (I might have missed something).