On Tue, 2023-04-04 at 12:03 +0200, Jean Abou Samra wrote:
> Le mardi 04 avril 2023 à 11:34 +0200, Jean Abou Samra a écrit :
> Le lundi 03 avril 2023 à 20:50 +0200, Jonas Hahnfeld via LilyPond
> user discussion a écrit :
> > This shouldn't be needed: g_spawn_sync internally uses a helper
> > executable that should take care exactly of this aspect. LilyPond
> > uses
> > it internally to call Ghostscript.
> Hmm, but Denemo is already using g_spawn_sync and still experiencing
> this issue, or am I missing something?
> You are right that the GLib sources contain a gspawn-win32-helper.c
> program with the comment
> /* We build gspawn-win32-helper.exe as a Windows GUI application
> * to avoid any temporarily flashing console windows in case
> * the gspawn function is invoked by a GUI program. Thus, no main()
> * but a WinMain().
> */
> Later, there is
> #ifndef HELPER_CONSOLE
> int _stdcall
> WinMain (struct HINSTANCE__ *hInstance,
> struct HINSTANCE__ *hPrevInstance,
> char *lpszCmdLine,
> int nCmdShow)
> #else
> int
> main (int ignored_argc, char **ignored_argv)
> #endif
> Apparently, there are two such executables, gspawn-win32-helper.exe
> and gspawn-win32-helper-console.exe, the latter compiled with -
> DHELP_CONSOLE.
> In gspawn-win32.c, I see
> if (might_be_console_process ())
> helper_process = HELPER_PROCESS "-console.exe";
> else
> helper_process = HELPER_PROCESS ".exe";
> which calls
> static gboolean
> might_be_console_process (void)
> {
> // we should always fail to attach ourself to a console (because
> we're
> // either already attached, or we do not have a console)
> gboolean attached_to_self = AttachConsole (GetCurrentProcessId ());
> g_return_val_if_fail (!attached_to_self, TRUE);
>
> switch (GetLastError ())
> {
> // current process is already attached to a console
> case ERROR_ACCESS_DENIED:
> return TRUE;
> // current process does not have a console
> case ERROR_INVALID_HANDLE:
> return FALSE;
> // we should not get ERROR_INVALID_PARAMETER
> }
>
> g_return_val_if_reached (FALSE);
> }
> Richard, maybe might_be_console_process is returning true inside
> Denemo for some reason?
I couldn't follow up this suggestion because I don't have a way of
building Denemo for Windows to experiment with. But it occurred to me
that I *could* test this idea just by swapping the executables
gspawn-win32-helper.exe and gspawn-win32-helper-console.exe around -
that is, running the opposite one that the
might_be_console_process (void)
call suggests.
I did this and it turns out that this doesn't prevent a terminal from
popping up, however there is a clue: the title of the program being run
in the title bar of the terminal changes from lilypond.exe to gspawn-
win32-helper.exe when that program is replaced by gspawn-win32-helper-
console.exe.
So it would seem that a terminal would pop up regardless of which of
those gspawn-win32 helper programs ran, but the title bar would name
the helper program rather than the lilypond.exe program.
Richard
