大坡3D软件开发

本册是"窗口系统三大主线"的GDI 文本渲染深化篇。第 30 册《USER 与 GDI 双子系统》从分工的视角给出了TextOutW。本册则把镜头对准这条链的内部文本怎么变成字形LPWSTR的每个WCHAR（含 UTF-16 surrogate 对）如何通过查 cmap 表得到字形索引（glyph index）；字形怎么变成位图：字形索引如何经加载轮廓、渲染成 8BPP 覆盖度掩码，并被全局缓存；位图怎么变成屏幕像素：字形位图如何被包装成SURFOBJ，再作为掩码交给，用 DC 的文本画刷。

USER 与 GDI 的关系：USER 不直接操作显示硬件。窗口的"显示"本质是：USER 维护窗口对象与可见区域（hrgnVis），当窗口需要重绘时产生 WM_PAINT 消息，应用程序通过GetDCBeginPaint获得窗口 DC（windc.c创建），GDI 以窗口可见区域为裁剪区绘制到屏幕表面。可见区域（vis.c）的合成是 USER 与 GDI 协作的桥梁。本文把这条注释展开成完整的架构分析。先给出全局 ASCII 图——注意与总览 L48-72 的区别在于：本篇把。

Z 顺序（Z-order）是窗口系统的核心概念之一：屏幕上的窗口可以重叠，"谁盖住谁"由 Z 序决定。Windows 的 Z 序模型是兄弟窗口单链表——每个父窗口（或桌面）把它的直接子窗口串成一条双向链表，链表头部（）是屏幕最上层，链表尾部是最底层；绘制、命中测试、可见区域计算全部按这条链表的顺序工作。本篇逐行拆解的问题包括：一句话模型：Z 序 = “以 为根、以 为头的兄弟单向次序（ 指向更底层）”； 只是为摘除/反向遍历提供的回链。窗口树（父子）是层次，Z 序是同一层内的前后次序，两者正交。 的第

第 27 册回答了"标题栏三个系统按钮怎么画"。但界面上的按钮远不止标题栏那三个——对话框里的"确定/取消/应用"、向导的"上一步/下一步"、工具栏下的各种按钮，全部是BUTTON 控件：应用在对话框模板或代码里用创建，由 user32 内置的 Button 窗口类接管。它们是"窗口显示"主线的另一大块内容，且绘制引擎与标题栏按钮完全相同），只是调用侧从内核换成了用户态控件代码button.c。“Button” 这个类是怎么注册的？为什么就能得到一个会自己画、自己响应点击的窗口？

第 25 册已经回答了"按钮在哪里"（布局）与"点了之后发生什么"（行为）；第 26 册回答了"图标区怎么显示"。按钮的"样子"到底是怎么画出来的。怎么把整个标题栏矩形TempRect收缩出每个按钮自己的矩形（SM_CXSIZE步进定位）？在内核里走了哪条路，最终调用了谁？怎么用Marlett 符号字体'0''1''2''r'）画出最小化/最大化/还原/关闭符号？按钮的3D 凸起边）与凹陷边）是几条什么颜色的线画出来的？按下）与灰化）在像素层面各做了什么？点击按钮的完整状态机（

标题栏最左端有一块宽度约等于标题栏高度的正方形区域，显示窗口的小图标（16×16，系统度量 /）。这个图标区同时是系统菜单按钮：1.2 两条图标显示链窗口图标在 ReactOS 里实际有两条相互独立的"显示链"：链 A 回答"非最小化窗口的标题栏图标怎么画"，链 B 回答"最小化后窗口图标去哪、位置怎么定"。两条链在 / 这条"图标归属"逻辑上汇合——本册的 6、7 节是两条链共同的地基。第 25 册已覆盖：标题栏六段绘制总流程（）、三按钮像素级布局与 Marlett 符号、按下状态机（）、激活/非激

标题栏是带WS_CAPTION，值0xc00000）样式的窗口顶部一条横向带状区域，高度由系统度量决定（经典主题默认 19 像素）。标识：显示窗口标题文字与窗口图标，用户据此识别窗口；操作入口：承载系统菜单按钮（图标）、最小化/最大化/关闭三个系统按钮；移动载体：按住标题栏空白区拖动可移动窗口（HTCAPTION→SC_MOVE快捷操作：双击标题栏空白区切换最大化/还原（│ WS_THICKFRAME 粗边框（NC_DrawFrame 绘制） │。

在拉丁字母键盘上如何输入 CJK（中日韩）等表意文字。Win32 的答案是：把"键盘事件流"先交给一个叫IMM（Input Method Manager，输入法管理器）的中间层，由它把按键翻译成"组合字符串”，组合完成后以WM_CHAR提交给应用程序。ReactOS的 IMM 实现横跨内核（win32k 的）与用户态（imm32.dll），中间靠桥接。键盘硬件中断→ RawInput 线程（input.c: RawInputThreadMain）

键盘是窗口系统最复杂的输入设备：一个键按下，既要维护"按键状态"（供 GetKeyState/GetAsyncKeyState 查询），又要在键盘布局（Keyboard Layout）的参与下翻译成虚键与字符，还要生成WM_KEYDOWNWM_KEYUP硬件消息，最终在用户态阶段变成WM_CHARWM_SYSCHAR送达焦点窗口的窗口过程。此外，键盘还要服务 IME（输入法）、

窗口怎么样实现鼠标控制。鼠标控制的核心是把物理世界的鼠标动作（移动、按键、滚轮）翻译成 Win32 窗口消息体系中的WM_MOUSE*消息，并把它准确地投递给"应该接收"的那个窗口。鼠标硬件中断（i8042prt / mouclass / HID）→ 输入驱动排队原始数据 MOUSE_INPUT_DATA（ntddmou.h）→ RawInput 线程（input.c: RawInputThreadMain，LOW_REALTIME 优先级）

硬件输入（鼠标/键盘中断）是如何变成发给特定窗口的消息的？——答案是一条完整的内核管线：输入驱动 →RawInput 线程（RIT）→ 键状态/光标位置更新 → 消息队列 → 应用窗口过程。系统如何对输入做"全局状态管理"？——输入屏蔽（BlockInput）、线程输入队列合并（AttachThreadInput）、屏保触发（DoTheScreenSaver）、以及可访问性事件（WinEvent，SetWinEventHook）的注册与分发。input.c是这条管线的"总装车间"：它只做三件事——

光标（Cursor）与图标（Icon）是窗口管理中最"小"却也最特殊的一类 USER 对象：它们的本质都是位图对（AND 掩码 + XOR 掩码 / 彩色位图 + 透明信息），再加上一个"热点"（hotspot，光标命中点）或"动画帧表"（.ani 光标）。ReactOS 在 win32k 中用同一个对象类型（TYPE_CURSOR）统一表示光标与图标，把差异压进一个rt（资源类型）字段与一组标志位里。

窗口系统里的一切"对象"——窗口（HWND）、菜单（HMENU）、光标/图标（HCURSOR/HICON）、钩子（HHOOK）、加速键表（HACCEL）、输入法上下文（HIMC）、剪贴板数据、插入符、计时器、WinEvent 钩子——在 ReactOS 内核侧都被抽象为 USER 对象：一块带统一头部的内核内存 +一个句柄表项（编号 + 类型 + 代次）。 就是这个对象管理器的核心实现。（869 行）承担五大职责：（341 行）提供 USER 对象的"存储地基"：会话级 （全局用户堆，所有进程共享一

桌面与窗口站是 ReactOS 窗口系统层级结构的顶层：进程 → 窗口站（Window Station）→桌面（Desktop）→ 窗口树。一个窗口站是一个会话内的安全与资源容器（剪贴板、原子表、键盘布局、窗口站级安全都在其中）；一个桌面是窗口树与输入状态的容器（桌面窗口是窗口树的根，桌面堆 pheapDesktop 容纳该桌面上所有窗口对象）。前 17 册分析的多是"某个窗口、某条消息、某段菜单"——那些对象全部隶属于某个桌面；这些对象住在哪里？

剪贴板是窗口管理主线中最"特殊"的一员：它不像菜单、滚动条那样有可见的 UI，也不像焦点、钩子那样直接参与消息分发，而是一个跨进程、跨线程的数据共享设施。一个进程"复制"（Copy），另一个进程"粘贴"（Paste），中间的桥梁就是剪贴板。在 ReactOS 中，剪贴板的全部状态——格式列表、数据句柄、所有者窗口、查看者链、锁——都保存在窗口站对象）中，因此同一窗口站内所有桌面、所有进程共享同一份剪贴板内容。本册分析的内核文件共 1285 行，包含 32 个函数，其中NtUser*

当前的输入（键盘/鼠标）属于谁？概念载体含义典型消息焦点 Focus消息队列spwndFocus键盘消息（WM_KEYDOWN/UP、WM_CHAR、WM_SYSKEY*）的接收者激活 Active消息队列当前"高亮"的顶层窗口，决定标题栏/边框的绘制状态前台 Foreground桌面+ 全局整个系统当前与之交互的窗口/线程/消息队列捕获 Capture消息队列鼠标消息的定向目标（越过命中测试）ReactOS 中三者之间的关系可以概括为一条从硬件到窗口的消息定向链。

钩子（Hook）是 Win32 提供的一种消息流拦截机制：应用程序可以注册一个"钩子过程"（Hook Procedure），当系统中发生指定类型的事件（消息被取出、消息被发送、按键、鼠标移动、窗口创建等）时，系统先调用钩子过程，再继续原有的处理流程。钩子过程可以：钩子在"窗口管理"主线中的位置：它是消息传递机制（msgqueue.c / message.c）之上的一层“旁路闸门”。消息在被取出（WH_GETMESSAGE）、被发送（WH_CALLWNDPROC）、进入键盘/鼠标队列（WH_KEYBO

窗口管理主线已经讲过窗口的创建/销毁（window.c）、消息队列与派发（msgqueue.c、message.c）、默认窗口过程（defwnd.c）、菜单（menu.c，见 _11/_12 册）与滚动条（scrollbar.c，见 _13 册）。窗口计时器（timer.c，720 行）SetTimerKillTimer的内核实现。它以一个内核 KTIMER（）驱动所有窗口计时器，到期后把WM_TIMER消息投递到线程消息队列；同时提供内部系统计时器机制（光标闪烁、窗口闪烁、鼠标悬停等）

滚动条是窗口管理子系统中最"看得见"的基础设施之一。几乎每个文本编辑器、列表框、树形控件、网页浏览器都要靠滚动条浏览内容。Win32 中有两种形态的滚动条：无论哪种形态，滚动条的逻辑模型完全相同：一个"位置"（pos）在一个"范围"（range：）内移动，可选地有一个"页面大小"（page）决定 thumb 的比例与翻页步长。用户通过鼠标点击箭头/滑道或拖动 thumb 产生 / 通知，应用程序在收到通知后调用 之类的 API 更新位置并重绘内容。窗口管理主线上的地位：滚动条与菜单（_11/_1

本文是"窗口系统三大主线之窗口管理"系列的第 12 册，主题是菜单（下）：循环与交互，核心源码为（共 6699 行）。第 11 册（ReactOS 窗口系统分析_11.md）覆盖了菜单的对象与构造PMENUPITEM对象模型、CreateMenuAppendMenuLoadMenu等构造 API、菜单项属性（）、菜单尺寸计算与绘制（本册则聚焦菜单的运行时行为模态菜单循环进入后，系统捕获鼠标、接管消息队列、循环处理输入，直到用户选中、取消或菜单被外部终结。命中测试与高亮移动。

菜单子系统是 ReactOS 窗口管理中最复杂的一块。它既要支持顶层菜单栏（挂在窗口客户区上方的一条横栏），也要支持弹出式菜单（右键菜单、下拉子菜单、系统菜单），还要承担模态菜单循环（TrackPopupMenuEx 捕获鼠标键盘、高亮导航、子菜单展开）与自绘菜单（owner-draw）等重活。总览文档 5.4 节把 menu.c 的职责归纳为五条主线：本册聚焦前三条主线——对象与构造：菜单从何而来（CreateMenu → InsertMenuItem → SetMenu 链），对象内部长什么样，如何被查

在 Win32 中，每个窗口都有一个窗口过程（WNDPROC），窗口收到的每条消息都会先进入该过程。窗口过程通常只处理自己感兴趣的消息，其余消息必须调用交还给系统处理。是整个窗口系统的"兜底"：它实现了 Windows 对每条消息的标准默认行为WM_CLOSE→ 销毁窗口；WM_SETTEXT→ 保存窗口标题并重绘标题栏；WM_NCPAINT→ 绘制非客户区（标题栏、边框、按钮）；→ 用类背景画刷填充客户区；→ 执行最小化/最大化/关闭/移动/缩放等系统命令；

窗口管理的全部行为都由消息驱动：窗口是对象，消息是方法调用，消息循环是解释器。分册 _8（msgqueue.c）回答了"消息存放在哪里、如何被唤醒"；应用程序如何把消息从队列里取出来（GetMessage/PeekMessage）、如何把键盘消息翻译成字符（TranslateMessage）、如何把消息交给窗口过程执行（DispatchMessage）、以及消息如何被异步投递（PostMessage）或同步发送（SendMessage）。本册围绕取消息→→。

消息队列是 Win32 窗口系统的心脏。窗口是一台状态机，它的"输入"就是消息；而消息队列（）是消息从"产生方"流向"消费方（线程的消息循环）"的中转站。在 ReactOS 中，消息队列完全由内核（win32k.sys 的 ）实现：每个 Win32 线程（，pti）关联一个消息队列，线程通过 / 系统调用从队列取消息，通过 / 等向（自己的或别的线程的）队列投递/发送消息。消息按产生方式分为三类，对应队列中的三条链表：三类消息的语义差异：队列的"有没有消息"这一状态被聚合成 QS 位（queue stat

窗口管理的全部行为都由消息驱动：窗口是对象，消息是方法调用，消息循环是解释器。分册 _8（msgqueue.c）回答了"消息存放在哪里、如何被唤醒"；应用程序如何把消息从队列里取出来（GetMessage/PeekMessage）、如何把键盘消息翻译成字符（TranslateMessage）、如何把消息交给窗口过程执行（DispatchMessage）、以及消息如何被异步投递（PostMessage）或同步发送（SendMessage）。本册围绕取消息→→。

消息队列是 Win32 窗口系统的心脏。窗口是一台状态机，它的"输入"就是消息；而消息队列（）是消息从"产生方"流向"消费方（线程的消息循环）"的中转站。在 ReactOS 中，消息队列完全由内核（win32k.sys 的 ）实现：每个 Win32 线程（，pti）关联一个消息队列，线程通过 / 系统调用从队列取消息，通过 / 等向（自己的或别的线程的）队列投递/发送消息。消息按产生方式分为三类，对应队列中的三条链表：三类消息的语义差异：队列的"有没有消息"这一状态被聚合成 QS 位（queue stat

创建窗口对象（window.c，分册 _1）、注册窗口类（class.c，分册 _2）、摆放窗口并决定可见性（winpos.c，分册 _3）、按 WM_PAINT 协议把内容画到屏幕（painting.c + windc.c + vis.c，分册 _4/_5）、绘制非客户区（nonclient.c，分册 _6）。分层窗口（layered.c）：一种不走 WM_PAINT 协议的"特殊显示"路径。窗口内容不是由应用在 WM_PAINT 里画到窗口表面，而是应用直接提供一个源 DC 的内容。

│ 非客户区：WS_THICKFRAME 粗边框（可缩放） ││ │ 非客户区：标题栏（Caption） │ ││ │ │ 图标 │ │ 窗口标题文字 │ │━ ││□ ││✕ ││ ││ │ 非客户区：菜单栏（Menu Bar，WM_NCCALCSIZE 计入） │ ││ │ 客户区（Client Area，WM_NCPAINT 之上） │ ││ │ │ ││ │ （应用程序自由绘制区域） │ ││ │ │ ││ ││ 非客户区：WS_HSCROLL 水平滚动条 │客户区。

CreateWindowEx → IntCreateWindow（窗口对象）→ ShowWindow / SetWindowPos（winpos.c：可见性、Z 序）→ IntInvalidateRect / RedrawWindow（painting.c：累积更新区域 hrgnUpdate）→ GetMessage 收到 WM_PAINT└── UserGetDCEx（windc.c：取窗口 DC，DCE 出队/入队）

创建窗口对象摆放窗口并决定可见性把窗口内容画到屏幕上前两件事已在分册 _1~_3 中阐述，本册讲述第三件事——窗口绘制协议。Windows 的窗口绘制不是"系统直接重画"，而是协议式系统只负责记账：当窗口的某部分"脏了"（被遮挡、被移动、被应用显式标记），内核把该部分累积进窗口的更新区域hrgnUpdate，并通知消息队列。应用通过消息循环收到 WM_PAINT，调用BeginPaint取得窗口 DC 与"需要绘制的矩形"。应用用 GDI 在该 DC 上绘制，最后EndPaint结束。

winpos.c是 win32k.sys 中负责"窗口几何状态"的模块：窗口的位置、大小、可见性、Z 序、最小化/最大化状态全部由它管理。它对外导出十多个NtUser*系统调用（用户态 user32.dll 的ShowWindowMoveWindow等 API 的最终落点），对内提供co_WinPos*系列函数供 win32k 其他模块（window.c、menu.c、focus.c 等）复用。│ 应用程序 (应用) ││ NtUser* 系统调用│ ││ │ │ ││ │ │ ││ ▼ ▼ │。

窗口类（Window Class）是 Win32 窗口系统"模板复用"的基石：应用程序先用注册一个类（窗口过程、样式、图标、光标、背景画刷、附加字节等），然后反复用按这个模板创建任意多个窗口实例。一个类的全部信息在内核中凝缩为一个CLS对象，挂在进程（或桌面）的类链表上；每个窗口的WND对象里则保存一个指向所属类的指针pcls。用户模式 (user32.dll) 内核模式 (win32k.sys)

本册聚焦"窗口对象"与"窗口创建/销毁"。窗口对象（）是 win32k USER 子系统中最核心的内核对象：每个 Win32 窗口在创建时于桌面堆中分配一个 结构，通过 USER 句柄表获得一个 ，并在窗口树（父子/拥有关系）与线程窗口链表中占据位置。 是这一过程的"主战场"。 的完整调用链如下：对称地，窗口销毁调用链：1.1 本册范围窗口对象的分配、初始化、挂接、释放（ / ）窗口树（父/子/拥有者）与 Z 序链表（ / ）窗口创建/销毁两条完整流程窗口句柄解析族（ / / ）窗口属性

ReactOS 的窗口系统位于（Win32 子系统 USER 半边），是win32k.sys内核模块中与 GDI 平级的另一大组成部分。GDI 负责"画"，USER（窗口系统）负责"管"——管理窗口、消息、输入、桌面、菜单、剪贴板等。win32k.sys目录下的 USER 内核实现，处理所有NtUser*系统调用。user32.dll。

0x10000// 65536 个表项（ntgdihdl.h）20*/// 表必须位于结构开头以便映射！用户态视图（gdi32.dll 使用的）定义于 [ntgdihdl.h](file:///d:/reactos/win32ss/include/ntgdihdl.h#L244)，布局与之完全一致（注释明确要求"Must match win32k/include/gdiobj.h"）。Entries数组必须是结构体的第一个成员——因为该结构被映射进进程地址空间后，直接指向。

系统库存对象是 GDI 在会话启动（win32k.sys 加载）时预先创建好的一组"全局共享、永不删除"的基础 GDI 对象——包括标准画刷（WHITE_BRUSH、BLACK_BRUSH……）、标准画笔（WHITE_PEN、BLACK_PEN……）、系统字体（SYSTEM_FONT、DEFAULT_GUI_FONT……）、默认位图（DEFAULT_BITMAP）与默认调色板（DEFAULT_PALETTE）。特性说明全局共享所有进程、所有线程共用同一份对象，对象属主为PUBLIC。

接口标准化：它把"像素格式"这一 OpenGL 窗口概念以三个系统调用（）暴露给用户态，是 gdi32 → opengl32 → 显示驱动 DDI 之间唯一的内核收口；惰性缓存把"设备支持的格式总数"缓存进 DC（ipfdDevMax），避免重复陷入驱动；窗口表面桥接通过拿到 WNDOBJ 与psoOwner表面，把 OpenGL 操作落实到窗口的底层表面，并将 HWND/WNDOBJ 交给驱动回调；可选 DDI 适配：三个回调均为可选（

4 个入口（ALT DC 底座）、（创建内核元文件对象）、（读取内核元文件数据）、（未实现桩）；1 个私有结构（BASEOBJECT + iType/mm/xExt/yExt/cjData + 尾部数据），数据与结构一体分配；核心价值：为剪贴板提供"跨进程、带标签、整块快照"的元文件数据容器，配合 gdi32 的系列完成 EMF↔WMF 双向转换；真正的元文件语义在 gdi32：录制由 mfdrv（MFDRV_* → METARECORD），播放由。

pen.c 虽然只有约 516 行，却是整个 GDI 线条绘制的起点统一模型，画笔就是"用于画线的画刷"。颜色放在样式放在，宽窄由lWidth决定；双入口（简单笔）与（扩展笔）最终都汇聚到，后者完成对象分配（老式/扩展两种 GDI 对象类型）、三层参数校验（端帽/连接/类型）、线型样式分发（内建静态数组或用户数组）与flAttrs标记；安全边界：用户样式数组在内核用+ SEH 复制到非分页池），所有权随对象移交、析构时按区分释放；查询对称按返回LOGPENEXTLOGPEN并被。

├─ (DC_PERMANANT) UserReleaseDC(NULL, hdc, FALSE) → TRUE/递归强制└─ 引用计数归零├─ ENTRY_vPushFreeEntry (句柄表条目回收)├─ DC_vFreeDcAttr ① 属性池├─ DC_vRestoreDC(pdc, 1) ② SaveDC 栈├─ DC_vSelectSurface/FillBrush/LineBrush/Palette(NULL) ③ 解选。