Windows Terminal 标签页拆离与默认终端 IPC 机制：从 1256 设计文档到 conhost/wt 协作架构

Windows Terminal 标签页拆离与默认终端 IPC 机制从 #1256 设计文档到 conhost/wt 协作架构【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal本文围绕 Windows Terminal 仓库中的规格草稿 Tab Tearoff 设计文档 展开系统讲解支持标签页拆离/合并tab tearoff/merge与默认终端应用接管default app两大特性所需的跨进程通信IPC设计从 Manager 仲裁进程、内核句柄的三种传递模式到 OLE 拖放、协议处理器与 conhost.exe 降级回退策略。读完本文你能理解 Windows Terminal 与 conhost 之间会话如何跨进程移交的完整设计脉络并对照当前源码看到这些设计思想在wt.exe内部以何种方式落地如 TabView 拖放数据载荷、Monarch 窗口仲裁、拆离窗口的_contentBounds定位。一、设计目标与两大核心驱动力该规格由 Michael Niksa 于 2019 年提出issue #1256核心是描述支持以下能力所需的进程间通信机制标签页拆离与合并把一个标签页从一个wt.exe实例拖出合并到另一个wt.exe实例中默认应用接管命令行应用的启动能够触发一个托管环境而不是系统内置in-box的conhost.exe。作者的结论是这两类需求都要求存在一个进程间通信管理器IPC manager能够收发代表客户端应用 ↔ 托管环境连接的系统句柄。作者在 2019 年 7 月微软黑客松期间用一条分支做了多进程管道服务器原型分支链接已不存在于当前仓库原文仅记录其存在并发现问题比答案多因此该文档定位为一份机制探索性的设计规格而非完整实现。二、公共组件Manager 与连接细节2.1 Manager仲裁管理器文档提出的 Manager 形态需要一段服务器/管理器代码等待来自各wt.exe进程乃至conhost.exe进程的连接在进程之间仲裁broker连接它可以运行在独立进程中也可以由某个被选为主管理器primary manager的wt.exe承担创建时应建立通信通道和全局互斥量global mutex。后续启动的其他wt.exe检测到主管理器存在后应等待该 mutex主进程消失后操作系统调度器会唤醒其中一个等待者它拿到锁并接管主管理通道——这是一种**可恢复resilient**的选主方案备选方案是让管理器完全独立且要求所有wt.exe必须保持连接一旦任一进程与管理器断开全部关闭。作者明确倾向于前一种可恢复方案但承认浏览器类应用选择后者的做法必有其原因。实现路径上作者的原型采用了Message 类型的多线程管道服务器Multithreaded Pipe Server但文档的正式结论是最终应形式化地围绕一个更结构化、经过测试、天然具备安全性的机制即COM 服务器接口。2.2 连接细节可传递的两类信息任何一次连接传递本质上只有两种能力在两个进程之间传递内核句柄传递任意长度的结构化信息路径、设置等。标签页拆离与默认应用两个场景都需要这两种能力。三种 Fresh Start全新启动模式对即将被新启动的应用开启会话所需的信息是以下三者之一服务器及引用句柄描述控制台服务器与命令行客户端进程之间驱动连接的句柄。conhost.exe可以将其包装成 PTY其中还可能包含 LNK快捷方式偏好命令行字符串 工作目录描述要启动哪个命令行客户端。conhost.exe启动它并在过程中创建服务器/引用句柄再将其转为 PTY已存在的 PTY 会话带 read、write、signal 三个句柄。传递连接时必须意识到这三种模式并逐一中继给目标wt.exe。系统句柄的跨进程传递OpenProcess DuplicateHandle对系统句柄方案是通过 Manager 向目标进程发起请求取得其PID再告知源进程源进程用PID配合OpenProcess以PROCESS_DUP_HANDLE权限打开目标进程随后用DuplicateHandle把上述句柄复制进目标进程。文档特别指出打开与复制句柄本身就需要操作系统检查我们的访问令牌access token与权限这天然承担了相当一部分安全检查。命令行字符串与工作目录直接把命令行字符串和工作目录传给目标wt.exe让它像用户从下拉菜单选择了一个选项一样正常启动一个新 ConPTY。一个细节技巧可能需要把命令行字符串与用户 profile 做匹配以对齐图标与会话启动偏好。LNK 快捷方式的迁移从 LNK 启动的应用用户可能期望即使快捷方式的属性在技术上属于conhost.exe偏好而非wt.exe偏好在wt.exe里打开的窗口仍应套用这些属性。文档给出的行为是把 LNK 文件信息像命令行字符串一样传给wt.exe由它使用共享库的快捷方式解析逻辑提取信息并迁移为Settings偏好是否持久化该偏好供以后在下拉菜单中使用可以做成选项或询问。Already Running会话已在运行的迁移对已在运行的应用成功迁移到新标签页位置需要发送三类信息ConPTY 的 read、write、signal 句柄回滚历史scroll-back history——它保存在wt.exe内部并不是 PTY 模式下conhost.exe任何时刻重绘内容的组成部分与Settings相关的用户偏好与会话信息。把这些通过 IPC 机制发给目标端后目标端按与源端标签页完全相同的参数立起新标签页。文档还给出了一个替代方向如果未来走向隔离进程模型——每个标签页/窗格有独立进程UI 托管在另一个 frame/shell 进程中外加一个 manager 进程——那么本就需要设计UI 可被远程托管到其他界面Component UI的方案此时活跃会话的迁移只需要把该标签页/窗格的绘制与输入目标重定向到另一个 shell这可能比把构成一个会话的所有部件整体搬过去再重建更简单、更可靠。三、标签页拆离的实现路径文档在Common Pieces之外针对拆离场景单独描述给标签栏的 on-drag 增加处理器并很可能要实现拖放处理器由于拖放处理器基于 OLECOM这是整个 Manager 都应实现为 COM的又一个理由作者坦承此处是低认知度下的理论设计需要探索WinUI 的 TabView 控件预期会支持用自身拖放重排标签页但拖拽开始时我们大概率需要创建一个携带会话 GUID 的拖拽源drag source随后交给操作系统处理 drop若 drop 落在另一个wt.exe上就用 drop 载荷中的会话 GUID 在进程间传递连接信息若落在别处拖拽源应能感知这一点并拉起一个新的wt.exe其启动参数指定启动后向 Manager 执行针对该会话 GUID 的 drop 部分而不是打开默认标签页。四、默认应用conhost 的移交与回退4.1 基本流程与失败回退默认应用启动时conhost.exe必须尝试把传入连接移交给已注册的终端处理器而不是自己弹出 UI 窗口。若注册处理器启动失败、不存在注册处理器、或该机制任何环节失败conhost.exe需要回退到开发前的行为该弹窗就弹窗、该隐藏就隐藏——这是文档中反复强调的可靠性底线。4.2 交互式 vs 非交互式检测必须区分两种模式交互式终端用户希望以可见窗口启动命令行应用以查看输出、输入内容非交互式工具、实用程序、服务在无可视窗口可能带重定向句柄的情况下启动命令行应用。编译器、脚本、工具随时在后台调用命令行工具我们不希望捕获非交互式会话——它们不需要输出与显示没必要承担转入终端的开销。此外还要识别正在启动的 ConPTY避免移交—再被识别—再移交的无限循环。最大的难点是在开始接受来自服务器句柄的连接之前我们不知道它是否为交互式。文档给出两条处理路线路线 A系统自带 conhost 处理系统自带的conhost.exe直接接受来自服务器句柄的连接确认某个wt.exe可以接管 UI 托管后把自己切换为ConPTY 模式把句柄交给wt.exe自己以 PTY 模式在后台保持不可见与wt.exe自己启动该连接时的情形一样。优点大部分启动连接流程照常发生拿到服务器句柄的那个conhost.exe将负责服务该客户端会话的整个生命周期可以完全不用担心驱动如何反应、应用如何折腾进程间关系——一切都正常。缺点从快捷方式、资源管理器、运行框启动命令行应用正是触发默认应用场景的入口将使用的是旧版本的 PTY。若希望使用应用包内已有改进的 PTY就必须把服务器连接迁移进包内 PTY由此引出额外难题可能要让原conhost.exe保持打开直到另一个进程退出防止有人正在等待该进程要么由包内被委派 PTY 的 conhost 在启动连接时自行判定交互性要么由外部 conhost 先启动连接、发现是交互式后中途移交——或者类似的某种舞蹈dance。路线 B包内 conhost 处理把 System32 中conhost.exe的服务器连接直接送进包内版本由它处理连上 broker传递服务器句柄让wt.exe用该特定服务器句柄创建一个 PTY 模式的conhost.exe。其优缺点与路线 A 正好相反文档不再赘述。4.3 向下兼容让默认应用在旧版 OS 上工作文档研究了三条路径并逐一评估安装时替换 system32 中的 conhost.exe操作系统经由kernelbase.dll中的ConsoleInitialize会启动C:\windows\system32\conhost.exe来开启默认应用会话。技术上可以把一个名为conhost.exe的OpenConsole.exe放进 system32 让新代码跑在旧 OS 上前提是装好 CRT、链接 in-OS-CRT、对所有旧版本不可用的 API/引用做条件特性检测。作者说明这实际上就是内部在没有完整 nightly build 时的本地开发测试方式在某种程度上被证明可行。但问题在于OS 会主动通过 ACL 防御对 system32 二进制的改动Windows File Protection 时代已远去但防御仍在内部能成是因为测试证书链正式的应用签名证书是否会被像 OS 签名证书一样信任也不确定且无法在 Windows 之外针对 in-box CRT 构建只能附带 MSVCRT redist——也很恶心。更新 kernelbase.dll 以查询启动偏好/协议处理器启动控制台宿主要覆盖到最新 OS 之外的版本就必须对 kernelbase 做向后服务service。而kernelbase.dll对一切都至关重要几乎没有任何可能获批向后服务以添加特性即便为即将发布的版本改动它风险也极高。思想实验到此结束。更新 conhost.exe 本身去查询启动偏好/协议处理器启动另一个控制台宿主让 system32 的conhost.exe把会话委派给一个期望更新的conhost.exe。由于内置驱动协议不改变、也无意改变前后兼容故事很好若被委派的conhost.exe启动失败还可以像改动前一样回退启动旧的。向后多个版本服务 conhost.exe 仍是有难度的论证资源是否应投入被放弃的 OS 版本但远小于颠覆整个kernelbase.dll。文档补充协议处理器在 Windows 上是广为人知且相对完善/测试充分的机制新旧应用都能处理协议协议处理器还能携带参数不需要依赖其他团队改变 OS 其余部分的运作方式。4.4 启动参数的传递方式文档列出三个选项conhost.exe查询wt.exe的包注册并带参调用入口点可扩展为查询注册为默认的那个包以支持第三方宿主——但要在 OS 里内置选择机制或用某种公开文档化的注册表键有点粗conhost.exe调用**执行别名execution alias**并带参数——WSL 发行版启动器就是这么做的为这类连接定义协议处理器让wt.exe注册它。协议处理器在 Windows 经典应用与打包/现代应用中都受良好支持且必然具备传递某种参数数据的机制。这是作者最倾向的路线形式如ms-term://incoming/session-id。接收方wt.exe联系管理器进程若自己是第一个则把它建立起来协商接收被指定的会话并在新标签页中打开。五、UI/UX 设计5.1 标签页拆离理想世界Ideal World——体验应像浏览器应用鼠标按下并拖动标签页时应提供视觉上的拖拽提示左右拖动应在标签栏上给出重排的视觉指示且不涉及 IPC 管理器服务上下拖动脱离标签栏时应启动一个新的wt.exe实例把拖拽中标签页的状态作为初始启动点传入忽略其他默认启动行为并把拖拽/鼠标按下继续传给该新实例追随鼠标继续把这个游离标签页拖到另一个运行中wt.exe的标签栏上时标签页与该实例合并这个临时新建/游离帧的wt.exe在把最后一个标签页转出后关闭。简化 V1Simplified V1——为首次迭代简化转移不实时发生按下并拖动标签页时通过光标变化之类的方式提供拖拽视觉提示在释放之前不发生任何实际的标签页转移释放回同一wt.exe实例的标签栏其他位置 → 在 TabView 控件内重排标签页释放到另一个wt.exe实例 → 通过 IPC 管理器中继通信通道与细节在目标实例打开标签页在源实例关闭该标签页释放到任何非wt.exe的地方 → 创建一个新的wt.exe实例把连接作为默认启动参数传入。文档还指出如果能找到 Component UI 式方案标签页/窗格有自己的进程只把 UI/输入远程到 shell 中随时更换承载某个元素的 shell/frame 宿主将变得容易甚至平凡。5.2 默认应用的 UX整体上应看起来完全像用户从快捷方式或启动磁贴启动了wt.exe只是首个标签页不同于默认值无 WT 运行中由系统触发来托管客户端应用的conhost.exe找到已安装的wt.exe包并带参启动用该连接替代默认标签页作为首个连接conhost.exe不显示窗口转入 ConPTY 模式只有新的wt.exe及其标签页可见WT 已运行conhost.exe找到运行中的实例用同样机制在标签栏末尾追加新标签页多个 WT 运行中conhost.exe必须找到前台的、激活的或 primary/manager 的那个并把标签页发过去。文档承认作者不确定其他支持标签页的应用怎么做可以研究/学习。六、能力影响分析Capabilities6.1 可访问性作者认为该特性基本不改变可访问性。唯一要提出的是已知信息UIA 框架基于PID、HWND 及其层级建立连接与部分逻辑推理在标签页被挪动后玩弄这些元素可能影响读屏应用在标签页洗牌后获取 UIA 树的能力。6.2 安全该特性必须经过安全评审/审计文档列出几个明确关注点mutex/pipe/通信必须限定在特定会话的特定用户内。另一用户在其会话中运行 WT 时应使用完全独立的 manager 进程与系统对象可能必须抑制跨完整性级别integrity level的连接传递高完整性进程天然有权对低完整性进程操作即提升的wt.exe理论上可以向标准级wt.exe发送标签页。可能需要禁止这种行为甚至每个完整性级别一个管理器涉及的每个内核对象需要什么样的 ACL/DACL/SACL 尚不清楚原型使用消息传递管道 自研协议——自研协议必须做 fuzzing且作者承认我肯定漏了什么。多数安全顾虑若改用知名 IPC 机制作者再次指向 COM 服务器可能自然消除比消息管道复杂但安全性收益大也免去了对协议做 fuzzing 的需要。6.3 可靠性简单实现会降低可靠性在应用实例之间来回倒腾连接默认情况下比不动更冒险值得做的唯一理由就是用户体验。文档给出与 2.2 节替代方向呼应的缓解/增强路径向浏览器式的进程/容器化模型再进一步把每个标签页立为独立的进程宿主wt.exe运行在多种模式下wt.exe - Manager Mode |- wt.exe - Frame Host Mode | |- wt.exe - Tab Host Mode | | |- conhost.exe - ConPTY mode | | |- pwsh.exe - Client application | |- wt.exe - Tab Host Mode | |- conhost.exe - ConPTY mode | |- cmd.exe - Client application |- wt.exe - Frame Host Mode |- wt.exe - Tab Host Mode |- conhost.exe - ConPTY mode |- pwsh.exe - Client applicationManager Mode无 UI作为 broker 坐在那里持有给定窗口站/会话与完整性级别的内核对象接受协议处理器例程协助在标签页移动时于各 frame host 之间中继连接并决定默认应用新标签页实例化在哪里Frame Host Mode单个标签页之外的完整外层外壳托管标签栏、设置下拉、标题栏等Tab Host Mode单个标签页的内层外壳含渲染区域、滚动条、输入等Pane Host Mode既然窗格已经成为现实可能还要再深一层——或者它只是 Tab Host mode 的递归。文档明确这些进程之间如何连接目前尚未探索。6.4 兼容性进程树层级文档指出核心兼容性担忧客户端应用或外部工具判断命令行客户端 ↔ 控制台宿主关系的主要手段之一是进程树/层级而本设计不可避免会让原本托管的conhost.exe无论被wt.exe以 ConPTY 模式启动还是 OS 响应无宿主命令行应用而启动变成孤儿或与真正呈现它的 UI 脱离关联。作者承认可用 API 中可能可以复用重排进程父子关系把conhost.exe置为cmd.exe的父的机制——尽管cmd.exe通常先启动、kernelbase.dll的ConsoleInitialize例行程序先创建了conhost.exe——但这可能引入新问题一个既有的例子是可访问性的 UIA 树不容忍父子关系洗牌因为其通信通道会话常与 HWND/PID 的绑定关系挂钩。两个终端之间拆离/合并的层级示例初始状态实例 A 中有cmd.exe与pwsh.exe两个标签页实例 B 中有一个cmd.exe标签页- wt.exe (Terminal Instance A) |- conhost.exe (in PTY mode) - Hosted to A | |- cmd.exe |- conhost.exe (in PTY mode) - Hosted to A |- pwsh.exe -- I will be dragged out - wt.exe (Terminal Instance B) |- conhost.exe (in PTY mode) - Hosted to B |- cmd.exepwsh.exe标签页从 A 撕下并 drop 到 B 之后进程树实际上没有任何变化——连接细节、偏好与会话元数据经由 IPC 管理通道传递但在外部观察者看来什么都没有变- wt.exe (Terminal Instance A) |- conhost.exe (in PTY mode) - Hosted to A | |- cmd.exe |- conhost.exe (in PTY mode) - Hosted to B |- pwsh.exe -- I am hosted in B but Im parented to A - wt.exe (Terminal Instance B) |- conhost.exe (in PTY mode) - Hosted to B |- cmd.exe文档断言据作者所知Windows 没有把应用重父子化reparent到另一个进程的机制。更有趣的是 A 死亡而 B 仍在运行时- conhost.exe (in PTY mode) - Hosted to B |- pwsh.exe -- I am hosted in B but Im parented to A - wt.exe (Terminal Instance B) |- conhost.exe (in PTY mode) - Hosted to B |- cmd.exe实例 A 死亡后该conhost.exe继续运行在 Process Explorer 等工具里呈现为顶层孤儿。文档给出的行动计划是先实现能实现的观察世界状态再向前修正——我们并不确切知道有多少客户端应用会被这种表观变化影响而且可能完全没问题因为客户端应用始终父子挂在同一个conhost.exe之下即使那些conhost.exe不再汇报给正确的wt.exe。另外是否要允许外部工具发现这种层级文档倾向于没有强有力的理由就不提供——理解本机进程层级是在未来扩展到远程连接时自我设限的好方法。Conhost 与 Terminal 之间默认应用的层级示例看起来很像上一节中 B 死亡后的情形- conhost.exe (in PTY mode) - Hosted to A |- pwsh.exe - wt.exe (Terminal Instance A)该conhost.exe是因无宿主的pwsh.exe启动而触发的随后把自己转为 PTY 模式并接入wt.exe实例 A。替代形态利用 conhost 启动时的重父子化命令让树更整洁- conhost.exe - idling - wt.exe (Terminal Instance A) |- conhost.exe (in PTY mode) |- pwsh.exe顶层的conhost.exe响应无宿主的pwsh.exe而启动识别到wt.exe在运行后把传入连接摆渡进该wt.exewt.exe在自己之下立起 PTY 模式的conhost.exe其下是客户端pwsh.exePTY 模式的conhost.exe用启动时的 reparenting 命令把树整形成上图而那个被孤儿化最初启动的conhost.exe会等待连接退出后才自行退出以防有人正在等待它。6.5 性能、功耗与效率文档的判断很克制这显然比什么都不做低效因为要拉起服务器、协议与处理器来倒腾东西但只要线程与服务大部分时间在睡眠、仅在某个内核/系统事件时唤醒就不会在功耗与后台资源上浪费太多。同时wt.exe在所有效率类别上都比单独的conhost.exe差——不仅显示漂亮要资源还需要其下以 PTY 模式运行的conhost.exe来适配 API 调用这通常可被更在意体验而非总性能的用户接受。但相较用户直接选用wt.exe而非conhost.exe这一情形本特性不太可能再造成多大甚至任何额外损耗。七、源码印证文档思想在当前 wt.exe 中的落点该文档成文于 2019 年属于草稿规格当前仓库中的wt.exe尚未实现文档构想的独立 Manager 进程与跨实例句柄移交但文档中的若干机制已经在源码中以进程内的形式被验证和落地可对照阅读7.1 拖拽标签页的 DataPackage 载荷windowId pid Move文档设想创建携带会话标识的拖拽源交给 OS 处理 drop。当前实现正是用 WinUITabView的拖放事件链完成这一点TerminalPage.cpp_onTabStripDragStarting把被拖标签页存入_stashed.draggedTab记录光标相对标签页原点的dragOffset后续用于定位新窗口并向拖拽数据写入windowId与当前进程pid两个属性声明DataPackageOperation::Move_onTabStripDragOverTerminalPage.cpp目标页必须确认数据载荷含windowId且pid等于本进程 PID才接受 Move 操作——这与文档drop 载荷携带标识、由源端完成信息传递的思路一致只是标识从会话 GUID具体化为窗口 ID PID且当前限定了同进程pid GetCurrentProcessId()跨wt.exe实例的合并尚依赖后续演进_onTabStripDropTerminalPage.cpp解包 DataPackage 得到来源窗口 ID计算 drop 点落在哪个标签之间落在标签左半则插入该位置构造RequestReceiveContentArgs{src, targetWindowId, index}然后上抛给 Monarch——由单例AppLogicthe monarch把请求再分发回源TerminalPage源页执行SendContentToOther。这正是文档中OS 处理 drop、源端被通知后发起移交事件链的具体化且由于所有TerminalPage都运行在同一wt.exe进程内IPC Manager退化为进程内单例仲裁。7.2 撕出到空白处BuildStartupActions 新窗口定位文档 Simplified V1 的第三分支——释放到非 wt.exe 的地方 → 新建实例并把连接作为默认启动参数传入——在源码中对应 _sendDraggedTabToWindow目标窗口 ID 为-1时表示新建窗口见 _onTabDroppedOutside 的注释指针位置减去dragOffset得到新窗口的期望位置使被拖标签页基本仍停在光标正下方移交内容通过tab-BuildStartupActions(BuildStartupKind::Content)序列化为启动动作随后_DetachTabFromWindow_RemoveTab把标签页从源窗口摘除——即文档Fresh Start 三模式中以结构化信息而非裸句柄描述会话的思路源窗口先按原参数重建等价会话目标端再释放源端而非试图跨进程复制活句柄。新窗口侧TerminalWindow.cpp 用成员_contentBoundsTerminalWindow.h记录拆离时传入的内容区域在尺寸计算DIP × scale与初始布局中优先使用它并据此判断当前窗口是拆离tear out过程中打开的。此外 TerminalWindow::Create 的注释明确指出tear-out / reattach 情形下不能使用 settings 的startupActionsGH#16050避免拆离重建的窗口被默认启动动作二次干扰——这恰好印证了文档中新实例启动参数应指定执行 drop 部分而非启动默认标签页的要求。7.3 无障碍佐证UIA 与拆离的耦合文档 6.1 节担忧UIA 基于 PID/HWND/层级会被标签页挪动影响。当前源码中这一耦合是显式存在的TermControlAutomationPeer.h 注释说明该 peer based on InteractivityAutomationPeer, to support tab tear out——可访问性 peer 需要理解拆离/重附加时控件宿主的变化这与文档洗牌 PID/HWND 层级可能影响读屏应用获取 UIA 树的预警相互呼应。7.4 默认应用侧防止移交风暴ConsoleArguments.cpp 中存在注释 Prevent default application handoff to a different console/terminal说明 conhost 侧确实存在向不同控制台/终端移交的参数处理逻辑文档 4.2 节识别正在启动的 ConPTY、防止无限循环移交的顾虑在现行代码里是有对应物的。当前 conhost 的默认终端注册与移交细节另见仓库中 Default Terminal 规格 与 进程模型 2.0 规格可视为本草稿规格在默认应用方向上的后续演进。八、潜在问题清单文档在 Potential Issues 一节汇总了最关键的四个风险前文各节已分别展开进程树布局层级中的进程对目视用工具或程序化检查它的人可能不合逻辑进程与内核对象生命周期应用可能依赖特定进程或对象与其托管窗口的生命周期关系而我们在应用 job object、挪动所有权让标签页生效的过程中可能动了这些默认启动预期测试工具或自动化可能依赖conhost.exe就是宿主应用或尚未准备好容忍其他应用被拉起作者认为交互/非交互检测能缓解但仍需保持警惕AttachConsole/DetachConsole/AllocConsole作者直言完全不知道这些 API 会怎样。AttachConsole有基于进程层级的限制在奇怪的父子顺序下可能表现有趣这或许是必须调整进程父子关系或在底层改 API的驱动因素DetachConsole可能造成标签页从终端里消失、job object 导致全部死亡的问题AttachConsole也不保证回到同一个wt.exe或任何wt.exe。九、未来方向扩展隔离文档末尾指出拆离与默认应用所需的进程容器化 跨进程通信模型若真的建成同一套机制也许可以隔离扩展extensions扩展在长期路线图上存在但对应用稳定性与完整性固有地有风险浏览器式每个标签页一个进程宿主的容器化若能落地扩展可以同样被装进容器里。这与 6.3 节的可靠性论证同出一源浏览器用进程隔离同时换来了稳定性与能力扩展空间。十、小结这份 2019 年的规格文档是理解 Windows Terminal 跨实例/跨宿主会话模型的一份基础设计档案其核心结论可以概括为机制选型优先采用结构化、可测试、自带安全语义的知名 IPC 机制COM 服务器、协议处理器避免自研协议管道的安全与 fuzz 负担信息模型会话传递 内核句柄服务器/PTY read-write-signal经OpenProcessDuplicateHandle跨进程复制 结构化描述命令行/工作目录/LNK 偏好/设置/回滚历史可靠性底线默认应用接管必须全链路可回退到 conhost 原行为演进方向从单进程wt.exe走向 Manager / Frame Host / Tab Host/ Pane Host多进程模型顺带获得可靠性提升与扩展隔离能力。对照当前源码可以看到拖拽数据载荷、Monarch 仲裁、拆离窗口定位与tear-out 不走 startupActions等设计都是该文档事件链思想在进程内场景下的先行落地而真正的跨实例句柄移交与默认应用移交仍在由后续规格Default Terminal、Process Model 2.0与 conhost 侧代码持续演进中。【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考