Mail Archives: djgpp/2001/03/05/02:43:30
On Sun, 4 Mar 2001, Michael Allison wrote:
> Eli, you've made references to a special djgpp method used to pass
> really long command lines between djgpp programs such as make and gcc.
> Could the cause of this be in that code?
I doubt that. There's nothing fancy in how long command lines are
passed; in a nutshell, the parent program puts the long command line
into the transfer buffer (which is a buffer in low a.k.a. conventional
memory), and passes the real-mode address of that buffer to the child
via the DOS command tail. The child then accesses that buffer with
dosmemget and similar functions. Since the same transfer buffer is
used for passing data to and from all DOS/BIOS functions called by a
DJGPP program, I find it hard to believe that this is the reason.
> When I run the test "nesting" program that I posted earlier in the
> thread (parent.c), separate processes are created for each under
> windows 2000:
> 1160 NTVDM.EXE
> 1284 parent.exe
> 332 parent.exe
> 1388 parent.exe
Well, what's so surprising in that? Separate processes are created
for each program even on plain DOS. As long as the processes run in
the same Virtual Machine, we should be okay. (If they don't run in
the same VM, all heck will break lose on us much sooner...)
> Could you point me to some place that explains how this long
> command line sharing is done?
See section 16.4 of the FAQ for a starting point. Beyond that, read
the code of the function `direct_exec_tail' in the file
src/libc/dos/process/dosexec.c found in djlsr203.zip, or ask questions
here.
> I'm wondering if some sort of process boundary or memory protection
> is being violated.
Even if this is true, we still need to explain how come it never shows
on any other platform, including NT4. Spawning child processes is by
far the most frequent thing people do with DJGPP, since compiling
programs involves it.
- Raw text -