Please note that the screenshots will also need to be updated, but I'm leaving that for later (as I would like to spin up a Windows 11 VM in order to take them in a clean environment, but I won't be able to do it in a short time).

Screenshots have been added.

I'm with a Win11 installation up and running. I can continue the screenshots and Task Scheduler-related changes in #926.

@tomasz1986 i've made some image adjustments on rafaeloledo@97e8b97

i think you have access to it, since it's a fork

Summary

• users/windows-nssm-config.png fixed the single - to be -- and removed --no-console
• users/windows-startup-addressbar.png slightly larger
• users/windows-startup-createshortcut.png removed --no-console
• users/windows-startup-newshortcut.png updated image
• users/windows-taskschd-actions.png removed --no-console
• users/windows-taskschd-additional-actions.png updated image
• users/windows-taskschd-additional-conditions.png untranslated particle Rede to Network (PT)
• users/windows-taskschd-createtask.png updated image
• users/windows-taskschd-general.png different author
• users/windows-taskschd-settingstab.png updated image
• users/windows-taskschd-triggers-logon.png different author
• users/windows-taskschd-triggers-startup.png updated image

Thanks for the screenshots, I think in this specific PR including the ones that have --no-console removed is appropriate. How would you prefer to be recognised as the author of them? If I download and push them to the PR myself, the whole PR will still end up being authored by myself only.

You can just add a co-authored-by when merging.

You can just add a co-authored-by when merging.

This is sufficient.

The images that not get merged are out of scope of this PR, right? Sorry for that. 🤗

With the advent of Windows Terminal and it being the default shell both
in newer releases of Windows 10, and in Windows 11, the --no-console
command line switch no longer works.

It still works with Run: Minimized

I've tested here with .lnk and it's working. It's even possible to run them with .cmd/.bat.

The behavior is: when using Normal Window, it runs with Windows Terminal, when using Minimized, it runs with conhost.

@tomasz1986 so, we may instruct the user to run wrapped on a .lnk?

Edit 1: Tested Start-Process -WindowStyle Minimized and the behavior is not the same of .lnk Minimized, it keeps calling Windows Terminal no matter the -WindowStyle
Edit 2: Only double-clicking on the .lnk will make it not pop the Windows Terminal. I've tested wrapping the lnk on a .bat file with @echo off, it still opens a flash of wt.exe.

So, indeed the .lnk solution is working. But it has limitations and not solve the problem entirely. The thing is that Windows Terminal is being set as the new default for console applications. The --no-console solution was built in a context that is not the Windows 11 way. It's natural to be considered deprecated.

Even if we advertise the user to use .lnk, it only not pops the terminal if he manually clicks on the icon, which i think is not desired.

@tomasz1986 I've been studying Windows a bit those last days. Since Windows NT, Microsoft launched the sc.exe API to create services, which is different from tasks. It's a bit confusing here.

What i can explain here is, creating a service, a real service and not a task, it can execute syncthing.exe without calling Windows Terminal.

But, it doesn't require the user to click every time.

I've analyzed the sc.exe call stack and it uses conhost with already a "hidden" behavior to trigger execution.

So, in my early PRs i've suggested the schtasks. But for this demand of not showing the console, it can be accomplished only with this API.

The only problem i found is when i run the service manually, it can not be controlled by the internal Manager. But it does not block the execution despite of not being able to communicate with the syncthing thread.

:: create service
sc.exe create syncthing binPath="<path-to-syncthing.exe> --no-browser" start=auto DisplayName="syncthing"
:: delete service
sc.exe delete syncthing
:: start service
sc.exe start syncthing

Then, following Ockham's Razor, my suggestion is removing --no-console flag from docs at least since it's not well supported now. Finally, we can tell the user to create services as above. The problem is that syncthing is not implementing communication with Windows Services Control API, so it can't be stopped by the manager, requiring the user to kill the program with Task Manager.

taskkill /IM "syncthing.exe" /F

Currently working on implementing Windows Service API. Finishing in the next days.

https://github.com/rafaeloledo/syncthing