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

Create a "conpty" framework package to bundle up the PseudoConsole APIs and conhost #1507

New Issue
Closed
opened 2026-01-30 22:29:08 +00:00 by claunia · 8 comments
claunia commented 2026-01-30 22:29:08 +00:00
Owner
Copy Link

Originally created by @DHowett-MSFT on GitHub (Jun 4, 2019).

This deliverable tracks pulling out the source for the PseudoConsole API set.

Rationale

Right now, we're using conhost.exe directly as a pseudoconsole host. If we ship it as a framework package, we can switch to the "official" PseudoConsole APIs (CreatePseudoConsole, ClosePseudoConsole, etc.) and offer conpty as an independently-upgradable package on which WT and third party applications can depend. This will allow us to more fully undock from the OS release cycle.

Requirements

  • Document/open HPCON
  • Translate winconpty.c (which currently lives in kernelbase) from C to C++
    • produce conpty.dll, which hosts the three pseudoconsole APIs
  • Produce a framework package

see also: #3577

Originally created by @DHowett-MSFT on GitHub (Jun 4, 2019). This deliverable tracks pulling out the source for the PseudoConsole API set. ### Rationale Right now, we're using conhost.exe directly as a pseudoconsole host. If we ship it as a framework package, we can switch to the "official" PseudoConsole APIs (`CreatePseudoConsole`, `ClosePseudoConsole`, etc.) and offer conpty as an independently-upgradable package on which WT and third party applications can depend. This will allow us to more fully undock from the OS release cycle. ### Requirements * [x] Document/open `HPCON` * [x] Translate winconpty.c (which currently lives in kernelbase) from C to C++ * [x] produce `conpty.dll`, which hosts the three pseudoconsole APIs * [ ] Produce a framework package see also: #3577
claunia added the Issue-FeatureNeeds-Tag-FixArea-InteropProduct-Conpty labels 2026-01-30 22:29:08 +00:00
claunia commented 2026-01-30 22:29:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 8, 2019):

As discussed with @Tyriar, we should probably also just make a nuget package for the ConPTY APIs in lieu of a proper framework package. Framework packages will only work for packaged applications, and not for something like VSCode.

@zadjii-msft commented on GitHub (Aug 8, 2019): As discussed with @Tyriar, we should probably also just make a nuget package for the ConPTY APIs in lieu of a proper framework package. Framework packages will only work for packaged applications, and not for something like VSCode.
claunia commented 2026-01-30 22:29:10 +00:00
Author
Owner
Copy Link

@davidhewitt commented on GitHub (Dec 28, 2019):

Random question, is there a way that winconpty could be packaged as a static library which contains the conhost server internally? It would be nice if applications could be built using winconpty and can then be shipped without needing to have OpenConsole.exe / conhost.exe packaged beside them.

@davidhewitt commented on GitHub (Dec 28, 2019): Random question, is there a way that `winconpty` could be packaged as a static library which contains the `conhost` server internally? It would be nice if applications could be built using `winconpty` and can then be shipped without needing to have `OpenConsole.exe` / `conhost.exe` packaged beside them.
claunia commented 2026-01-30 22:29:11 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Dec 28, 2019):

Not easily: conhost isn’t architected in such a way as to allow multiple instances of it to be hosted in the same address space. It’s riddled with singletons and global state. You’d only be able to host a single console session with a static pseudoconsole library 😄

@DHowett-MSFT commented on GitHub (Dec 28, 2019): Not easily: conhost isn’t architected in such a way as to allow multiple instances of it to be hosted in the same address space. It’s riddled with singletons and global state. You’d only be able to host a single console session with a static pseudoconsole library :smile:
claunia commented 2026-01-30 22:29:11 +00:00
Author
Owner
Copy Link

@davidhewitt commented on GitHub (Dec 28, 2019):

It’s riddled with singletons and global state.

Yikes! Amazingly that would still be enough for the use case I was thinking (Alacritty). It would only ever host a single console process per Alacritty process.

Such a library would greatly help Alacritty use ConPTY with the ability to control the version of ConPTY that it's paired with. For example, I've been wondering about submitting a PR to implement https://github.com/microsoft/terminal/issues/262. Using overlapped I/O would help to unify our code with the Win7 legacy code (WinPTY) which also uses overlapped I/O. However, as things are, we'd probably want to keep supporting the blocking ConPTY I/O implementation until we were sure all Windows 10 versions with blocking I/O are more or less out-of-use. If we could control the ConPTY version, ideally by a static lib rather than packaging with a conhost.exe, we could entirely remove the blocking I/O implementation in Alacritty.

For safety, such a static library could add a check to ensure only one console process is spawned, right?

If I were to author one, would you be willing to review a PR which adds a way to build conhost as a static lib?

@davidhewitt commented on GitHub (Dec 28, 2019): > It’s riddled with singletons and global state. Yikes! Amazingly that would still be enough for the use case I was thinking ([Alacritty](https://github.com/jwilm/alacritty)). It would only ever host a single console process per Alacritty process. Such a library would greatly help Alacritty use ConPTY with the ability to control the version of ConPTY that it's paired with. For example, I've been wondering about submitting a PR to implement https://github.com/microsoft/terminal/issues/262. Using overlapped I/O would help to unify our code with the Win7 legacy code (WinPTY) which also uses overlapped I/O. However, as things are, we'd probably want to keep supporting the blocking ConPTY I/O implementation until we were sure all Windows 10 versions with blocking I/O are more or less out-of-use. If we could control the ConPTY version, ideally by a static lib rather than packaging with a `conhost.exe`, we could entirely remove the blocking I/O implementation in Alacritty. For safety, such a static library could add a check to ensure only one console process is spawned, right? If I were to author one, would you be willing to review a PR which adds a way to build conhost as a static lib?
claunia commented 2026-01-30 22:29:11 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Dec 28, 2019):

I appreciate the offer, but I wouldn’t be willing to ship that as a solution. Sorry! There’s too many caveats, and moving forward I’d prefer a solution that takes us through true console host multi-instancing.

From an architectural standpoint, it seems more robust to run the console host as a separate process if only for the insulation it affords the pty user from crashes.

Also, see #3568: a static library solution may make it difficult for an x86 application running on x64 to properly host consoles, as the conhost needs to match the system architecture.

@DHowett-MSFT commented on GitHub (Dec 28, 2019): I appreciate the offer, but I wouldn’t be willing to ship that as a solution. Sorry! There’s too many caveats, and moving forward I’d prefer a solution that takes us through true console host multi-instancing. From an architectural standpoint, it seems more robust to run the console host as a separate process if only for the insulation it affords the pty user from crashes. Also, see #3568: a static library solution may make it difficult for an x86 application running on x64 to properly host consoles, as the conhost needs to match the _system_ architecture.
claunia commented 2026-01-30 22:29:11 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Dec 28, 2019):

I was idly investigating shipping conhost as a dll and using something like rundll to host it so it didn’t read so immediately as a separate process, and could be another entry point on winconpty.dll, but that still doesn’t help us with #3568...

@DHowett-MSFT commented on GitHub (Dec 28, 2019): I was idly investigating shipping conhost as a _dll_ and using something like rundll to host it so it didn’t read so immediately as a separate process, and could be another entry point on winconpty.dll, but that still doesn’t help us with #3568...
claunia commented 2026-01-30 22:29:11 +00:00
Author
Owner
Copy Link

@davidhewitt commented on GitHub (Dec 28, 2019):

Understood, thanks for investigating!

@davidhewitt commented on GitHub (Dec 28, 2019): Understood, thanks for investigating!
claunia commented 2026-01-30 22:29:12 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 27, 2022):

This is obsoleted by #12980!

@DHowett commented on GitHub (Apr 27, 2022): This is obsoleted by #12980!
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-Interop Issue-Feature Needs-Tag-Fix Product-Conpty
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#1507
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?