geelaw

随便看了一眼，只能说非常业余而且模型可能选得也是一团糊。就拿 native_preview 里一些 COM 、WinRT 、快捷方式的处理来说吧：

GUI 线程的 COM 、WinRT 必须选择单线程套间，尤其是 CLSID_ShellLink 等 shell 相关的对象，它们仅支持 STA 。仓库代码使用的是 MTA ，这会有两种可能的结果，一是初始化为 MTA 的时候失败（因为线程已经处于 STA ）并被静默忽略，二是初始化为 MTA 成功，然后建立 ShellLink 对象的时候自动建立新 STA 线程并封送之后每一个 COM 调用。

结果：比 Explorer 慢。

然后就是检查文件是否是快捷方式的代码，是查看扩展名是否为 lnk ，这当然是完全错误的，正确做法是使用文件关联查询 API 。

Ctrl+Shift+V 是 cooked input 粘贴，特点是程序在输入完一行后才会看到这一行的输入，程序看到了 n 次输入，每次一行，程序决定每行结束后做什么。例子：

PowerShell 里面 Ctrl+Shift+V 粘贴

write-host 1;
write-host 2;<# 此处没有换行 #>

会导致 PowerShell 执行第一行并停在第二行末尾。而 C+S+V 粘贴

&{write-host 1;
write-host 2;}<# 此处没有换行 #>

会导致停在第二行末尾。而粘贴

&{write-host 1;
write-host 2;}
write-host 3;<# 此处没有换行 #>

会导致 1 、2 运行，停在第三行末尾——即使第一行是一次性输入的，PowerShell 也不会执行，因为累积的输入不构成语句。

————

要诊断楼主的问题，可以从观察以下几点入手：文本是用 CR 还是 LF 还是 CR LF 换行？程序采用 raw input 的时候粘贴（通常这类程序会识别 Ctrl+V ），是什么效果？硬回车的位置是否有其他特征，例如字数、累积内容的语义？ A 篇手敲进去的时候，是否在 1 、2 行末尾程序会继续等待输入，并在第 3 行末尾开始处理？

@geelaw #10 “滚动纹理” => “滚轮纹理”，滚轮的纹理见此图：

https://www.reddit.com/r/MouseReview/comments/qg80b9/looking_for_a_lightweight_mouse_with_leftright/

我认为正确的方向：

1. 触控拖动内容的时候，手向方向 n 移动导致 -n 方向的内容进入视野。（“拽纸”模型）
2. 触控拖动滚动条、滚动条指示器的时候，手的移动导致滚动位置的移动，向 n 方向移动导致 n 方向的内容进入视野。（“拽指示器”模型）
3. 万向滚轮，滚轮的移动方向是滚动条、滚动条指示器的移动方向。（“转动眼球”模型）
4. 滑动滚轮，滚轮向远离人的方向旋转，则滚动条向 **阅读开始的方向** 移动。（在上下滚动的内容里，同于“拽指示器”模型）

请注意第 4 条的含义：

- 对于纵向滚动内容，向远离自己的方向旋转滚轮时，更上方的内容进入视野；
- 对于横向滚动的内容，远离自己的方向可以代表左或者右，取决于内容是 LTR 还是 RTL 。

目前已知的是 Windows 在 LTR 模式下符合这四条规则，我没有测试过 RTL 。另外 iOS 的触控符合前两条。

至于为什么第 4 个是正确的，实际上你可以发现传统 UI 里面“滚动条指示器”的样式是矩形 + 中间有条纹装饰，见

https://www.reddit.com/r/coolguides/comments/joszyg/evolution_of_a_scroll_bar/

例如 System 7, Mac OS 8, Windows XP/Vista （在 NeXTSTEP 里面则是中间有个点），这里面的“条纹装饰”实际上是滚动纹理的拟物表现，说明滚动条指示器指示的是滚轮的位置。如果把滚轮想象成“平铺”的状态，那么向远离自己的方向滚动，会导致手挪动到更前面，因此应当对应指示器靠上的位置。

能把 L 的小写误打成 i 的大写我只见过两个地方……

一是百度贴吧数学吧里有些帖子把 ln (自然对数) 写成 In ，这是至少 10 年前看见过的。

二是有人把 lgbt 打成 Igbt ，这是今天在 Twitter 上看见的。

你看到的第二个工具叫做“资源监视器”，“资源管理器”是指 explorer.exe 的窗口 UI 。

资源监视器：
正在使用 = 工作集（进程经常访问的内存，存在于实体内存中，“完全”占用）
已修改 = 脏冷页面（距离上次进程访问已经很久，但自从上次写入页面文件后修改过，因此必须先重新写入才能挪作他用，算“半占用半不占用”实体内存）

任务管理器：
使用中 = 工作集 + 脏冷页面

至于为什么要这么设计，这得问微软，但我的想法是任务管理器是初级工具，资源监视器是高级工具，因此前者没有那么细分。

对 .lnk 的解析错误，其图标和指向的文件没有任何关系，正确的做法是 IShellLink(A/W)::GetIconLocation 。此外 .lnk 当然不一定指向文件，比如上传“控制面板”的快捷方式会提示无法解析绝对路径。有趣的是，即使上传的是“命令提示符”的快捷方式，也会出现无法解析，怀疑可能是不支持环境变量展开。

@Need4more #9 任何以 Win32 为受支持目标的应该都可以，试了一下 mingw-w64 gcc 15.2.0 (Compiler Explorer / Godbolt) 的 SDK 比较旧，把 EVENT_OBJECT_UNCLOAKED 替换为 0x8018 之后是可以的编译成功的。

@loading #6 “不是直角”的原因单纯是 AI 写出来的是乱七八糟的：

- EVENT_OBJECT_SHOW 是 0x8002 ，而 0x8003 是 _HIDE
- EVENT_OBJECT_UNCLOAKED 是 0x8018
- DWMWCP_DONOTROUND 是 1 ，而 3 是 DWMWCP_ROUNDSMALL
- DWMWCP_ROUNDDEFAULT 不存在，正确的名字是 DWMWCP_DEFAULT ，这个数是 0
- 处理所有当前窗口的回调里面过滤莫名其妙，尤其是取消设置的时候，无论窗口是否最小化都应该重设
- if not hooks 语义错误，因为 hooks 是列表，只要安装了一个就会认为成功
- 取消设置的逻辑错误，一般地，没有办法取消，因为每个进程自己也可能调用 DSWA 来控制自己的窗口要怎么圆角