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. 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. John _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
