Support job control for Windows programs invoked under Bash (ctrl-c, ctrl-z support)

[robgssp]

It would be good to be able to use Bash job control (suspend/background/etc) in the context of Windows interop. It's currently partially supported under preview builds (can launch windows programs in the background, e.g. notepad.exe &), but once a windows program is started in the foreground you cannot suspend it with ^Z, and interrupting it with ^C transfers control back to bash but doesn't actually kill the Windows program, just detaches it.

I personally find it quite useful to be able to decide I want something backgrounded after I've launched it, and I'd like to be able to do that with e.g. MSBuild invocations.

[benhillis]

This is somewhat similar to #1574 although that issue only calls out control-c. Since this one is a bit more generic I'm going to close out the other issue and refer to this one.

[CherryDT]

For me this begs the question, though, whether it is really a good idea to make Ctrl+Z suspend a Windows process, in particular when it has any windows. It can cause a chain reaction which may hang multiple other applications this way, I think... at least this is what happened to me multiple times before (mostly during debugging sessions, though).

Yes, it may be the fault of other applications to wait infinitely for the responses of windows which don't belong to them, but it can be still very problematic. I remember that when I had this issue while I was using the input macro tool Breevy, I came into a state where almost none of the keys and mouse operations were working anymore until I somehow managed to kill Breevy using a lot of trickery because I couldn't afford restarting the computer at that point...

[aseering]

Please pardon my Windows naivety -- does there already exist a Windows equivalent of SIGSTOP (which I assume is how suspending a process is implemented)? What would the obvious (if any) mapping of this Linux functionality into Windows look like for the Windows application?

(What I'm really asking is, is there a Windows semantic equivalent that's common enough that most programs ought to mostly support it without blowing up too horribly? Suspending just one process in a cloud of Linux processes is problematic too, but usually you don't get yourself too deep into trouble by doing so.)

[CherryDT]

As far as I know, suspending a process is done just by calling SuspendProcess which suspends all threads. The issue I was trying to point out is that if the process in question wasn't designed for being suspended and has windows which are supposed to pump messages, other applications which naively send a message to such a window (may be even broadcast) and wait for the response can get stuck because of that.

It's probably an edge case when something like my situation described before happens, but I know it can happen.

I do believe though that pure console processes can be suspended and resumed just fine and will work as expected...

[poizan42]

Well that can happen on Linux as well if processes are doing any kind of synchronous ipc without timeout. But most normal communication between windows that aren't intimately connected are done with posted messages.

Though the fact that the windows of a suspended process can't be moved may also be somewhat annoying. I guess that usually when a process is suspended on windows it's because of it being debugged or some debug-like scenario like making a memory dump. Note that the only documented way to suspend a complete process, DebugActiveProcessStop, requires you to be debugging the process. The NtSuspendProcess function is undocumented.

For this to work well I think there would actually need to be some sort of support for processes being suspended for non-debugging purpose, which the window manager could use as a hint to show the windows somewhat like they are for non-responding processes, just with an indication that the process is suspended.

[crozone]

@poizan42 If a GUI application's message pump doesn't accept any input for a timeout period (or rather, the application doesn't call GetMessage or DispatchMessage), won't Windows just flag that process as "Not Responding" and ghost all of its active windows (unless the process happened to call DisableProcessWindowGhosting() - pretty unlikely). The user should still be able to move the Windows around, it'll just appear as if the program has crashed (here are some edge cases with active dialogue boxes too, but not a big deal).

[poizan42]

@crozone normally yes, but not if it's suspended. Try using e.g. ProcessHacker to suspend a process with a window and see what happens.