Sorry for the late reply, life …
Anyway…
The way I see it, you’re using a monitoring process for syncthing anyway, so you launch the monitor process that then launches syncthing. Where’s the problem in compiling those processes for Windows as a GUI application and for the other things you use a different executable that then offers the console option.
When someone runs syncthing --help you can just call another executable that was built with the console set and output the help from there. You could even build the binary twice, once with console and once with gui and depending on the switches of the starting process then start the console or the gui version.
You could use the syncthing.exe file as a gui binary that is used for routing the commands to the right binary and let it then launch the other binary that is needed.
I really don’t see the problem with this approach as these things are modules anyway and it’s not uncommon to have different build parameters for different platforms and multiple .exe files for different parts of a software suite. Putting everything into one .exe file on the other hand can create all kinds of problems, including the one we’re looking at now.
I also don’t think the Windows behavior is going to change, because when you put a flag in the header of your executable file format so that the LDR in your kernel knows which subsystem to initialize, you won’t remove the console requirement after 40 years all of a sudden.
The main issue here is that Windows is not meant to have programs running that output their information to stdout/err. Not even services should do that and that philosophy is not reflected in the Windows version of the file.
You either write something that sits as an icon in the information area of the taskbar (near the clock) that then syncs stuff in the background or you write it as a service that is then doing its job on a per user basis. But that logic needs to be included in the binary. Windows will not take care of that for you like systemd does on Linux.
The Syncthing Tray is a nice thing, but I don’t want another piece of software from another vendor. All I need is an icon in the taskbar, that opens the browser to the website when I doubleclick on it. The main issue I have with those 3rd party applications is that the developers loose their interest over time or something else happens and I’m out looking for a new software to fix an old problem once again.
This is sadly an issue the open sauce scene is suffering from for the last ten years were people develop new software w/o the commitment to support it and all of a sudden it just stops and that’s it, so I hope that the core project will not suffer that fate.
BTW: I built syncthing as GUI executable myself by using EXTRA_LDFLAGS and it worked like a charm. Only issue is that the binary isn’t signed and I have no incentive on creating my own private signing certificate. I don’t know if a self built binary is fully accepted in the network, so I’m not going to use it either.
KR,
G.