On Tue, 2011-03-01 at 16:42 +0000, jcup...@gmail.com wrote:
> 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.
Which is why GIMP ships two binaries. A UI version called gimp.exe and a
command-line tool called gimp-console.exe. The latter does not provide
any user interface and doesn't even link with GTK+.
Gimp-developer mailing list