On Tue, 2011-03-01 at 16:42 +0000, jcupitt@xxxxxxxxx wrote: > On 1 March 2011 05:00, Roger Penn <roger.penn@xxxxxxxxx> 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+. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
