Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminal window/tab is not closed when console application calls FreeConsole #14416

Closed
Tracked by #13392
edo9300 opened this issue Nov 20, 2022 · 4 comments · Fixed by #14544
Closed
Tracked by #13392

Terminal window/tab is not closed when console application calls FreeConsole #14416

edo9300 opened this issue Nov 20, 2022 · 4 comments · Fixed by #14544
Assignees
Labels
Area-DefApp Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@edo9300
Copy link

edo9300 commented Nov 20, 2022

Windows Terminal version

No response

Windows build number

No response

Other Software

No response

Steps to reproduce

On windows 11, with the windows terminal being set as the default console application, start a program that was compiled for the console subsystem from explorer.
That program calls FreeConsole during its lifetime and then keeps running (either because it has spawned a gui or it is still has work to do).

Expected Behavior

The console window that got spawned by that program is closed as it did with cmd on previous windows versions.

Actual Behavior

The console window stays open until the program terminates the execution.

@edo9300 edo9300 added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Nov 20, 2022
@edo9300
Copy link
Author

edo9300 commented Nov 20, 2022

I've looked at other similar issues on this repository, but all of them are related to the program manually working on the console window HANDLE that as said various times was a deprecated behaviour, for FreeConsole instead there's no such deprecation notice, and as the docs says A console is closed when the last process attached to it terminates or calls FreeConsole., which is the behaviour I expect as only my program should be attached to that console. (That is also emphasized by the fact that when the program terminates then the console closes as well, and that indicates that there are no other programs attached to it.)

@lhecker lhecker added Product-Terminal The new Windows Terminal. Area-DefApp labels Nov 21, 2022
@lhecker
Copy link
Member

lhecker commented Nov 21, 2022

We could make this work by removing ConPTY's \Reference handle from the ConsoleProcessList after starting OpenConsole, if OpenConsole was started as part of a handoff.

BTW if you're using FreeConsole to hide the console conditionally as part of your startup, I personally believe a better option might be to go with AttachConsole(ATTACH_PARENT_PROCESS) and reopen stdout/stdin. I haven't tested it, but it should look something like this:

// Compile with /SUBSYSTEM:WINDOWS!
if (!AttachConsole(ATTACH_PARENT_PROCESS)) {
    AllocConsole();
}

FILE* stdinNew = nullptr;
freopen_s(&stdinNew, "CONIN$", "r+", stdin);
FILE* stdoutNew = nullptr;
freopen_s(&stdoutNew, "CONOUT$", "w+", stdout);
FILE* stderrNew = nullptr;
freopen_s(&stderrNew, "CONOUT$", "w+", stderr);

printf("Hello, World!\n");

@edo9300
Copy link
Author

edo9300 commented Nov 21, 2022

BTW if you're using FreeConsole to hide the console conditionally as part of your startup

Yes, I'm doing that but because before my program reads its configs from which the console can be disabled, it has already printed some debug information that would not be there if I created the console afterwards (this is where I'm doing that call, by that time the console has already debug Info from its libraries printed to the console https://github.com/edo9300/edopro/blob/bce9989dbf6f497d1b5f3c009f4b6328d80e9201/gframe/gframe.cpp#L223), so I can't create the console afterwards.

@edo9300 edo9300 closed this as completed Nov 21, 2022
@edo9300 edo9300 reopened this Nov 21, 2022
@lhecker lhecker self-assigned this Nov 30, 2022
@ghost ghost added the In-PR This issue has a related PR label Dec 14, 2022
@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Dec 15, 2022
@ghost ghost closed this as completed in #14544 Dec 16, 2022
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Dec 16, 2022
ghost pushed a commit that referenced this issue Dec 16, 2022
2 new ConPTY APIs were added as part of this commit:
* `ClosePseudoConsoleTimeout`
  Complements `ClosePseudoConsole`, allowing users to override the `INFINITE`
  wait for OpenConsole to exit with any arbitrary timeout, including 0.
* `ConptyReleasePseudoConsole`
  This releases the `\Reference` handle held by the `HPCON`. While it makes
  launching further PTY clients via `PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE`
  impossible, it does allow conhost/OpenConsole to exit naturally once all
  console clients have disconnected. This makes it unnecessary to having to
  monitor the exit of the spawned shell/application, just to then call
  `ClosePseudoConsole`, while carefully continuing to read from the output
  pipe. Instead users can now just read from the output pipe until it is
  closed, knowing for sure that no more data will come or clients connect.
  This is especially useful in combination with `ClosePseudoConsoleTimeout`
  and a timeout of 0, to allow conhost/OpenConsole to exit asynchronously.

These new APIs are used to fix an array of bugs around Windows Terminal exiting
either too early or too late. They also make usage of the ConPTY API simpler in
most situations (when spawning a single application and waiting for it to exit).

Depends on #13882, #14041, #14160, #14282

Closes #4564
Closes #14416
Closes MSFT-42244182

## Validation Steps Performed
* Calling `FreeConsole` in a handoff'd application closes the tab ✅
* Create a .bat file containing only `start /B cmd.exe`.
  If WT stable is the default terminal the tab closes instantly ✅
  With these changes included the tab stays open with a cmd.exe prompt ✅
* New ConPTY tests ✅
@ghost
Copy link

ghost commented Jan 24, 2023

🎉This issue was addressed in #14544, which has now been successfully released as Windows Terminal Preview v1.17.1023.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-DefApp Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants