GetLargestConsoleWindowSize returns incorrect size in Terminal

[alabuzhev]

Windows Terminal version (or Windows build number)

1.9.1445.0

Other Software

No response

Steps to reproduce

Compile and run the following code:

#include <iostream>
#include <windows.h>

int main()
{
	COORD c = GetLargestConsoleWindowSize(GetStdHandle(STD_OUTPUT_HANDLE));
	std::cout << "\nWidth:  " << c.X << "\nHeight: " << c.Y << std::endl;
}

Expected Behavior

Some sane output, e.g.

Width:  213
Height: 50

Actual Behavior

Reported width is insanely large:

Width:  1904 
Height: 62

Actual maximum size (maximize the window and type mode con):

> mode con

Status for device CON:
----------------------
    Lines:          47
    Columns:        209

[vefatica]

If you're familiar with the console API, it's a bit disappointing, but many things don't work when a console app runs in Windows Terminal. For one thing, there is no console window; i.e., no CONSOLE_WINDOW_CLASS window.

This will shed some light: https://docs.microsoft.com/en-us/windows/console/getlargestconsolewindowsize

A year or more ago @DHowett gave me a fairly detailed account of what you can/cannot expect to work. I can't find the issue. If @DHowett chimes in here, perhaps he can dredge it up.

[DHowett]

(This is an ongoing discussion, but I need to get my notes in order in order to reply ;P)

[alabuzhev]

it's a bit disappointing, but many things don't work when a console app runs in Windows Terminal

I just ranted about that fact elsewhere, but anyways - it's okay if something doesn't work, especially when there are technical limitations. But please, please, make it obvious that it doesn't work by returning FALSE, or, in this particular case, returning {0, 0} and setting the last error to something sensible to give an app a chance to recover.
Currently it's impossible to tell whether the function failed and the result can't be trusted of the user just has one of these and it's okay.

[zadjii-msft]

You know, we've had this discussion before as it turns out!

/dup #2712

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!