很久以前写过一篇文字，记录了当时采用 WinNUT 作为中继，以群晖本身作为 UPS 服务器，向局域网中的其他设备提供自动关机服务。
几年后的今天（实际上是2024年），公司又买了一台威联通（QNAP）的 NAS。由于 UPS 还是只有那一台（APC Back-UPS 650），且群晖和威联通在连接网络 UPS 服务时，使用的账号密码是不同的，虽然也可以通过硬改配置文件来勉强使用，但存在系统更新后被覆盖失效的风险。
经过一点研究，最终决定采用树莓派 Zero 作为 NUT（Network UPS Tool）服务器的方法为两台 NAS 提供网络 UPS 服务。
继续阅读 “Day 7427 使用树莓派作为 NUT 服务器，同时为群晖和威联通（QNAP）NAS 提供 UPS 服务”
这是 Gemini 的作品，但是感觉好像还挺有用的，留个备份。
# 1. 获取当前目录的完整路径
$currentPath = $PWD.Path
# 2. 构造查询语句 (注意 Scope 的路径必须准确)
$query = "SELECT System.FileName, System.ItemPathDisplay FROM SystemIndex " +
"WHERE Scope = 'file:$currentPath' AND System.FileExtension = '.jpg'"
# 3. 创建 COM 对象连接索引库
$adapter = New-Object -ComObject ADODB.Connection
$recordset = New-Object -ComObject ADODB.Recordset
try {
$adapter.Open("Provider=Search.CollatorDSO;Extended Properties='Application=Windows';")
$recordset.Open($query, $adapter)
$longestName = ""
$longestPath = ""
$maxLength = 0
# 4. 循环遍历结果
while (-not $recordset.EOF) {
$name = $recordset.Fields.Item("System.FileName").Value
$path = $recordset.Fields.Item("System.ItemPathDisplay").Value
# 统计文件名长度（不含路径）
if ($name.Length -gt $maxLength) {
$maxLength = $name.Length
$longestName = $name
$longestPath = $path
}
$recordset.MoveNext()
}
# 5. 输出
if ($maxLength -gt 0) {
Write-Host "`n==============================" -ForegroundColor Cyan
Write-Host "检索成功！"
Write-Host "字符长度: $maxLength"
Write-Host "文件名称: $longestName"
Write-Host "完整路径: $longestPath"
Write-Host "==============================" -ForegroundColor Cyan
} else {
Write-Host "`n[提示] 在索引中未找到该目录下的 .jpg 文件。" -ForegroundColor Yellow
Write-Host "原因可能是：1. 目录未加入索引；2. 索引尚未构建完成。"
}
}
catch {
Write-Error "发生错误: $_"
}
finally {
# 释放资源
if ($recordset.State -ne 0) { $recordset.Close() }
if ($adapter.State -ne 0) { $adapter.Close() }
}
如上是佳能打印机在 Windows 下的 “打印机状态窗口”（Canon Printer Status Window）应用。初次安装佳能 LBP2900/2900+/3000 系列打印机驱动后，每次打印这个窗口都会弹出来提示打印进度。通常对于直连在本机的打印机而言，该窗口不会造成太大影响，
然而，这是一个编写于 2009 年的应用，十几年来，伴随着倒霉催的微软对打印服务子系统的 “修复”，该应用对于 Windows 共享打印机的兼容性逐渐下降，表现为弹出后卡死在“正在获取状态”，打印任务无法开始，虽然强行关闭后可以继续打印，但每次都这样操作未免难受。
2026 年以前，这个问题的解决方案是：当这个窗口出现时，如果在卡顿，就等它卡完，然后点击“选项-首选项”，将“显示打印机状态窗口”配置为“不自动显示”。然而 2026 年的当下，情况起了新变化：
最终，通过分析应用本身（CNAB4SWD.EXE）的 API 调用情况，找到了上述“不自动显示”的选项在注册表中的位置：
\HKEY_CURRENT_USER\SOFTWARE\Canon\CNAB4\打印机名称项\PSW
上述“打印机名称项”位置，如果是本地连接的打印机，通常是打印机本身的名称（如 Canon LBP2900）；如果是 Windows 网络共享的打印机，则为类似如下的项名称，请根据实际情况查看：
,,192.168.0.100,Canon LBP2900
在 PSW 项下，找到 Showing 项目（如果没有就新建一个 DWORD 32位值），数据值为 0。
退出注册表编辑器后，再次打印，应该就没有这个状态窗口出来烦人了。
碟片满足以下特征：
处理方法：
使用 Handbrake 进行抓取，会自动跳过无效的节目。
有一款叫 TxBench 的工具，可以在 Windows 环境下为磁盘进行测速、安全擦除、信息显示等操作，其中安全擦除功能调用了硬盘本身固件的功能，在启动前会为磁盘加上 ATA 固件锁，而如果由于断电等原因，安全擦除异常中断，会导致磁盘不可用，表现为磁盘在 OS 层面不显示（宛如没有这个硬件一样）、对任何 I/O 操作不响应等。
TxBench 在擦除前不会告知用户设置的固件锁密码，如果擦除异常中断导致硬盘被锁定，需要使用作者提供的工具移除密码。由于软件官网已经下线，感谢 Internet Archive 将这个工具保留了下来，可以在这里下载。
适用于接收器型号为 CU0019 的罗技鼠标接收器（见上图）和鼠标背面没有配对按钮的型号（M170、M171、M185、M186、M221等），不需要去下 Logitech Connection Utility，那个是给支持优联技术的鼠标用的。
一、将接收器插入 PC 的 USB 接口。
二、鼠标开关拨到 OFF 位置（记得装电池），先按住右键并保持不动（一直到配对完成为止），然后将开关拨到 ON 位置。
三、保持按住右键的同时，按一下鼠标的左键。
四、保持按住右键的同时，按一下鼠标的滚轮（中键）。
五、连接完成，尝试移动鼠标，应当已经可以看到指针移动了。
公司有一台采购于 2014 年的 DELL PowerEdge R720 服务器，由于各种原因，机房没有在机架上配备 KVM，于是每次出现需要到现场调试的情况（如进 BIOS 修改设置）都要扛一台有 VGA 输入的显示器过去，在不额外花钱采购的前提下，不论是什么背光的型号都又大又重。
某天在一次出现场之前，突然想到之前似乎看到过有 VGA 转 HDMI 的连接线，检索之后选定了山泽的 VH2024，并在去现场之前找了一台机器进行测试，可以“正常使用”，于是抱着一块小尺寸的便携屏美滋滋地去了机房。
然而，当实际到达现场后，发现除了极少数界面以外（例如启动过程中 Initializing firmware interfaces… 的无光标图形模式画面），大部分时间都是在画面一闪而过之后一直黑屏，甚至连 DELL 图形界面的 BIOS 设置和 Lifecycle Controller 都看不到任何画面，偶尔能打开便携显示器 OSD 画面的情况，输入信号显示为 0×0 的分辨率，给人的感觉是从源头上就出了问题。
顺带一提，由于 VGA 转 HDMI 是模拟转数字信号，芯片是主动模式，而 VGA 端子唯一有供电的 pin 9 是否存在无法确保，所以这种转换线缆都会再配一根从 USB 取电的线，本例中，这根供电线是接上了的，所以看不到画面并不是因为没有插供电。
从机房回来后，丧气之余将线缆拆开，发现其中起主要作用的是一颗 MS9288C 芯片。不过，虽然可以很简单地查到这颗芯片的出品方是安徽合肥宏晶微电子科技有限公司，但查不到任何该芯片的 Datasheet（可以查到一份手册，但上面没有关于支持的信号模式的相关信息）。
尝试去问京东客服，对方也只是山泽的销售人员，不清楚具体原因；向芯片出品方宏晶微发邮件咨询，被告知需要留下公司名称方可进行回访，算了算了.jpg
多方搜索后，在这个页面找到了采用同款芯片的产品，其配套说明书如下：
假设说明书上的内容不是乱写的，那么 MS9288C 所支持的输入分辨率包括：
很不巧的是，Legacy BIOS 使用的是 VGA 文本模式，其分辨率为 720×400，恰好不在支持范围内。
不幸的是，市面上销售的便宜转接头基本上都没有考虑过这个已经进了故纸堆的分辨率，能支持的基本上也只有 OSSC（Open Source Scan Converter，一款开源的视频信号硬件转换器，国内售价 500 元起跳）这类很贵的设备，而如果只是为了减轻去机房的负重明显就不太值得了。
结论就是，学费 40 元，扛台显示器吧，挺好的。
这里还有一篇文章讲述了类似的情况，比我专业多了，可以做进一步参考。
原文链接：https://devblogs.microsoft.com/oldnewthing/20060609-07/?p=30923
As we saw earlier, the “Add or Remove Programs” control panel used several heuristics to attempt to determine things like program size and frequency of user. Why did it bother doing this at all?
正如早先讨论过的，控制面板中的「添加/删除程序」使用了多种启发式的方式来判断应用程序的大小和使用频率。为什么它要做这种吃力不讨好的事情呢？
At the time the feature was added, disk space was not cheap like it is today. One of the problems users were having was running out of disk space and not knowing what they could safely delete. Thus was born the Disk Cleanup utility, which attempted to guide the user through various things that could be deleted in order to make disk space available.
这个功能最初上线的时候，磁盘空间不像如今这样廉价。用户需要面对的问题之一是磁盘空间不够用了，而又不知道可以放心地删掉什么东西。由此，「磁盘清理工具」诞生了，它会引导用户执行一系列操作来判断可以删掉哪些东西来释放磁盘空间。
In addition to cleaning up temporary files, you could also remove programs that weren’t being used. But how do you know which programs you weren’t using? (Maybe you were using a program without realizing it because it ran automatically.) And how do you know how much disk space would be recovered if you removed a program?
在删除临时空间之外，用户还可以删除不再使用的应用程序（来释放磁盘空间）。然而，用户如何判断有哪些应用是用不到的呢？（有些应用是自动运行的，所以用户可能根本没有意识到它的存在。）此外，用户又怎么能知道移除掉某个应用后能释放多少磁盘空间呢？
That’s where the program size and frequency of use heuristics came in. By providing this information (or at least trying to), the “Add or Remove Programs” control panel could help users decide which programs to remove.
这就是（「添加/删除程序」控制面板项中）应用程序大小和使用频率估算起作用的时候了。通过提供这些信息（至少是试着提供了），「添加/删除程序」得以帮助用户判断要删除哪个应用。
Of course, nowadays, with hard drives in the hundreds-of-gigabytes range, disk space has become so cheap as to be nearly free. The need to remove programs to make more disk space available is largely gone, but the feature remains as a vestigial organ.
当然，如今硬盘容量已按数百 GB 为单位计算，磁盘空间也（相对地）便宜到跟不要钱一样。通过删除应用程序来腾出更多磁盘空间的需求基本已经不存在了，但这个功能就像退化了的器官一样保留了下来。
原文地址：https://devblogs.microsoft.com/oldnewthing/20060525-04/?p=31073
In former times very cross-platform NTVDM was. If you view NTVDM.EXE in a hex editor, you’ll find the message “Using Yoda on an x86 may be hazardous to your systems’ health” buried inside it.
很久以前，NTVDM 的跨平台程度是非常高的。如果你在十六进制编辑器里查看 NTVDM.EXE 的内容，你会看到里面藏着这么一句话：“在 x86 系统上使用尤达大师可能对您系统的健康有害”。
Yoda was the name of the internal debugger that was used to debug the MS-DOS emulator, also known as the Virtual DOS Machine or VDM. (Buried inside the Yoda source code are such wonderful variables as “luke” and “chewy”.)
Yoda 是用来调试 MS-DOS 模拟器的内部调试器的名字，MS-DOS 模拟器又称作 DOS 虚拟机（VDM）。（在 Yoda 的源代码里还深藏着其它妙妙的变量名，比如 luke 和 chewy（译注：都是《星球大战》梗））。
The Intel 80386 has a mode known as “Virtual-8086 mode” or just “V86 mode” wherein the CPU ran as if it were an 8086, except that if the program did anything interesting like issue a privileged instruction, call a software interrupt, or fault, control would return to the protected-mode supervisor for handling. (Win386 used this same CPU mode to support multiple MS-DOS sessions.)
Intel 80386 处理器有个“虚拟 8086 模式”（或者简称为 V86 模式），在此模式下，CPU 将按照 8086（实模式）的方式运行，不过只要有程序试图执行如特权指令、软件中断或出错之类的行为，就会返回到保护模式的管理之下来处理这一切。（Win386 也使用这一 CPU 模式来支援多个 MS-DOS 会话。）
When running on an 80386-class processor, NTVDM used this mode to do its emulation, making the CPU do the heavy lifting of decoding instructions and emulating them, which took place at very close to full speed. On the other hand, NTVDM on the non-x86 processors (Alpha, PPC, MIPS, etc.) had to implement an entire 8086 emulator, with all the decoding and execution performed in software. Yoda was the debugger you used if you needed to debug the emulator.
当运行在 80386 级的处理器上时，NTVDM 使用虚拟 8086 模式来进行模拟工作，让 CPU 来承担解码指令、模拟行为之类的繁重工作，并且基本上可以全速运行。但另一方面，在非 x86 处理器上（如 Alpha、PPC、MIPS 等等）就要实现一整个 8086 模拟器，对指令的解码和执行工作完全依赖软件模拟。Yoda 就是那个用来调试这个模拟器的调试器。
And that’s why NTVDM has a message warning you not to use Yoda on an x86. Because on an x86, there is no instruction emulator. There is nothing to debug.
这就是为什么 NTVDM 里有一条警告不要在 x86 系统上使用 Yoda 的原因——在 x86 系统上并没有一个 x86 指令模拟器的存在，么得调试工作可做。
(My thanks to Andrew McLaren and Tony Gaston for providing historical background.)
（感谢 Andrew McLaren 和 Tony Gaston 提供历史背景信息。）
