Unexpected behavior of the Console class in Windows Terminal

[f2bo]

I was looking at doing something slightly more involved with the Console class than my occasional calls to WriteLine or ReadKey. I began to look at some other properties and methods I hadn't used previously to understand how they should be used and noticed that many did not seem to work as documented.

To give an example, the LargestWindowHeight property, which supposedly should return the height of the largest possible console window measured in rows. However, that didn't seem to be the case in my tests where it returned a larger number. Or some samples in the documentation that didn't do what they claimed to do.

• https://learn.microsoft.com/en-us/dotnet/api/system.console.setbuffersize?view=net-9.0#examples
• https://learn.microsoft.com/en-us/dotnet/api/system.console.setwindowsize?view=net-9.0#examples

It then occurred to me that perhaps this might be related to the use of the Windows Terminal and after switching to the Windows Console Host, things began to make a little more sense.

Of course, it would be desirable for all Console features to be available in Windows Terminal given that it is now the default. I also imagine that I'm not the first person to have noticed this and that there's some technical hurdle to make them work. However, I'm a little surprised that the documentation and samples do not reflect any of this. At the very least, they should indicate which methods or properties are not supported.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

The LargestWindowHeight property directly calls GetLargestConsoleWindowSize from Windows console API. All the console API issues should be reported to Windows Terminal. Duplicate of microsoft/terminal#10337.

Also according to documentation, console buffer APIs are not recommended for use in the future.

[f2bo]

@huoyaoyuan Thanks for replying.

The LargestWindowHeight property directly calls GetLargestConsoleWindowSize from Windows console API. All the console API issues should be reported to Windows Terminal. Duplicate of microsoft/terminal#10337.

That was just an example of many methods and properties that I tested and didn't seem to work (e.g. LargestWindowWidth, LargestWindowHeight, SetWindowSize, WindowWidth, WindowHeight, SetWindowPosition, WindowLeft, WindowTop, ...). I recommend running the samples I linked above keeping in mind that one might do this when new to an API and a sample should hopefully make things clearer.

Also according to documentation, console buffer APIs are not recommended for use in the future.

Well, yes, but that's found in the documentation for the Windows API. There's no such disclaimer in the .NET documentation. Also, the recommendation applies to virtual environments such as when using SSH. It should make it clear that the Windows Terminal, which is now the default console in Windows, is also in this category.

According to the .NET docs, all these APIs are supported in Windows and I didn't see a single mention of the Windows Terminal or any other indication that they might not work as expected. I think something should be done on the .NET side to make this better, even it it's only adding a note like the one you mention above, but making it clear that it applies to Windows Terminal.