Re: -dgui option dropped in 2.24 - how to stop the black box on Windows now?

[Richard Shann]

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 don't understand, I'm afraid. Denemo only makes calls to the g_spawn*
functions as documented. The function might_be_console_process() is
static - internal to glib - or rather to some executable that it calls,
apparently.

The name and path of the lilypond executable is typed into Denemo and
the g_spawn call is made - so the only difference is that it is calling
lilypond.exe below the 2.24.0 folder rather than the lilypond-
windows.exe below the 2.22.0 folder. I've just tested this out by
downloading 2.22.0 to the home directory and telling the same Denemo
executable to execute lilypond.exe and lilypond-windows.exe
alternately. With the former I get the terminal popping up and not with
the latter.

Richard Shann