feat(build, syncthing): dynamic console allocation for Windows

[Shablone]

Dynamic Console Allocation for Windows

Purpose

Windows GUI builds either always show a short console pupup on windows systemstart implementation or never show one (CLI users can't see output). See PR10334 , PR926 and many more

Solution

Implement dynamic console allocation:

• No console when double-clicked from Explorer
• Console appears when launched with CLI arguments
• --no-console flag to explicitly disable console
• Console behavior preserved across monitor restarts

Testing

syncthing.exe              # No console (GUI)
syncthing.exe --help       # Shows console + help
syncthing.exe --no-console # No console even with args

Opening from explorer won't show a console.

Implementation

• Uses Windows API (AllocConsole/AttachConsole) to create console on demand
• Monitor process passes --no-console to child processes when appropriate
• Windows-only using build constraints

Fixes console window appearing briefly when launched from Explorer while maintaining proper CLI functionality.

Authorship

• Name: Elias @shablone
• Email: [email protected]

[rafaeloledo]

Did you have success running it?

[rasa]

One issue with this is if a user runs this GUI version from inside an SSH session, they won't see any output. The console window will appear on the desktop.

[Shablone]

Thank you for the review :) I will rework that changes accordingly.

I was reinventing the stuff because

• It was late
• I'm not familiar with Go
• I didn't get familiar with the remaining codebase Sorry for that

I will also investigate the ssh session. Although it seems very niche to me, to ssh into a windows server.

[calmh]

I think the SSH bit is indeed extremely niche, but probably follows the same scenario as just running the command in an existing cmd? At least the latter should work, imho. (by which I mean "show output in that terminal")

[calmh]

This seems somewhat promising. I'll have comments on the actual code and stuff at some point, but just some behavioural notes;

• When doubleclicking syncthing.exe from explorer, there is a console flash but it disappears. That's good, but even better if it were possible to avoid the flash? If not, no biggie, it's already at the same level as the old --no-console was while it worked.

• This is possibly an extension for a future PR but, currently, if Syncthing is already running and is then doubleclicked again, visually nothing happens (except the flash as above). I think it would be nice and make sense if it resulted in the equivalent of synchthing.exe browser, i.e. start the UI. (Perhaps that's not on you and should just be the default behavior when launching Syncthing a second time under any platform and circumstance. Something to think about.)

[Shablone]

I noticed that syncthing not only was starting in console mode, it also opened the browser at runtime via calling cmd.exe resulting in another flash if no console was present yet. I included the fix here I haven't checked, but I guess this was the reason for your mentioned scenario @calmh

[Shablone]

Hey I'm not sure if I just need to be patient, but is there anything missing for a merge?

[tomasz1986]

I'm trying to test the PR right now, but for me, even when launched from Explorer, the console window just stays open.

This is under Windows 10 x64, and the default shell is set to Command Prompt.

[Shablone]

I'm trying to test the PR right now, but for me, even when launched from Explorer, the console window just stays open.

This is under Windows 10 x64, and the default shell is set to Command Prompt.

This is very strange. I just tried it again myself and also had the console window stay open. I believe that this wasn't the case when I pushed my last commit. I pulled every change from upstream and build it again. After that it worked as intended again. I'm not smart enough yet to understand why this is. Do you have any idea? I probably need to check the auto-upgrade functionality for any conflicts here

[Shablone]

I now understand the issue with the console that stays open. It seems it eally is the autoupgrade. Running a build with a current rebase is fine. Running a build

• rebased on an old commit eg 2.0.4, with STNOUPGRADE set, is fine
• rebased on an old commit eg 2.0.4, with STNOUPGRADE not set, shows this console, which stays open

If the build with this Dynamic Console Allocation is older then the online build, it will autograde to the online one, which doesn't have Dynamic Console Allocation yet and starts with non-gui-mode, allocating a console again.

Now I ask you: -Do you agree -Does this actually need fixing? I probably need to stay up-to-date on upstream with that PR, so testing does work as intended

[Shablone]

Alright. Please have another look

I now splitted the console initialization into attachment (Already on present) and allocation (a new one needed). Relying on Kong would otherwise be very complex. The console handle should already be there if --help was passed or some invalid arguments. Unfortunately both don't reach Kongs AfterApply(). I also can't use the other hooks of kong, as they wouldn't have parsed the arguments yet. But I like the new approach better then the manual flag check. So now I always try to to attach to a console if present. Then we can parse the arguments and only create a new console if needed.

I also tested the ssh stuff. With the current commit when I ssh from unix into windows and call synthing.exe, it will pipe the output to my ssh shell. No new console appears 👍

I also learned that FreeConsole() is not needed, as windows this stuff on its own on process termination. So I could delete the defering stuff

I removed the old HideConsole and replaced it with the dynamic allowcation

[Shablone]

Please keep in mind, that for testing there should be no newer version online, which does not have this feature implemented. Or auto-upgrade should be disabled. Otherwise it will upgrade itself and run as console again

[Shablone]

Thanks, sorry for taking some time on this, I do want to get it in. Can you sort out the various style/linter complaints please, and then I think this is ready given it passes some manual testing 🙏

Thank you. There is no hurry 🙂

[calmh]

Actual Windows users who want this, can we have some testing? 🙏