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

[Aaron Hill]

On 2023-04-03 3:19 am, Richard Shann wrote:
> On Sun, 2023-04-02 at 11:54 -0700, Aaron Hill wrote:
> > I have never looked at Denemo or its source code, so what I am going
> > to
> > say might not be so trivially applicable.
> >  But in the Win32 API, you can
> > call CreateProcess and use the process flag CREATE_NO_WINDOW.
>
> 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.

Ah, such is the bane of cross-platform programming.  Often these edge 
cases get overlooked with API abstractions.


> 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?

The question of the hour is: Is this a LilyPond problem or a Denemo 
problem?  (Well, one could also ask whether this is a glib problem.)  If 
another third-party tool like Frescobaldi is still working given the 
change in LilyPond, then the case could be made that this is something 
best addressed in Denemo itself.  However, if LilyPond could easily 
provide both entrypoints as it used to, then the issue should be filed 
against LilyPond.

----

This is something I have not tested, but there are some indications that 
the subsystem of a Windows portable executable can be changed after it 
has been built.  There are two references to Perl modules that do this:

  https://metacpan.org/pod/Win32::Exe
  https://metacpan.org/dist/Tk/view/exetype

It sounds like you could manually copy lilypond.exe to 
lilypond-windows.exe and then change the copy's subsystem.  Not really a 
long-term solution, but it might help you keep auto-compilation as that 
really does sound like a useful workflow.


-- Aaron Hill