starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Integration issues with Unity (Running in batchmode/console mode) #13193

New Issue
Closed
opened 2026-01-31 03:36:16 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 03:36:16 +00:00
Owner
Copy Link

Originally created by @ghost on GitHub (Mar 25, 2021).

Originally assigned to: @DHowett on GitHub.

Windows Terminal version (or Windows build number)

1.7.572.0 (Preview)

Other Software

Unity 2020.2.1f1
gui.cs/Terminal.Gui (https://github.com/migueldeicaza/gui.cs)
My app (https://github.com/EternalClickbait/Team-Defense)

Steps to reproduce

  1. Build and run the app (Team-Defense) using the parameters "-nographics -batchmode"
  2. Observe that when running from Command Prompt or PowerShell, the app attaches to the console normally and works as expected.
Initializing Better Windows Console
Attempting to attach to parent process's console
Attached to parent process's console
  1. Observe that when running from Windows Terminal, the app fails to attach with error code 6
Attempting to attach to parent process's console
Failed to attach to parent process's console (Error 6)
Allocating new console
  1. Running command prompt first and using it to run the app (cmd /c Team-Defense.exe -nographics -batchmode) allows the app to attach successfully and display in the Terminal
Initializing Better Windows Console
Attempting to attach to parent process's console
Attached to parent process's console

Expected Behavior

The app always attaches to the process without having to use Command Prompt (cmd.exe) as a "man in the middle"

Actual Behavior

The app is unable to attach to the Windows Terminal app, returning ERROR_INVALID_HANDLE (6), meaning "the specified process does not have a console". I have tried using a combination of a debugger and Task Manager to manually attach to the Windows Terminal processes, but all of them fail with ERROR_INVALID_HANDLE.

Originally created by @ghost on GitHub (Mar 25, 2021). Originally assigned to: @DHowett on GitHub. ### Windows Terminal version (or Windows build number) 1.7.572.0 (Preview) ### Other Software Unity 2020.2.1f1 gui.cs/Terminal.Gui (https://github.com/migueldeicaza/gui.cs) My app (https://github.com/EternalClickbait/Team-Defense) ### Steps to reproduce 1. Build and run the app (Team-Defense) using the parameters "-nographics -batchmode" 2. Observe that when running from Command Prompt or PowerShell, the app attaches to the console normally and works as expected. ``` Initializing Better Windows Console Attempting to attach to parent process's console Attached to parent process's console ``` 3. Observe that when running from Windows Terminal, the app fails to attach with error code 6 ``` Attempting to attach to parent process's console Failed to attach to parent process's console (Error 6) Allocating new console ``` 4. Running command prompt first and using it to run the app (`cmd /c Team-Defense.exe -nographics -batchmode`) allows the app to attach successfully and display in the Terminal ``` Initializing Better Windows Console Attempting to attach to parent process's console Attached to parent process's console ``` ### Expected Behavior The app always attaches to the process without having to use Command Prompt (`cmd.exe`) as a "man in the middle" ### Actual Behavior The app is unable to attach to the Windows Terminal app, returning ERROR_INVALID_HANDLE (6), meaning "the specified process does not have a console". I have tried using a combination of a debugger and Task Manager to manually attach to the Windows Terminal processes, but all of them fail with ERROR_INVALID_HANDLE.
claunia added the Needs-TriageNeeds-Tag-Fix labels 2026-01-31 03:36:16 +00:00
claunia commented 2026-01-31 03:36:17 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 26, 2021):

This application is attempting to do something that is unsupported. The developers may need to be reprimanded for “attaching to the parent process console.” The console that they are spawned with is perfectly acceptable, and they are looking for trouble by walking up the process tree.

Terminal hosts console processes just like the actual inbox console hosts console processes, with some minor non-contractual process tree things changed (*which aren’t unique to Terminal; any consumer of the ConPTY API like vim, Cygwin 3.1+, and VSCode are subject to the same restriction).

When an application gets caught, well..

You know the old adage: “you break it, you buy it”? 😄

@DHowett commented on GitHub (Mar 26, 2021): This application is attempting to do something that is unsupported. The developers may need to be reprimanded for “attaching to the parent process console.” The console that they are spawned with is perfectly acceptable, and they are looking for trouble by walking up the process tree. Terminal hosts console processes just like _the actual inbox console_ hosts console processes, with some minor non-contractual process tree things changed (*which aren’t unique to Terminal; any consumer of the ConPTY API like vim, Cygwin 3.1+, and VSCode are subject to the same restriction). When an application gets caught, well.. You know the old adage: “you break it, you buy it”? 😄
claunia commented 2026-01-31 03:36:17 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 26, 2021):

(@EternalClickbait I’m not necessarily blaming you- there’s a host of libraries that are part of Unity and GUI.cs that might pose an issue or be doing something weird. The first place to look would be the code producing the “Initializing Better Windows Console” message! That part seems quite suspect, as we only usually see stuff like that from unusual and unsupported hooking libraries.)

@DHowett commented on GitHub (Mar 26, 2021): (@EternalClickbait I’m not necessarily blaming you- there’s a host of libraries that are part of Unity and GUI.cs that might pose an issue or be doing something weird. The first place to look would be the code producing the “Initializing Better Windows Console” message! That part seems quite suspect, as we only usually see stuff like that from unusual and unsupported hooking libraries.)
claunia commented 2026-01-31 03:36:17 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 26, 2021):

Once I’m at my desk tomorrow I’ll explain a bit about the terminal’s process structure (and that of VSCode and conpty!)

@DHowett commented on GitHub (Mar 26, 2021): Once I’m at my desk tomorrow I’ll explain a bit about the terminal’s process structure (and that of VSCode and conpty!)
claunia commented 2026-01-31 03:36:17 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 26, 2021):

(@EternalClickbait I’m not necessarily blaming you- there’s a host of libraries that are part of Unity and GUI.cs that might pose an issue or be doing something weird. The first place to look would be the code producing the “Initializing Better Windows Console” message! That part seems quite suspect, as we only usually see stuff like that from unusual and unsupported hooking libraries.)

That's my code :)

If you want, here's the important bits:

internal BetterWindowsConsole(string consoleTitle)
{
	//Free our old console just in case
	FreeConsole();

	//Try to attach to the parent process. Useful when using the internal console in Rider for debugging
	Logger.LogDelayedMessage("Attempting to attach to parent process's console", LogEventLevel.Verbose);
	//Try to attach a console to the parent (i think?)
	bool attachedToParent = AttachConsole(-1);
	//Didn't attach to parent, going to have to make a new one
	Logger.LogDelayedMessage(attachedToParent ? "Attached to parent process's console" : $"Failed to attach to parent process's console (Error {GetLastWin32Error()})", LogEventLevel.Verbose);
			
	//Try create a new console if we couldn't attach to the parent process
	if (!attachedToParent)
	{
		Logger.LogDelayedMessage("Allocating new console", LogEventLevel.Verbose);
		bool success = AllocConsole();
		if (!success) Logger.LogDelayedMessage("Could not allocate console (Error {GetLastWin32Error()})s", LogEventLevel.Warning);
	}

	//Set the title, color, etc
	SetConsoleTitle(consoleTitle);
	System.Console.Clear();
	System.Console.SetOut(new StreamWriter(System.Console.OpenStandardOutput()) {AutoFlush = true});
	System.Console.SetIn(new StreamReader(System.Console.OpenStandardInput()));
	Logger.LogDelayedMessage("Initialized new better windows console", LogEventLevel.Debug);
        System.Console.OutputEncoding = Encoding.UTF8;
        
        // =====Other unimportant code here=====
}

And I know what you mean that it's probably some other library, but I'm attempting to directly use the Win32 kernel functions and I'm unable to get it to work. The main problem I see is that I am unable to find a process to attach the console to, and since Unity is normally a GUI application, by default there is no console (Running in batchmode/server mode will act as if the app is a windows service). If I don't call AllocConsole or AttachConsole, the whole thing breaks because I'm trying to access a non-existent, non-initialized console.

@ghost commented on GitHub (Mar 26, 2021): > > > (@EternalClickbait I’m not necessarily blaming you- there’s a host of libraries that are part of Unity and GUI.cs that might pose an issue or be doing something weird. The first place to look would be the code producing the “Initializing Better Windows Console” message! That part seems quite suspect, as we only usually see stuff like that from unusual and unsupported hooking libraries.) That's my code :) If you want, here's the important bits: ```csharp internal BetterWindowsConsole(string consoleTitle) { //Free our old console just in case FreeConsole(); //Try to attach to the parent process. Useful when using the internal console in Rider for debugging Logger.LogDelayedMessage("Attempting to attach to parent process's console", LogEventLevel.Verbose); //Try to attach a console to the parent (i think?) bool attachedToParent = AttachConsole(-1); //Didn't attach to parent, going to have to make a new one Logger.LogDelayedMessage(attachedToParent ? "Attached to parent process's console" : $"Failed to attach to parent process's console (Error {GetLastWin32Error()})", LogEventLevel.Verbose); //Try create a new console if we couldn't attach to the parent process if (!attachedToParent) { Logger.LogDelayedMessage("Allocating new console", LogEventLevel.Verbose); bool success = AllocConsole(); if (!success) Logger.LogDelayedMessage("Could not allocate console (Error {GetLastWin32Error()})s", LogEventLevel.Warning); } //Set the title, color, etc SetConsoleTitle(consoleTitle); System.Console.Clear(); System.Console.SetOut(new StreamWriter(System.Console.OpenStandardOutput()) {AutoFlush = true}); System.Console.SetIn(new StreamReader(System.Console.OpenStandardInput())); Logger.LogDelayedMessage("Initialized new better windows console", LogEventLevel.Debug); System.Console.OutputEncoding = Encoding.UTF8; // =====Other unimportant code here===== } ``` And I know what you mean that it's probably some other library, but I'm attempting to directly use the Win32 kernel functions and I'm unable to get it to work. The main problem I see is that I am unable to find a process to attach the console to, and since Unity is normally a GUI application, by default there is no console (Running in batchmode/server mode will act as if the app is a windows service). If I don't call `AllocConsole` or `AttachConsole`, the whole thing breaks because I'm trying to access a non-existent, non-initialized console.
claunia commented 2026-01-31 03:36:18 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 26, 2021):

I believe missed this section here, so please let me explain @DHowett

This application is attempting to do something that is unsupported. The developers may need to be reprimanded for “attaching to the parent process console.” The console that they are spawned with is perfectly acceptable, and they are looking for trouble by walking up the process tree.

I'm afraid that simply isn't the case here. The application does not have it's own console. It's a Unity (GUI) application, and so it would normally create it's own window etc as GUI apps normally do. However, I would like to have it be able to run as a server, which means no GUI, no GPU or graphics, just CPU. To do this I pass in "-batchmode -nographics" as command line arguments to the .exe (this is standard, supported, even recommended behavior). When I do so, Unity does not spawn any windows, meaning that the process is essentially invisible, and (at least on windows), running as a background process, which means I have essentially no way of interacting with it. So, I decided to add a console to it, so that I could interact with and monitor my game as it was running.

Herein lies the problem - as the .exe is a "GUI application", it doesn't have a console it spawned with. Not that the console was deallocated/removed, but it never existed in the first place. This means that if I want to use the System.Console class, I have to somehow give it a console to write to. If say I run the app from command line, I don't want it to create a whole new window for the console, so I just attach it to the parent process (AttachConsole(-1)), which works perfectly fine. I'm not actually "walking up the process tree", I'm just telling windows "Hey, can you attach me to the console of the process that spawned me?" (Without telling windows exactly which process), which I believe is supported behaviour.

I don't know how cmd manages to work fine when spawned in the Terminal and my app oesn't, but the fact that my app only doesn't work in Terminal and works fine everywhere else makes it seem highly unlikely that it's due to something I've done (not blaming you though). I would appreciate it if you could get back to me as soon as possible @DHowett so we can fix this issue.

@ghost commented on GitHub (Mar 26, 2021): I believe missed this section here, so please let me explain @DHowett > This application is attempting to do something that is unsupported. The developers may need to be reprimanded for “attaching to the parent process console.” The console that they are spawned with is perfectly acceptable, and they are looking for trouble by walking up the process tree. I'm afraid that simply isn't the case here. The application ***does not have it's own console***. It's a Unity (GUI) application, and so it would normally create it's own window etc as GUI apps normally do. However, I would like to have it be able to run as a server, which means no GUI, no GPU or graphics, just CPU. To do this I pass in `"-batchmode -nographics"` as command line arguments to the `.exe` (this is standard, supported, even *recommended* behavior). When I do so, Unity does not spawn any windows, meaning that the process is essentially invisible, and (at least on windows), running as a background process, which means I have essentially no way of interacting with it. So, I decided to add a console to it, so that I could interact with and monitor my game as it was running. Herein lies the problem - as the `.exe` is a "GUI application", it ***doesn't have a console it spawned with***. Not that the console was deallocated/removed, but it never existed in the first place. This means that if I want to use the `System.Console` class, I have to somehow give it a console to write to. If say I run the app from command line, I don't want it to create a whole new window for the console, so I just attach it to the parent process (`AttachConsole(-1)`), which works perfectly fine. I'm not actually "walking up the process tree", I'm just telling windows "Hey, can you attach me to the console of the process that spawned me?" (Without telling windows exactly which process), which I believe is supported behaviour. I don't know how `cmd` manages to work fine when spawned in the Terminal and my app oesn't, but the fact that my app only doesn't work in Terminal and works fine everywhere else makes it seem highly unlikely that it's due to something I've done (not blaming you though). I would appreciate it if you could get back to me as soon as possible @DHowett so we can fix this issue.
claunia commented 2026-01-31 03:36:18 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 30, 2021):

Hey @DHowett I've updated my comments so they're more accurate and explained a few more things, so you might want re-read them. I would really love for you to explain the terminal process's structure so I can better understand it as well.

@ghost commented on GitHub (Mar 30, 2021): Hey @DHowett I've updated my comments so they're more accurate and explained a few more things, so you might want re-read them. I would really love for you to explain the terminal process's structure so I can better understand it as well.
claunia commented 2026-01-31 03:36:18 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 30, 2021):

Alright, so as you've noted, there's a difference between running GUI and commandline applications on windows. We tend to call GUI applications "SUBSYSTEM=WINDOWS" applications, and commandline apps are "SUBSYSTEM=CONSOLE". Console subsystem apps must always have a conhost - if they were spawned and the parent was a console app, then they'll inherit the console from their parent. If they're spawned without one, the system will make one for them. As you've noted, WINDOWS subsystem applications don't need a console. They aren't spawned with one, and they won't inherit the parent's automatically.

There's one weird thing about running Windows subsystem apps from shells like cmd.exe and powershell. These shells are smart enough to know that Windows applications won't be using the console, so they immediately return to the prompt.

That might all just be irrelevant background info though..

when running from Windows Terminal, the app fails to attach with error code 6

Just to make sure, are you setting Team-Defense.exe -nographics -batchmode as the commandline for a profile in the Terminal, or are you running a shell first, then running that commandline from the shell?

Technically, if you're doing the first, then windowsterminal.exe is the parent process for your Team-Defense.exe, and windowsterminal.exe doesn't have a console. It's also a Windows subsystem application. When you're running Team-Defense.exe from powershell, cmd, or using cmd /c Team-Defense.exe..., then the parent process is powershell or cmd, and those do have a console.

@zadjii-msft commented on GitHub (Mar 30, 2021): Alright, so as you've noted, there's a difference between running GUI and commandline applications on windows. We tend to call GUI applications "SUBSYSTEM=WINDOWS" applications, and commandline apps are "SUBSYSTEM=CONSOLE". Console subsystem apps must always have a conhost - if they were spawned and the parent was a console app, then they'll inherit the console from their parent. If they're spawned without one, the system will _make one for them_. As you've noted, WINDOWS subsystem applications _don't_ need a console. They aren't spawned with one, and they won't inherit the parent's automatically. There's _one weird thing_ about running Windows subsystem apps from shells like `cmd.exe` and `powershell`. These shells are smart enough to know that Windows applications won't be using the console, so they _immediately_ return to the prompt. That might all just be irrelevant background info though.. <hr> > when running from Windows Terminal, the app fails to attach with error code 6 Just to make sure, are you setting `Team-Defense.exe -nographics -batchmode` as the `commandline` for a profile in the Terminal, or are you running a shell first, then running that commandline from the shell? Technically, if you're doing the first, then `windowsterminal.exe` is the parent process for your `Team-Defense.exe`, and `windowsterminal.exe` _doesn't have a console_. It's _also_ a Windows subsystem application. When you're running `Team-Defense.exe` from powershell, cmd, or using `cmd /c Team-Defense.exe...`, then the parent process is `powershell` or `cmd`, and those _do_ have a console.
claunia commented 2026-01-31 03:36:18 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Mar 30, 2021):

Console subsystem apps must always have a conhost

Unless they're spawned with the DETACHED_PROCESS creation flag. With this flag, it may be necessary to also override the standard handles to use the "NUL" device or pipes. Even with that, console applications will fail if they require a console session.

if they were spawned and the parent was a console app, then they'll inherit the console from their parent.

Unless they're spawned with either the CREATE_NEW_CONSOLE or CREATE_NO_WINDOW creation flag. CMD's START command and ShellExecuteExW default to using CREATE_NEW_CONSOLE.

Here's another aspect of how the system supports console applications: if a console application inherits the parent's console session and handle inheritance is disabled, the system automatically duplicates the parent's standard handles to the child process. It's not inheritance, so the handle values are different. But it's only meant to support using GetStdHandle(), so the handle values don't matter. It also doesn't matter whether they're handles for console files or redirected to pipes, etc.

@eryksun commented on GitHub (Mar 30, 2021): > Console subsystem apps must always have a conhost Unless they're spawned with the `DETACHED_PROCESS` creation flag. With this flag, it may be necessary to also override the standard handles to use the "NUL" device or pipes. Even with that, console applications will fail if they require a console session. > if they were spawned and the parent was a console app, then they'll inherit the console from their parent. Unless they're spawned with either the `CREATE_NEW_CONSOLE` or `CREATE_NO_WINDOW` creation flag. CMD's `START` command and `ShellExecuteExW` default to using `CREATE_NEW_CONSOLE`. Here's another aspect of how the system supports console applications: if a console application inherits the parent's console session and handle inheritance is disabled, the system automatically duplicates the parent's standard handles to the child process. It's not inheritance, so the handle values are different. But it's only meant to support using `GetStdHandle()`, so the handle values don't matter. It also doesn't matter whether they're handles for console files or redirected to pipes, etc.
claunia commented 2026-01-31 03:36:18 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 31, 2021):

Just to make sure, are you setting Team-Defense.exe -nographics -batchmode as the commandline for a profile in the Terminal, or are you running a shell first, then running that commandline from the shell?

I've tried both. When I run the exe directly as a profile (C:\XXXXX\Builds\Team-Defense-Quick\Team-Defense.exe -nographics -batchmode) My exe is unable to find a console to 'attach' to and has to resort to allocating a new one (Using Kernel32 AllocConsole()). My workaround is to run cmd first with the /c parameter (cmd /c C:\XXXXX\Builds\Team-Defense-Quick\Team-Defense.exe -nographics -batchmode for the profile command line). This allows me to attach to the cmd process, and I'm able use the console as normal:
image

Technically, if you're doing the first, then windowsterminal.exe is the parent process for your Team-Defense.exe, and windowsterminal.exe doesn't have a console. It's also a Windows subsystem application. When you're running Team-Defense.exe from powershell, cmd, or using cmd /c Team-Defense.exe..., then the parent process is powershell or cmd, and those do have a console.

This makes more sense to me and explains why running cmd first works, but I still don't understand how Windows Terminal manages to somehow intercept the output (buffer?) from cmd and powershell. All I need is to somehow emulate whatever they're doing, but I don't know what or how they're doing it.

@ghost commented on GitHub (Mar 31, 2021): > Just to make sure, are you setting Team-Defense.exe -nographics -batchmode as the commandline for a profile in the Terminal, or are you running a shell first, then running that commandline from the shell? I've tried both. When I run the exe directly as a profile (`C:\XXXXX\Builds\Team-Defense-Quick\Team-Defense.exe -nographics -batchmode`) My exe is unable to find a console to 'attach' to and has to resort to allocating a new one (Using Kernel32 `AllocConsole()`). My workaround is to run `cmd` first with the `/c` parameter (`cmd /c C:\XXXXX\Builds\Team-Defense-Quick\Team-Defense.exe -nographics -batchmode` for the profile command line). This allows me to attach to the `cmd` process, and I'm able use the console as normal: ![image](https://user-images.githubusercontent.com/48875125/113080275-fd832480-9219-11eb-8a4c-db68d8fe24fd.png) > Technically, if you're doing the first, then windowsterminal.exe is the parent process for your Team-Defense.exe, and windowsterminal.exe doesn't have a console. It's also a Windows subsystem application. When you're running Team-Defense.exe from powershell, cmd, or using cmd /c Team-Defense.exe..., then the parent process is powershell or cmd, and those do have a console. This makes more sense to me and explains why running `cmd` first works, but I still don't understand how Windows Terminal manages to somehow intercept the output (buffer?) from `cmd` and `powershell`. All I need is to somehow emulate whatever they're doing, but I don't know what or how they're doing it.
claunia commented 2026-01-31 03:36:19 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 6, 2021):

Ok @zadjii-msft I've done some research and from my understanding, when I launch my app from the terminal app directly, the Windows Terminal has no console, so my app can't attach to one. However, if I run a shell first (like cmd or powershell), then the shell (which is now also the parent process does have a console, which my app then happily attaches to. If I'm correct, all I need to do is somehow 'create' a console for my app to use, and then somehow get Windows Terminal to somehow read/connect to that console. This is just a guess, but would starting processes with the CREATE_NEW_CONSOLE flag work?

@ghost commented on GitHub (Apr 6, 2021): Ok @zadjii-msft I've done some research and from my understanding, when I launch my app from the terminal app directly, the Windows Terminal has no console, so my app can't attach to one. However, if I run a shell first (like `cmd` or `powershell`), then the shell (which is now also the parent process *does* have a console, which my app then happily attaches to. If I'm correct, all I need to do is somehow 'create' a console for my app to use, and then somehow get Windows Terminal to somehow read/connect to that console. This is just a guess, but would starting processes with the `CREATE_NEW_CONSOLE` flag work?
claunia commented 2026-01-31 03:36:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 6, 2021):

I mean, in my opinion, the easiest way to handle this would be to just use a commandline of cmd.exe /k Team-Defense.exe ... in your profile. If you use CREATE_NEW_CONSOLE, I'm pretty confident that that will end up spawning en entirely new console window.

Or if you're really determined, you could just make another "shim" executable that's something like Team-Defense-Commandline.exe. This would be a SUBSYSTEM=Console application that's literally just a thin wrapper around Team-Defense.exe, to force the creation of a console. This is also similar to what things like python do, with python.exe (a Console exe) and pythonw.exe (a Windows exe).

@zadjii-msft commented on GitHub (Apr 6, 2021): I mean, in my opinion, the easiest way to handle this would be to just use a `commandline` of `cmd.exe /k Team-Defense.exe ...` in your profile. If you use `CREATE_NEW_CONSOLE`, I'm pretty confident that that will end up spawning en entirely new console window. Or if you're really determined, you could just make another "shim" executable that's something like `Team-Defense-Commandline.exe`. This would be a `SUBSYSTEM=Console` application that's literally just a thin wrapper around `Team-Defense.exe`, to force the creation of a console. This is also similar to what things like python do, with `python.exe` (a `Console` exe) and `pythonw.exe` (a `Windows` exe).
claunia commented 2026-01-31 03:36:20 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 7, 2021):

I mean, in my opinion, the easiest way to handle this would be to just use a commandline of cmd.exe /k Team-Defense.exe ... in your profile. If you use CREATE_NEW_CONSOLE, I'm pretty confident that that will end up spawning en entirely new console window.

Or if you're really determined, you could just make another "shim" executable that's something like Team-Defense-Commandline.exe. This would be a SUBSYSTEM=Console application that's literally just a thin wrapper around Team-Defense.exe, to force the creation of a console. This is also similar to what things like python do, with python.exe (a Console exe) and pythonw.exe (a Windows exe).

Well using cmd.exe /k Team-Defense.exe ... does let me see the console output, but for some reason the mouse input does not work, which is my main reasoning for using Terminal.Gui (It does work fine when running plain cmd though).
It seems i have 2 options:

  1. Stick with plain cmd (discarding Windows Terminal) - I'd rather not because cmd is pretty bad
  2. Make my own wrapper/shim - Probably should work but I'm not sure how it would work with mouse input.

I'll try out (2) now and see how it goes.

@ghost commented on GitHub (Apr 7, 2021): > > > I mean, in my opinion, the easiest way to handle this would be to just use a `commandline` of `cmd.exe /k Team-Defense.exe ...` in your profile. If you use `CREATE_NEW_CONSOLE`, I'm pretty confident that that will end up spawning en entirely new console window. > > Or if you're really determined, you could just make another "shim" executable that's something like `Team-Defense-Commandline.exe`. This would be a `SUBSYSTEM=Console` application that's literally just a thin wrapper around `Team-Defense.exe`, to force the creation of a console. This is also similar to what things like python do, with `python.exe` (a `Console` exe) and `pythonw.exe` (a `Windows` exe). Well using `cmd.exe /k Team-Defense.exe ...` does let me see the console output, but for some reason the mouse input does not work, which is my main reasoning for using [Terminal.Gui](https://github.com/migueldeicaza/gui.cs) (It does work fine when running plain `cmd` though). It seems i have 2 options: 1. Stick with plain `cmd` (discarding Windows Terminal) - I'd rather not because `cmd` is pretty bad 2. Make my own wrapper/shim - Probably should work but I'm not sure how it would work with mouse input. I'll try out (2) now and see how it goes.
claunia commented 2026-01-31 03:36:20 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 7, 2021):

Well using cmd.exe /k Team-Defense.exe ... does let me see the console output, but for some reason the mouse input does not work, which is my main reasoning for using Terminal.Gui (It does work fine when running plain cmd though).

Ah well watch out there - even with a shim, mouse input's unfortunately not going to work for you quite yet. We haven't had time to get around to adding support for Win32-style mouse input to the Windows Terminal yet. That's being tracked over in #376.

@zadjii-msft commented on GitHub (Apr 7, 2021): > Well using `cmd.exe /k Team-Defense.exe ...` does let me see the console output, but for some reason the mouse input does not work, which is my main reasoning for using [Terminal.Gui](https://github.com/migueldeicaza/gui.cs) (It does work fine when running plain `cmd` though). Ah well watch out there - even with a shim, mouse input's unfortunately not going to work for you quite yet. We haven't had time to get around to adding support for Win32-style mouse input to the Windows Terminal yet. That's being tracked over in #376.
claunia commented 2026-01-31 03:36:21 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 7, 2021):

I'd rather not because cmd is pretty bad

The shell might be, but the console window that it lives in is part of this repository too and we both love and respect it! 😄

@DHowett commented on GitHub (Apr 7, 2021): > I'd rather not because `cmd` is pretty bad The shell might be, but the console window that it lives in is part of this repository too and we both love and respect it! 😄
claunia commented 2026-01-31 03:36:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 8, 2021):

Well using cmd.exe /k Team-Defense.exe ... does let me see the console output, but for some reason the mouse input does not work, which is my main reasoning for using Terminal.Gui (It does work fine when running plain cmd though).

Ah well watch out there - even with a shim, mouse input's unfortunately not going to work for you quite yet. We haven't had time to get around to adding support for Win32-style mouse input to the Windows Terminal yet. That's being tracked over in #376.

Oooh that explains it. In that case I don't even need to bother using a shim, as I believed it was a cmd issue that was causing my mouse input to not work (but that's probably not the case). It is a bit of a bummer though, I was really hoping to use mouse input. Any ETA/Timeframe for when to expect it?

@ghost commented on GitHub (Apr 8, 2021): > > > > Well using `cmd.exe /k Team-Defense.exe ...` does let me see the console output, but for some reason the mouse input does not work, which is my main reasoning for using [Terminal.Gui](https://github.com/migueldeicaza/gui.cs) (It does work fine when running plain `cmd` though). > > Ah well watch out there - even with a shim, mouse input's unfortunately not going to work for you quite yet. We haven't had time to get around to adding support for Win32-style mouse input to the Windows Terminal yet. That's being tracked over in #376. Oooh that explains it. In that case I don't even need to bother using a shim, as I believed it was a `cmd` issue that was causing my mouse input to not work (but that's probably not the case). It is a bit of a bummer though, I was really hoping to use mouse input. Any ETA/Timeframe for when to expect it?
claunia commented 2026-01-31 03:36:21 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 18, 2021):

@EternalClickbait I think we actually fixed that in #9970, so it should be fixed in 1.9.

@zadjii-msft commented on GitHub (May 18, 2021): @EternalClickbait I think we actually fixed that in #9970, so it should be fixed in 1.9.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13193
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?