Mail Archives: djgpp/2000/04/16/14:48:54
Ok, take the following example
you run RHODE, open up your code,
and 'Build All'.
RHIDE at that stage has full file access, with only enough
memory to support it, if you are using the default dos prompt settings, which
auto scale the amount of memory available to suit the first program.
It then calls gcc, with all of RHIDE still loaded, a chunk of memory overhead
here now. gcc opens up the same source file, that RHIDE has open, possibly
causing a sharing violation (WinNT was always quite strict about this),
and starts compiling, dumping the code to an EXE. Here is another possible
problem, because the spawn program might not have the same full access as the
original program.
But I think the sharing violation is the most probable thing.
Eli Zaretskii wrote:
>
> On Sat, 15 Apr 2000, Robin Johnson wrote:
>
> > Just a thought on this, from something I ran into while trying to compile an
> > old Turbo Pascal v7.0 program on Win2K, part of the code involved calling
> > command.com to do some stuff, and then spawning a child process for a few
> > other things, but I traced the crash to the moment that any child
> > process tried to do any file access, it died. So just an idea to look at
> > the code of SetEdit or anything, and see where it calls spawn(), or
> > maybe just try something that you know will write a file.
>
> Any DJGPP program that can run other programs *will* call spawn at some
> point. So there's no need to look at the sources to know that.
>
> But I'm unsure what exactly are you trying to say. Why is it important
> to know whether spawn is or isn't called? Could you please elaborate?
--
Robin Hugh Johnson
"Robbat2"
QTOD: "I used to be an idealist, but I got mugged by reality."
E-Mail : robbat2 AT tesla DOT t-p-l DOT com
ICQ# : 30269588 or 41961639
Home Page : http://robbat2.t-p-l.com
Time Zone : Pacific Daylight (GMT - 8)
- Raw text -