Xref: news2.mv.net comp.os.msdos.djgpp:811
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: A go32 story ...
Date: Thu, 01 Feb 1996 20:22:37 CST
Organization: Rice University, Houston, Texas
Lines: 16
Message-ID: <3111756d.sandmann@clio.rice.edu>
References: <DM2H7n DOT 8Bz AT granite DOT mv DOT net>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> When we put a separate copy of go32.exe into a directory which was in the
> PATH (note that go32 was already in the executables) everything worked fine
> If someone could give an explanation (or even a good guess) what's going on
> here I invite her/him to send comments to this mailing-list/newsgroup or my

Okay, this is a bug in V1's exec.c.  It opens the file to see if it's a
DOS image, stubbed, or a COFF image.  If it's stubbed (and yours is) it then
tries to exec GO32 in the path on the image (interestingly enough, NOT the
one imbedded in the program...).  In the case it can't find GO32 in the
path, it just "gives up" and execs the image itself (which works fine in
your case, since GO32 is imbedded).  The problem is that when it gives up,
it forgets to close the "pf" file handle, so loses one for each exec of
a stubbed image without GO32 in the path.  

This can easily be fixed by editing exec.c, fixing the bug, and replacing it
in the library, and re-linking everything.  This problem isn't in the V2 libc.