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

[Richard Shann]

On Sun, 2023-04-02 at 11:54 -0700, Aaron Hill wrote:
> On 2023-04-02 8:38 am, Richard Shann wrote:
> > there used to be an executable lilypond-windows.exe in addition to
> > the
> > lilypond.exe which has also vanished. I suspect it was compiled
> > using
> > the option
> > 
> > -mconsole
> > 
> > passed to gcc as this is how Denemo is compiled to avoid leaving a
> > terminal around that would tempt the user to kill everything by
> > dismissing it (Windows users are generally not familiar with
> > terminals).
> 
> Yup.  On Windows, the executable takes two forms based on whether it
> is 
> CLI-based or GUI-based.  lilypond-windows.exe was in all practical
> ways 
> identical to lilypond.exe except that it had WinMain as its
> entrypoint 
> instead of main.  This meant Windows did not automatically allocate a
> console window.  Do note that even GUI-based applications are
> afforded a 
> text console but they must explicitly call the AllocConsole API.
> 
> 
> > If I understand this correctly, it looks like I will have to spawn
> > a
> > process that runs a windows batch file that processes the command
> > line
> > parameters and synthesizes the names of the log file that LilyPond
> > used
> > to create and then calls LilyPond with re-direction of the output.
> > I'm
> > not sure that this can be done without a terminal popping up to
> > annoy
> > the user.
> 
> I have never looked at Denemo or its source code, so what I am going
> to 
> say might not be so trivially applicable. 

You were quite right to be doubtful - Denemo tries to off-load the
target machine dependent stuff onto libraries, in this case glib which
provides the routine to spawn a process, and sadly does not expose the
CREATE_NO_WINDOW part of the Win32 API.
For now I'll disable the autocompilation option for Windows with
LilyPond 2.24. Is there any chance the developers might re-instate the
lilypond-windows.exe?

Richard Shann

> 

>  But in the Win32 API, you can 
> call CreateProcess [1] and use the process flag CREATE_NO_WINDOW
> [2].  
> This should prevent the console window appearing if the child process
> is 
> CLI-based.
> 
> [1]: 
>   
> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
> [2]: 
>   
> https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags
> 
> 
> > Is there anyway of spawning a LilyPond 2.24 process on Windows now
> > without plaguing the user with terminals?
> 
> You might be able to shim with a VBS wrapper.  I do this a lot for 
> custom scheduled tasks that would normally run in the terminal but
> that 
> I do not want to interrupt what I am doing by spawning a window at
> odd 
> times.  Something like this should work, passing arguments to the
> script 
> along to LilyPond:
> 
> ''''
> ' Turn WScript.Arguments into a proper array.
> Dim args()
> ReDim args(WScript.Arguments.Count - 1)
> For i = 0 To WScript.Arguments.Count - 1
>    args(i) = Chr(34) & WScript.Arguments(i) & Chr(34)
> Next
> 
> Dim shell
> Set shell = WScript.CreateObject("WScript.Shell")
> shell.Run "lilypond.exe " & Join(args), 0, True
> ''''
> 
> NOTE: The important parameter here is the zero (0) to shell.Run. 
> This 
> hides the spawned process.  The True waits for the child process to 
> finish, which probably is what you need for this use case.  But if
> you 
> just want to fire off a child process and not have the scripting host
> stick around, change that to False.
> 
> 
> -- Aaron Hill