Set $Host.UI.RawUI.MaxPhysicalWindowSize

[creack]

Hello,

I can't find any reference to MaxPhysicalWindowSize in the console docs, I may be missing something, but is there a way to set this value?

The initial COORD in CreatePseudoConsole and in ResizePseudoConsole seem to only take X/Y.

Some programs like vim and other use it as upper bound. Upon exit, it restores the terminal modes and size, which results in the wrong one, breaking the terminal.

While I am working on adding support for conpty in a Go library, I noticed that OpenSSH has the same issue.

Open/Close vim result:

$> stty size
50 145
$> ssh wintest1
PowerShell 7.3.9
PS C:\Users\Administrator> $Host.UI.RawUI

ForegroundColor       : Gray
BackgroundColor       : Black
CursorPosition        : 0,2
WindowPosition        : 0,0
CursorSize            : 25
BufferSize            : 145,50
WindowSize            : 145,50
MaxWindowSize         : 145,50
MaxPhysicalWindowSize : 1008,45
KeyAvailable          : True
WindowTitle           : Administrator: C:\Windows\system32\conhost.exe


PS C:\Users\Administrator> vim
PS C:\Users\Administrator> $Host.UI.RawUI

ForegroundColor       : Gray
BackgroundColor       : Black
CursorPosition        : 0,18
WindowPosition        : 0,0
CursorSize            : 25
BufferSize            : 145,45
WindowSize            : 145,45
MaxWindowSize         : 145,45
MaxPhysicalWindowSize : 1008,45
KeyAvailable          : True
WindowTitle           : Administrator: C:\Windows\system32\conhost.exe


PS C:\Users\Administrator>

Any pointer would be appreciated.

For reference:
windows 2022 server without desktop: 10.0.20348.0
sshd: OpenSSH_for_Windows_8.0p1
vim: 9.0 (2022 Jun 28)

[tgauth]

Not sure if this is what you're looking for, but here is some documentation on MaxPhysicalWindowSize:
https://learn.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface.maxwindowsize?view=powershellsdk-7.3.0

[creack]

Thanks @tgauth, however, this only speaks about getting the value, not setting it. It also refers to the actual display, which is not relevant here in the context of a pseudo console.

In my example, WindowSize is larger than MaxPhysicalWindowSize and everything works fine until the tool restores the terminal and uses the MaxPhysicalWindowSize as upper bound.

Googling about it yielded quite a few examples of tools/scripts doing the same, checking MaxPhysicalWindowSize before setting the actual size, maybe it is an issue with those tools?

How does windows sets this value? In the context of a pseudo console, the actual size of the physical or virtual display attached is irrelevant and needs to be set, or am I missing something?

[lhecker]

In the native Win32 console API this field is called dwMaximumWindowSize in the CONSOLE_SCREEN_BUFFER_INFO(EX) struct. It's read-only and these methods generate it: https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/host/screenInfo.cpp#L410-L478

It seems like we should return 65535,65535 for dwMaximumWindowSize when conhost runs as ConPTY. I think this is where we should do it: https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/host/screenInfo.cpp#L430

• ConPTY should be considered headless.
• It should definitely not return the current buffer size, since that's not what the dwMaximumWindowSize field stands for.

Edit: Actually, maybe I'm misunderstanding dwMaximumWindowSize. Seems like it's always been limited to the current window size which is... weird? How would someone then know how large a window can be made? Oh well...

@zadjii-msft Should we move this issue over to the terminal repo? Seems more like a bug to me. (Also, heavily related to our vim sizing issues?)

[zadjii-msft]

Some programs like vim and other use it as upper bound. Upon exit, it restores the terminal modes and size, which results in the wrong one, breaking the terminal

Oh, so this is almost definitely the root cause of microsoft/terminal#16254 then isn't it 😮

We should definitely track this on the terminal repo somewhere - terminal#16254 is probably a good enough place. I'd want us to double-check the history here. IIRC we were returning 1,1 years ago¹, so I'd want to see if we've got the history on why we picked the current buffer size (or if that was just a totally arbitrary decision)

Footnotes

1. which is obviously insane in retrospect ↩

[DHowett]

root cause of 16254

I dearly hope vim isn’t using the max physical window size to position the cursor. That value has no bearing on the actual buffer the user was looking at. How could it be the root cause?

1,1 is “insane”

The problem is that this question has no answer. There is no guarantee of a physical window, and when there is a physical window we cannot know its limits. Is it more correct to say 64k than 1? I disagree 😄