GetLargestConsoleWindowSize returns incorrect size in Terminal #14121

Closed
opened 2026-01-31 04:01:29 +00:00 by claunia · 5 comments
Owner

Originally created by @alabuzhev on GitHub (Jun 4, 2021).

Originally assigned to: @DHowett on GitHub.

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
Originally created by @alabuzhev on GitHub (Jun 4, 2021). Originally assigned to: @DHowett on GitHub. ### Windows Terminal version (or Windows build number) 1.9.1445.0 ### Other Software _No response_ ### Steps to reproduce Compile and run the following code: ```C++ #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 ```
claunia added the Product-ConhostResolution-Duplicate labels 2026-01-31 04:01:29 +00:00
Author
Owner

@vefatica commented on GitHub (Jun 4, 2021):

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.

@vefatica commented on GitHub (Jun 4, 2021): 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.
Author
Owner

@DHowett commented on GitHub (Jun 4, 2021):

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

@DHowett commented on GitHub (Jun 4, 2021): (This is an ongoing discussion, but I need to get my notes in order in order to reply ;P)
Author
Owner

@alabuzhev commented on GitHub (Jun 4, 2021):

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.

@alabuzhev commented on GitHub (Jun 4, 2021): > 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](https://github.com/FarGroup/FarManager/issues/405#issuecomment-854969745), 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](https://docs.microsoft.com/en-us/windows/console/getlargestconsolewindowsize), 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](https://www.digitaltrends.com/computing/biggest-ultrawide-monitors/) and it's okay.
Author
Owner

@zadjii-msft commented on GitHub (Dec 9, 2021):

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

/dup #2712

@zadjii-msft commented on GitHub (Dec 9, 2021): You know, we've had this discussion before as it turns out! /dup #2712
Author
Owner

@ghost commented on GitHub (Dec 9, 2021):

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!

@ghost commented on GitHub (Dec 9, 2021): 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!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14121