On 2023-04-03 10:31 am, Jean Abou Samra wrote:
Le 3 avr. 2023 à 12:21, Richard Shann <rich...@rshann.plus.com> a
écrit :
Is there any chance the developers might re-instate the
lilypond-windows.exe?
Maybe. Is it as easy as compiling with -mconsole ? Does that have other
effects to take care of? Is there a use case where the current mode is
important or could we just switch to the other mode?
LilyPond would still need to be able to be run purely from the terminal,
so the main target should continue to use the console subsystem. This
importantly covers the scenarios of scripting and automation where you
need standard I/O to be mapped properly.
The use case for a third-party GUI application running LilyPond
behind-the-scenes is where the "windows" subsystem could be useful,
providing the application is unable to spawn the child process in a
hidden manner.
This goes to my question of which application has the real problem.
Denemo relied on LilyPond providing two entrypoints, so it was not
really at fault. But Denemo probably should have been spawning the
worker process hidden to begin with, thus never relying on
lilypond-windows.exe in the first place. However, that would require
working around glib to use the Win32 API directly (and adding
platform-specific development overhead), or by getting the glib
developers to expose the underlying process creation flag. But for all
I know, it might be out-of-scope for glib to support this scenario, thus
pushing the work back to Denemo.
It should be noted that this dual subsystem approach is very common on
Windows. Take the Windows scripting host itself. It comes in two
flavors: wscript.exe and cscript.exe. The first is for use without an
attached terminal, and the second is meant to be run from the
command-line. Java likewise has always shipped with two frontends:
java.exe and javaw.exe. So, LilyPond would not be doing anything
unusual by shipping two executables.
-- Aaron Hill
