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

SetConsoleDisplayMode on x64 #19422

New Issue
Closed
opened 2026-01-31 06:42:52 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 06:42:52 +00:00
Owner
Copy Link

Originally created by @malxau on GitHub (Feb 20, 2023).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

N/A (conhost issue)

Windows build number

10.0.17763 (but hasn't changed)

Other Software

"My Cool Application" that calls SetConsoleDisplayMode with CONSOLE_FULLSCREEN_MODE

Steps to reproduce

SetConsoleDisplayMode with CONSOLE_FULLSCREEN_MODE

Expected Behavior

Expected conhost to switch to fullscreen mode

Actual Behavior

  • Does switch to fullscreen mode if the program is 32 bit
  • Fails if the program is 64 bit

(Not sure which field to put analysis)

As far as I can tell, SetConsoleDisplayMode's client side implementation is compiled for x86 only. This is due to a historical accident. Originally fullscreen required text mode hardware support, and only x86 had it - Alpha, PPC, MIPS only supported bitmapped graphics. When the text mode fullscreen support was removed, it didn't really matter than this code failed on the client side or the server side. But in Windows 10, the return of fullscreen mode in graphics mode rendered this obsolete, since it can work on any architecture without hardware support.

Related, NT_CONSOLE_PROPS (the block attached to shortcuts) has a bFullScreen member, but this seems to be loaded as part of ShortcutSerialization.cpp but is never actually used. My hunch is this logic was removed when hardware fullscreen support was removed, and not re-added when bitmapped fullscreen support was added back.

(The bitmapped fullscreen mode is really cool and underappreciated IMHO. Unlike the previous hardware one, it can support arbitrary dimensions or fonts, and is much more usable. Unfortunately the only way to invoke it seems to be to use an x86 program or hit Alt+Enter.)

Originally created by @malxau on GitHub (Feb 20, 2023). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version N/A (conhost issue) ### Windows build number 10.0.17763 (but hasn't changed) ### Other Software "My Cool Application" that calls `SetConsoleDisplayMode` with `CONSOLE_FULLSCREEN_MODE` ### Steps to reproduce `SetConsoleDisplayMode` with `CONSOLE_FULLSCREEN_MODE` ### Expected Behavior Expected conhost to switch to fullscreen mode ### Actual Behavior - Does switch to fullscreen mode if the program is 32 bit - Fails if the program is 64 bit (Not sure which field to put analysis) As far as I can tell, `SetConsoleDisplayMode`'s client side implementation is compiled for x86 only. This is due to a historical accident. Originally fullscreen required text mode hardware support, and only x86 had it - Alpha, PPC, MIPS only supported bitmapped graphics. When the text mode fullscreen support was removed, it didn't really matter than this code failed on the client side or the server side. But in Windows 10, the return of fullscreen mode in graphics mode rendered this obsolete, since it can work on any architecture without hardware support. Related, `NT_CONSOLE_PROPS` (the block attached to shortcuts) has a `bFullScreen` member, but this seems to be loaded as part of ShortcutSerialization.cpp but is never actually used. My hunch is this logic was removed when hardware fullscreen support was removed, and not re-added when bitmapped fullscreen support was added back. (The bitmapped fullscreen mode is really cool and underappreciated IMHO. Unlike the previous hardware one, it can support arbitrary dimensions or fonts, and is much more usable. Unfortunately the only way to invoke it seems to be to use an x86 program or hit Alt+Enter.)
claunia added the Product-ConhostIssue-BugNeeds-Tag-FixArea-Server labels 2026-01-31 06:42:52 +00:00
claunia commented 2026-01-31 06:42:53 +00:00
Author
Owner
Copy Link

@leecher1337 commented on GitHub (Mar 24, 2023):

Just a little comment:

Full screen hardware support also never worked on x64. The problem lies within the IO Permission bitmap that allows passing through direct hardware port access on x86 with Ke386SetIoAccessMap function.
This function simply isn't present on x64 and theresfore functionality was not available there. However, there are some tricks for direct port access on x64, giveio64 has a way to allow it.
I thought about writing a fullscr.sys driver for x64, some code parts are still lying around, but as for unknown reasons starting with Windows 8 XPDM display driver support was removed (Win 7 still had it, so fullscreen was possible on Win 7 by simply dynamically stopping the WDDM display driver which caused a fallback to XPDM which supported fullscreen, I automated this via a service that hooked console fullscreen switch, so that it integrated seamlessly, but that's another story...), the idea became obsolete.

Breaking XPDM essentially also killed off all graphical DOS applications, because even though NTVDM technically inherited windowed graphic modes from MIPS/Alpha/PPC builds and it also works with ConhostV1 thanks to CreateConsoleScreenBuffer support, emulation performance simply is too slow to be of practical use when running in V86 mode, way too many context switched required.

@leecher1337 commented on GitHub (Mar 24, 2023): Just a little comment: Full screen hardware support also never worked on x64. The problem lies within the IO Permission bitmap that allows passing through direct hardware port access on x86 with `Ke386SetIoAccessMap` function. This function simply isn't present on x64 and theresfore functionality was not available there. However, there are some tricks for direct port access on x64, giveio64 has a way to allow it. I thought about writing a fullscr.sys driver for x64, some code parts are still lying around, but as for unknown reasons starting with Windows 8 XPDM display driver support was removed (Win 7 still had it, so fullscreen was possible on Win 7 by simply dynamically stopping the WDDM display driver which caused a fallback to XPDM which supported fullscreen, I automated this via a service that hooked console fullscreen switch, so that it integrated seamlessly, but that's another story...), the idea became obsolete. Breaking XPDM essentially also killed off all graphical DOS applications, because even though NTVDM technically inherited windowed graphic modes from MIPS/Alpha/PPC builds and it also works with ConhostV1 thanks to CreateConsoleScreenBuffer support, emulation performance simply is too slow to be of practical use when running in V86 mode, way too many context switched required.
claunia commented 2026-01-31 06:42:54 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Dec 11, 2023):

I've just merged a PR to fix this internally (MSFT-48083811). 🙂

@lhecker commented on GitHub (Dec 11, 2023): I've just merged a PR to fix this internally (MSFT-48083811). 🙂
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 Area-Server Issue-Bug Needs-Tag-Fix Product-Conhost
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#19422
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?