Mail Archives: djgpp/1994/03/23/18:30:51
The question was:
>>
>> What are the possible reasons why stub.exe says "Cannot exec go32" ?
And the answer was:
>
>(1) availability. Run "go32" and make sure it finds it.
>
>(2) memory. Run "go32" and see how much memory it says you have left.
This isn't strictly true. I've *frequently* had a situation where I
would do the following:
Type 'make' to build my project
Make starts up, and I see the 'gcc' command line for a source file
The machine sits for a bit
Make issues a 'cannot exec go32' error and quits
Type 'make' again
Everything compiles correctly
It's strange. I *think* it has to do with access to non-DOS memory getting
hosed somehow, because repeated invocation of 'make' after, say deleting
.o files works, but the instant I start my editor (Brief) and exit out
again, I get the above behavior.
Most of the time, that is. The problem seems to develop as I keep working.
More precisely, it will suddenly start exhibiting the above behavior, and
won't stop until I reboot, at which point the machine starts acting sanely
again for a while (until I do whatever it is that triggers the problem,
that is - I haven't pinned it down).
My memory environment is ... baroque, to say the least. I use 4DOS 5.0,
loaded high, with its environment and aliases also high, as well as QEMM 7
(though without any 'Stealth' functions turned on). In addition, I have
a bus-mastering SCSI drive D:, which requires some jiggery-pokery to coexist
peacefully with QEMM. I also have QEMM's QDPMI driver loaded, because for
my *work* compilation I have to use Microsquishy C++ 7.0 (shudder).
This all means that my machine is pretty delicately balanced; it'd be
fairly easy for some subtle problem in any of a number of pieces of
hardware or software to cause strange behavior like the above. Don't you
just love debugging PC memory problems? :-)
-- Chris Tate
fixer AT faxcsl DOT dcrt DOT nih DOT gov
- Raw text -