TOMIII@MTUS5.BITNET (Thomas Dwyer III) (06/01/90)
I believe there is a bug in MSC 5.1 The following code demonstrates
the problem:
#include <stdio.h>
#include <process.h>
main()
{
putenv("OOG=BLA");
spawnl(P_WAIT, "C:/DOS/COMMAND.COM", "COMMAND.COM", NULL);
}
Running this program under IBM DOS 3.3 results in COMMAND.COM being
invoked, as expected, with "OOG=BLA" in it's environment. However,
the new environment not only has that string, but also a string of
garbage at the end. This garbage string ";C_FILE_INFO$$$$AA" (where
$$$$ = 4 IBM funky characters, ASCII 05, 193, 193, 193) shows up on
every machine the program was run on (True blue PCs and Zenith 386-30)
even when recompiled.
Does anyone see anything wrong with this code?
Thomas Dwyer III TOMIII @ MTUS5.BITNET
Computing Technology Services DWYERIII @ MTUS5.BITNET
Michigan Technological Universitybobmon@iuvax.cs.indiana.edu (RAMontante) (06/02/90)
TOMIII@MTUS5.BITNET (Thomas Dwyer III) <90152.034339TOMIII@MTUS5.BITNET> : -I believe there is a bug in MSC 5.1 The following code demonstrates - [ simple routine to invoke a subshell ] -Running this program under IBM DOS 3.3 results in COMMAND.COM being -invoked, as expected, with "OOG=BLA" in it's environment. However, -the new environment not only has that string, but also a string of -garbage at the end. This garbage string ";C_FILE_INFO$$$$AA" (where -$$$$ = 4 IBM funky characters, ASCII 05, 193, 193, 193) shows up on -every machine the program was run on (True blue PCs and Zenith 386-30) -even when recompiled. I think this is intentional behavior on MSC's part, even prior to v5.1 My Procomm2.4.2, for example, has exactly the same behavior when I shell out (this caused me some confusion at one time); Procomm2.4.2 was compiled with a 1985-vintage MSC... The string ";C_FILE_INFO" appears in three different (nearby) places in the procomm.exe file, seemingly it is marking some area of the executable. (BTW, my "funky characters" are ASC 193,193, 193,1; and they aren't part of the string as stored in the executable.)
mshiels@tmsoft.uucp (Michael A. Shiels) (06/03/90)
That nice binary string inside your environment is MSCs way of communicating file modes between parent/child programs. Under OS/2 they got smart and made it a text string instead of binary. I bought the source code for the library and that was the first thing to go!
darcy@druid.uucp (D'Arcy J.M. Cain) (06/04/90)
In article <90152.034339TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes: >I believe there is a bug in MSC 5.1 The following code demonstrates >the problem: > [...] >the new environment not only has that string, but also a string of >garbage at the end. This garbage string ";C_FILE_INFO$$$$AA" (where >$$$$ = 4 IBM funky characters, ASCII 05, 193, 193, 193) shows up on >every machine the program was run on (True blue PCs and Zenith 386-30) >even when recompiled. No, there is nothing wrong with your code or the compiler. That stuff in the environment is put there by C programs for some unstated purpose of its own. Just ignore the stuff. -- D'Arcy J.M. Cain (darcy@druid) | Government: D'Arcy Cain Consulting | Organized crime with an attitude West Hill, Ontario, Canada | (416) 281-6094 |
jta@locus.com (JT Anderson) (06/05/90)
The ;C_FILE_INFO "variable" that Microsoft C sticks into the environment when you use spawn() or related library calls is used to keep track of which file streams are open in text mode and which ones are in binary mode. Child C programs look at this string so that inherited files are processed properly.