Session 'Onhold' feature

[wsy]

Description of the new feature/enhancement

I'm running some scripts with Windows Terminal (Windows App Store version).
I switched to some other app doing something else, and Windows Terminal got updated by Windows App Store.
After Windows Terminal opens again, every tab, every session, everything I was running was gone.
If Windows Terminal could have put those sessions in some sort of 'on-hold' state, and Windows Terminal would pick up those sessions again after it starts again, that would be great.

Proposed technical implementation details (optional)

I purpose that you may separate the concept 'session' from the concept 'window'/'Windows Terminal application'.
After decoupling these concepts, sessions run in standalone processes. When the application of Windows Terminal restarts, or maybe sometimes when it crashes, after we open Windows Terminal again, we may have our sessions back.
Those 'session' processes may have a timeout for maximum idle time. For example, if Windows Terminal quits with these sessions still running, after maybe 5 minutes, Windows Terminal did not connect to these sessions, then these sessions will quit themselves.

If you ever used iTerm on macOS, when sometimes it crashes, and I re-open iTerm within a very short time, everything can be restored. This is a good example of what I'm talking about.

[KalleOlaviNiemitalo]

Related issues:

• Enable Terminal to persist / restore instance settings #766 (restarting Windows Terminal should automatically open new sessions with the same profiles as last time).
• Feature Request - Restore closed tab #960 (closing a tab should keep the session alive so it can be reattached)
• Restore previously closed session's state (Buffer contents) #961 (restarting Windows Terminal should restore buffer contents and perhaps child processes)
• Please provide a way to delay updates #6726 (Windows Store should not update Windows Terminal without asking and cause it to lose sessions)

I think this would then be a combination of:

• Feature Request - Restore closed tab #960
• The ability to find and reattach the sessions even after the main Windows Terminal process has crashed and been restarted.
• Ensuring that updates from Windows Store leave the child processes running. Does Windows Store support leaving OpenConsole.exe of the previous version running across an upgrade?

In principle, condrv could allow detaching the console host process (conhost or openconsole) and later attaching a different one. That way, you could even upgrade OpenConsole.exe in an existing session. It would require:

• condrv would have to freeze the console I/O until a console host is attached again.
• condrv would have to support console IDs (perhaps LUID or GUID) so that the console host could attach to the correct console when restarting.
• OpenConsole would have to save the console modes to a file and restore them when restarting.

However, such a change would increase the attack surface in the kernel, so it would be safer to leave OpenConsole.exe running.

[DHowett]

@KalleOlaviNiemitalo Wow, this is absolutely comprehensive. Thank you.

We've also got #5000 tracking process model changes that might be required to pull something like this off. The main issue with keeping OpenConsole running is that it's also serviced as part of the store package so it wouldn't be particularly robust in the upgrade scenario.

This is really close to a request for a windows implementation of screen/tmux using ConPTY.

/dup #5000 #766 #960 ec.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[KalleOlaviNiemitalo]

I don't think those other issues cover the case where the main Windows Terminal process crashes and the user starts a new one and wants to attach the sessions to that. I haven't seen such crashes myself, though.

The main issue with keeping OpenConsole running is that it's also serviced as part of the store package so it wouldn't be particularly robust in the upgrade scenario.

The store platform installs each version of Windows Terminal to a different directory, doesn't it? So it would be able to leave the files of the previous version on disk as long as that version has processes running.

Or are you concerned that the new version of WindowsTerminal.exe would require features that the old version of OpenConsole.exe does not support?

Perhaps, a few years from now, Windows will include a conhost that has all the same features as OpenConsole, and Windows Terminal can just use that. Such a conhost might be easier to leave running across a Windows Terminal upgrade.