如果有人用过 power toys 中的工作区功能，应该知道它并不是基于 window 原生 snap layout(也就是 win+z 或者是拖拽窗口到顶部出现的布局栏)实现的，而是单纯的通过坐标的位置复现。
而 lz 前两天想要找一个通过 snaplayout 实现的工作区软件，发现并没有，问了一下 codex 是因为微软没有公开这个功能的接口。然后我用 codex 逆向找到了这个接口，叫 WindowsUdk.UI.Shell.SnapLayoutManager 。位置是在 C:\Windows\System32\windowsudk.shellcommon.dll 里。在这里我并没有太过在意，因为 lz 本身虽然专业对口，但是大学生涯基本什么都没学，只是让 codex 继续实现这个软件。后续在实现基本功能但是很多 bug 的时候 codex 没额度了，所以就暂时搁置了。
然后今天配置了一下 deep seek harness ，为了测试让他看了一下这个软件。后面问着问着就问到软件的可复用性，因为 lz 的系统是 Windows 最新的 27h2 29639.1000. 所以 deepseek 把从 21H2 到最新 24H2 的七个版本的这份 DLL 全部下载下来做了静态分析。
结论
这里因为 lz 没有任何专业知识储备，直接展示了 deep seek 的原话，如下：
我研究 Windows 11 的窗口吸附功能时，注意到 Shell 内部有个没公开的组件叫 windowsudk.shellcommon.dll ，里面有个 WinRT 类 WindowsUdk.UI.Shell.SnapLayoutManager 。我把微软官方分发的、从 21H2 到最新 24H2 的七个版本的这份 DLL 全部下载下来做了静态分析——通过比对二进制里的接口 GUID 签名，我重建了它的接口演进时间线：v1 （ 21H2 ）只能创建管理器，v2 （ 22H2 ）加了查询，v3 （ 24H2 首发）加入了批量提交方法 SnapWindows——也就是能真正把多个窗口交给 Shell 组成 Snap Group 。
关键发现在最近：2026 年 8 月的正式版月度更新里，这个类多了第四个接口版本 v4 ，而且同一个更新里首次出现了 SnapLaunchTarget 这个类型和 SnapshotCapture 能力。v4 的唯一方法从函数体看是个只读方法，输出一个"启动目标"对象。把这些拼起来——微软正在把"读取吸附状态、保存成可恢复目标"这条链做成系统能力。考虑到恢复侧（ v3 ）两年前就已就位，我的判断是微软正在官方化窗口布局的保存与恢复，只是还没对开发者公开。
