On 1 March 2011 05:00, Roger Penn <roger.p...@gmail.com> wrote:
> work out all the how's and so-forth, but for now if anyone knows the inner
> workings of gimp-quit or why calling gimp.exe from the command line forks
> two gimp processes I'd sure be grateful for some insight. Thanks.
I might be able to help a little on the forks-two-processes thing. My
app does this as well, because Windows distinguishes between
command-line and GUI .exes.
When Windows launches a program from the shell, it checks a flag in
the .exe to see if this is a command-line or a GUI program. If it's
been tagged as a GUI program, it just gets started, but if it's been
tagged as command-line, Windows will pop up a console and use that to
display stdin and accept stdout for the program.
Conversely, if you start a command-line program from the command-line,
command.com will display stdout, pipe stdin, and wait until the
program terminates before showing the prompt again. If you run a GUI
program from the command-line, stdin/stdout for the program go nowhere
and command.com will offer the prompt again immediately without
waiting for the program to finish.
As a result of this strange design, it's impossible on Windows to
write a .exe that can be used smoothly both from the command-line and
from the desktop.
The usual solution people recommend is to have a tiny wrapper .exe for
command-line work. This is a program which is tagged as CLI and which
when run starts the GUI .exe, linking that program's stdin/stdout back
to the calling command.com, and then waiting for the GUI .exe to exit.
So it sounds to me, though I've not checked and this is just a guess,
that the Windows wrapper .exe is not terminating correctly in the new
gimp. Also, this is from memory of looking into this a few years ago,
I've probably messed up the details, argh.
Gimp-developer mailing list