可是逐步地，CPU 的短板还是被逐渐感知到了。更何况近些时来，大家热热闹闹地玩 AI，这个家伙不管是对 CPU 还是内存/GPU，都不会特别迁就。所以故技重施，先把办公室的干活儿主力机升了升格，从 Latitude 5401 升级到 Latitude 5431，再把退下来的 Latitude 5401 搬回家里来用（因为它也可以支持三硬盘）。不过比较讨厌的是，它已经不支持 BIOS/MBR 引导了，而且虽然没有实测，可直觉上其 m.2 插槽也不会支持 SATA 协议的 SSD 了。这就是说，现有的 T450s 上的三个系统，每一个都得换盘，不仅如此，还要视情况进行针对性的外科手术式迁移适配。

最先，也最顺利的是 Windows 10，毕竟咱有积累的经验打底。Ubuntu 的使用频度目前在家里不算高，因此暂时搁置。比较不好搞的是那份黑苹果。从以往的历篇博文也可以看出，在 T450s 上表现完美的Monterey 时至今日也已略显过时，而升级到 Sequoia 之后，本身在 T450s 上还算不得完美。历尽艰难，才把升级后遇到的无法登录的问题解决掉，而进入桌面后，陆续又发现一些使用上的毛刺。一是触控板驱动的不太对头，想触发点击操作，需要在触控板上连点两次；二是显示屏的亮度无法调节，这个情况应该是和显卡有关，理由是当我把这款盘从双显卡的 T450s 上平移到另一台只有核显的 T450s 上之后，调节亮度的控件就会正常出现；第三个问题也比较古怪，那就是如果把外置电池接上的话，系统引导的时候会卡死。基于这些，心想正好把黑苹果也干脆迁到 Latitude 5401 上就好了。

找了一块闲置的 m.2 的 SSD，用 DiskGenius 的磁盘克隆功能成功把原来 NGFF SSD 上的内容克隆了过来。需要说明的是，这份黑苹果目前面临着两个问题：1. 如何在 Latitude 5401 上才能引导起来；2. 它自身的状态与 Latitude 5401 是否能兼容。第一个问题的解决方法很标准，那就是在网络上找是否有现成的 EFI 被人分享了出来，幸运的很，确实有，在这里。不过在看作者的文档时，发现了一个之前少有的要求：需要使用技术手段微调这台本子的固件界面里不曾体现的选项。途径则是在 OpenCore 引导时，按空格键调出额外的引导项，进入到 OpenShell 控制台，按需执行 setup_var.efi 命令。要调整项的偏移和值文档中有现成的，但作者又提醒说，各人应该自行确认一下，以免失误导致设备变砖。于是三太爷不得不阅读 setup_var.efi 的文档，按步骤操作。首先去下载了 Intel 的 CSME System Tools 工具集中的 Flash Programming Tool（FPTW64.exe），执行 FPTW64.exe -bios -d bios-dump.bin 把设备当前的 BIOS 转储，然后使用 UEFITool 把所需的 Setup/* 节抽取出来，再用 IFRExtractor RS 把配置信息转为文本格式。最后打开转换后的文本文件，一一核对提及的需要修改的配置项的偏移，顺便把当前值记录下来，以便将来可能需要恢复回去。还好，所有的偏移均与 EFI 的作者列出的一致。

作为一个好奇宝宝，显然在修改之前必须尝试一次引导，以观察不修改的话会有什么后果。后果其实很直接：不能引导成功，会重启。老老实实修改后，引导进入到了 macOS 的安装器界面。令人痛苦的是，界面的文字非中非英，一眼看去像是俄文。为了后续的步骤可以看明白，总得把这个界面显示问题解决掉。问了 AI 若干次，也按照它的回复对 OpenCore 的 config.plist 调整了若干次，统统无效（例如在 boot-args 里加上 -apple-language en_US，并指定 SystemLanguage 等）。最后没辙儿了，拿出手机打开 Google 翻译，照着屏幕一看，翻译 app 判定显示语言为匈牙利语。靠着它，才发现第二菜单下的唯一下拉菜单项其实就是语言切换的入口，这样一来，引导问题算是基本搞定。

接下来就要尝试用这份 EFI 引导一下前面克隆完成的 SSD 上的 macOS Sequoia 了。把 SSD 插入插槽，用带着定制了的 EFI 的 macOS 安装引导 U 盘启动，结果是令人意想不到的失望，一而再再而三地重启，根本不能像之前那样进入到安装界面。后来不禁想，不会是 U 盘自己输了什么问题了吧，决定验证下。把 SSD 取下，用最简单的环境来测试，结果这次好了，又能进入安装界面（也是 macOS 的恢复界面）了。这下恍然大悟，看来是 SSD 在作祟。赶忙到搜索引擎里查询，果然有人早就警示：若干多的 SSD 与黑苹果相克，而老夫所用的海力士 BC711 赫然在列。好像说西部数据的好一些。

于是到闲鱼上查访，发现 SSD 这半年涨价的实在离谱，西数的 SN520，512GB 的竟然要 350 元上下（这还不算更离谱的标价）。要知道去年十月份，1TB 的 SSD 也就这个价。唉，黑苹果的迁移大业，先停停吧。

Microsoft Agent 是 Microsoft 开发的一项技术，允许用户与应用程序和网页内的动画角色进行交互。它使用文本到语音（TTS）引擎来允许动画角色与最终用户对话。这些动画角色被称为“Microsoft Agent”。从 Windows 98 开始，它就预装在 Windows 中。Microsoft Agent 持续与所有 Windows 版本一起发布，直到 2009 年的 Windows 7，此后 Microsoft 停止提供 Microsoft Agent。Microsoft Agent 的最新版本是 1998 年 10 月 12 日发布的 2.0 版。

Microsoft Agent 允许软件用户通过 Microsoft Agent 角色编辑器创建角色。微软在原始页面上制作了四个默认角色，包括精灵、梅林、皮迪和罗比。其他一些值得注意的角色是 1997 年至 2003 年 Microsoft Office 套件中出现的角色，包括 Clippy、Dot 或 Office Logo。Windows XP 搜索助手也是 Microsoft Agent，包括 Rover。另一个值得一提的 Microsoft Agent 是 Bonzi，一只紫色大猩猩，它与 BonziBUDDY 捆绑在一起，直到其停产。Bonzi 角色后来因其多个 meme 视频而成为 meme，随后受到了广泛关注，最后又因一名主播直播了 XP 损毁而导致 Bonzi 角色的受欢迎程度上升。

上述引言来自于一个围绕 Microsoft Agent 技术而创建的社区页面，比较全面地介绍了 Microsoft Agent 是什么这一命题。

对于国人来讲，最知名的一个 Microsoft Agent 其实应该是瑞星杀毒软件中的小狮子，尽管在后期，由于各种原因，把小狮子的展示技术迁移到了 Adobe Flash。由于小狮子的形象备受人民群众的喜爱，甚至有爱好者自行制作了不包含瑞星杀毒软件本体的独立的小狮子安装包，如果你想体验的话，可以到这里下载：瑞星小狮子独立版下载 – 非凡手机软件。

当对技术的追思到二这个份儿上的时候，老夫突然想把非 SWF 版本的原始小狮子找到再看看。这个工作稍微绕了点，因为首先就是要找一个更老版本的瑞星杀毒软件的安装包。当然功夫不负有心人，还是被俺找到一份：瑞星杀毒软件 2004 官方 PC 版免费下载-天极下载。下载解包后看到里面确实存在 RsAgent.acs，这就和记忆对上了。

acs 文件是微软的角色构建工具（可以在这里下载）生成的，而制作的原始素材会用到 bmp 位图文件以及 wav 音频文件。如果你想把现成的 acs 文件逆向恢复成素材集，最妥善的方法当然是去了解 acs 的文件格式，尽管微软官方并未公开，好在前人栽过这棵树的，可以参看这个链接。文档作者也写好了一个现成的工具，在这儿下载。

微软官方文档站里目前还有相关内存，可以在这儿参阅；一个简单的入门介绍文档可以参阅这儿。

有了这些，俺又不免想到，怎么在这新时代里，旧物利用一下儿呢？

前天的时候，想着这事不如小马过河一下，不能总是被别人现成的信息迷惑着。于是把一个在 Android 上从 Play 商店下载安装的 VPN app 的安装包导了出来。现在的安装包都被 Play 商店搞成了分割版本，语言、屏幕适配等资源都是独立的子包。把所有安装包都传递到鸿蒙 6 设备上，尝试安装。鸿蒙 6 会自动提示经由卓易通打开，但可惜的是，除了主包可以安装成功外，再安装其它几个子包都会失败。而单独安装成功的主包并不能正常运行起来。

后来又做了一点功课，找到一个叫做 AntiSplit M 的工具，它可以把 Play 商店的分割包在本地重组为单一包。这真是救命的稻草，于是来了这么一下子，再传到鸿蒙 6 里尝试安装，竟然就可以正常工作了。安装正常、启动正常、运行正常、功能正常。实话讲，一个为 Android 编写的网络层面的应用，能正常接管鸿蒙系统范围内的网络流量，这是三太爷一开始所没敢相信的，但它就是这样华丽丽地成了。

幸甚至哉，天还没全黑，且行且珍惜吧！

于是想着不行把 .sup 转换成 .srt 格式。找了找工具，说是 SubtitleEdit 有自带的 OCR 可用，下载了回来一看，它是集成了几个 OCR 引擎，按照用户的选择进行调用。老夫只能选用 PaddleOCR，因为只有它支持 Chinese，但是执行时总是失败，也没有错误信息。这个工具还有个在线服务，位置是 https://www.nikse.dk/subtitleedit/online，使用了一下，更神，直接连 .sup 字幕的上传都搞不定，别说转换了。这么档子事不值得深究，暂且放弃。

不过既然转到线上了，那就再看看是不是还有别家。另找到一家是 https://www.subextractor.com/tools/sup-to-srt。成功上传，成功转换，成功下载，播放器也确实能成功展示，只是——翻译的质量着实堪忧。看来还是再去老老实实找别人已经上传的现成 .srt 字幕更合适。

好几年前的时候，由于微软向系统中引入的 Sets 功能一再跳票，遂决定入手一份 Groupy。这个软件由 Stardock 公司出品，其主要作用就是提供了运行的应用窗口分组整理的功能。看中的就是它功能单一，个头也不大。只是价格不便宜，比来比去，发现 Steam 上的价格算下来是最优惠的，所以注册了 Steam 账户，充了一点美元进去用于买软件。又过了些时候，发现 Groupy 2 发布了，但是 Steam 里没有提供升级途径，而是需要再次购买，价格 $9.99，常年不变，而老夫账号里的 $9.97 的余额，也就只能长年望洋兴叹。

昨天说到此处，兜哥突然说，这几天可是圣诞季，说不定有优惠。一句话点醒梦中人。连忙打开 Steam 客户端，发现果真如此，目前是七五折。正要下单时，兜哥又得陇望蜀，说别急，在看看国区的价格，说不定更便宜。一查果然，才人民币 ￥26.25。尝试先转区，把余额转成人民币后购买，结果转区一直因为网络问题而失败。最后只好直接购买，支付时选择国内的支付方式，同时触发转区。这样操作下来，结果是支付宝付款后，原来的美元余额才转为人民币余额。

这些前在里面放的时间也不短了，趁机看看还有没有性价比高的东东能买。想起了同一开发商的 Fences 产品，它是为桌面图标提供分组管理功能的。看了一下，也有优惠，但是折扣之后的价格可也不算便宜，要 90 多。思忖了一番，最终还是下单了，补足了 ￥21.6 的差价。用了几分钟发现，其提供的功能有的是不太满意，有的是画蛇添足，遂又发起了退款申请，一觉醒来，退款完成。

今早又想，既然 Fences 不合适，不知有无同类开源产品可以体验的？到 GitHub 上检索，还真有，抛去几个几乎无人问津的项目（不过更新时间倒是挺近的），有这么几个：

• limbo666/DesktopFences: An alternative to Stardock Fences. Open Source
• PinchToDebug/DeskFrame: Organize your desktop into frames
• chrisdfennell/OpenFences: OpenFences – a lightweight, open-source WPF app for Windows that lets you group desktop icons into movable “fences.” Create/rename fences, drag files to auto-create shortcuts, minimize to tray, toggle desktop icons, and one-click Auto-Import that sorts your desktop into Apps, Documents, and System fences.
• Twometer/NoFences: Open Source Stardock Fences alternative

NoFences 虽然被我列在最后，但似乎它具有一定的知名度。从它的 issue #69 中可以知道，它显然是把图标的“副本”纳入到自己的数据管理范畴之后，就不去顾及 Windows 系统桌面上原本的图标本身了。这是一个偷懒的方法，当然了，这与开发者的技术能力以及目标有关。从技术上来说，桌面图标处于 Explorer 进程内，另一个程序跨进程去管理它们，确实是有难度的，更何况，即便就从数据本身来说，出了最常见的快捷方式，还有 shell object 需要处理，后者涉及到的编程模型和技术更加复杂。事实上，前面我说到的那几个“抛去的无人问津的项目”，基本也都是 NoFences 这个路子。

经过实际使用测试，Desktop Fences 也是这样，OpenFences 也是这样，DeskFrame 也是这样，全军覆没！要不将来老夫动手写一个？

在检索过程中，还发现一个用 Qt 技术栈为 Linux 实现的 类 Fences 项目，同一个作者。先后写了两版，具体原因别问，问俺也不知道。先头一版是 https://github.com/Yue-Lan/Fences-for-Linux，后一版本是 https://github.com/Yue-Lan/desktop-file-memos。此处仅做存档，没有下载、试用过。

Windows 上进程的权限

Privexec 使用指定的权限级别运行程序。在 Windows 上，程序的权限级别可分为如下：

• TrustedInstaller 可信安装，此权限属于 Windows Modules Installer service (TrustedInstaller.exe)，常用于 Windows Update 和 Windows 资源保护。
• System 本地服务权限。
• Administrator 管理员(组)权限
• Not Elevated 标准用户权限
• Mandatory Integrity Control 低完整性
• AppContainer UWP/Store APP 权限

在 Windows 上，可能存在一些需求，比如在管理员权限获得 System/TrustedInstaller 权限去做一些事情（一帮不建议这么做）。也有可能以较低权限启动进程，或者实现进程权限从管理员降低到标准受限用户（这个建议）。还有一些，用于对 Windows 做安全分析，比如启动一个 AppContainer 进程，然后研究 Sandbox 逃逸机制。等等。

Privexec 的特性

Privexec 这个工具，自身以管理员权限运行时，可以启动 System/TrustedInstaller 权限进程，以标准用户启动时常常用于启动 AppContainer 进程。

在 Windows 8/8.1/10 中，应用商店，UWP 进程都是使用 AppContainer 隔离，当你启动 UWP 程序后你可以使用 Process Explorer 或者 Process Hacker 去分析进程的权限信息。

Privexec 能够支持在 以 AppContainer 启动 Win32 进程，并且支持 LPAC, 也就是 Windows 10 新增的 Less Privileged AppContainer

App Container has access to resources protected with ALL APPLICATION PACKAGES SID: This SID has read permission on all folders by default. LPAC is a more restricted version of the App Container. it denies access by default for everything. One can access only the secured objects that are granted explicitly to LPAC.

开启了 LPAC，你如果没有 lpacCOM，COM 对象都无法调用。LPAC 借鉴了 Google Project Zero sandbox-attacksurface-analysis-tools

管理员权限：

启动 AppContainer 进程：

Privexec 支持命令别名：

命令行版本：

关于在 Windows 上以不同权限启动进程的原理有相应的博客：Privexec 杂谈

Privexec 主要用在 Windows 10 上，故代码仅支持 Windows 较高版本，建议至少是 1803 或者更高。

下载 CI 构建的 64bit: https://ci.appveyor.com/project/fcharlie/privexec/build/artifacts

许可证 MIT。

类似工具

1. NSudo – A Powerful System Administration Tool

NSudo 主要擅长权限开启，Privexec 更擅长 AppContainer。NSudo 知名度更广，Privexec 基本只有少数人知道。

其他

Process Hacker 推荐下载 Nightly (v2 比较陈旧，有些特性未支持)：https://wj32.org/processhacker/nightly.php

Privexec 安全论坛上的介绍：https://www.wilderssecurity.com/threads/privexec-run-the-program-with-the-specified-permission-level.410734/

在评论区，还有人提到了 AdvancedRun，能把权限级别当配置文件保存。

不过凡事有一般，那通常也就意味着会有二般，只不过概率会低一些。设想一个场景。假如写了一个新的语言，为了让能在 Windows 下为开发者提供直接使用 Windows 平台 API 的能力，你可能就不得不把 Windows.h 这个头文件拉出来，把其中的大量常量宏定义、结构体或者函数别名的宏定义等等解析出来，转换成你自己的语言的对应形式的声明。

好在对于这些“二般”的“偏航”需求，也有前人做了相关的工作的。

有个项目叫 unifdef，主页在这儿：https://dotat.at/prog/unifdef/。它称自己为“selectively remove C preprocessor conditionals”，GitHub 上的代码库地址则在 https://github.com/fanf2/unifdef。

无独有偶，还有另一个项目，使用 Python 语言写就，主页设计得还要更美观些，叫 pcpp，主页在 https://pypi.org/project/pcpp/。当然在 GitHub 上也有自己的一席之地，在这儿：https://github.com/ned14/pcpp。

有需要的小伙伴们自取所需吧。

出于各种各样的需要，有时候用户可能想选择性下载某个机型的 BootCamp 驱动合集，而不必非要借助于已经安装成功的 Windows 系统中被苹果植入 BootCamp 工具，于是催发了一些第三方工具的诞生。

有个图形化工具叫 Bombardier 的，可以用来执行这一任务。它会列出可供下载的机型列表，由用户选择后进行下载。它正常发挥了 GUI 程序的优点：直观且操作简单。这是一个开源项目，使用 Swift 语言写就，其官方地址在：https://github.com/ninxsoft/Bombardier。当你打开这个地址后，你会发现该项目已经归档，这通常意味着原作者不会再对它进行后续的维护和更新了。

另外还有一个工具叫 Brigadier，官方地址位于 https://github.com/timsutton/brigadier。它与前述的 Bombardier 功能类似，不过它是脚本工具，用 Python 写就，对命令行选手更加适合一些。令人略微惊讶的是，它比 Bombardier 出现得更早，但最后更新的时间更晚一些。

如果真要遇到这样的需求，GUI 模式的 Bombardier 应该还是首先尝试的选项，实在有问题的话，不妨再试 Brigadier。

下午打开 WSL 里的 Ubuntu 18.04 LTS，要编辑一个 Python 源文件时突然就想试一下这个重生版的工具，于是到官方分发页面下载了下来，准备享受一番。解压缩就来了一次暴击，压缩包是个不常见的 zst 格式，原以为 tar 可以直接解决，但试过发现不行。只好先 apt install zstd，成功后用 zstd 解压。把得到的单文件 edit 移动到 /usr/bin 里执行，报错。

[crayon-69d545d1dbf2a734588956 inline="true" ]./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./edit)

看了下系统内的 libc.so 的情况，版本是 2.27，正好差着一点。给系统升级这个重量级的 so 不是没有可能，但是风险较高，实在犯不上。正好前两天清理系统盘的时候，把 WSL 里那份不用的 Ubuntu 20.04 LTS 卸载掉了，不行就把当前的这份升级到 20.04 吧。

执行 do-release-upgrade，报错，信息的最后一句很明确：ModuleNotFoundError: No module named 'apt_pkg'。听了 AI 的劝，执行了 apt install --reinstall python3-apt python3 python3-minimal 和
apt install -f 之后就好了。所谓的好了，就是 do-release-upgrade 命令可以执行了，而不是执行完成了，继续报错：

[crayon-69d545d1dbf2e044564464 inline="true" ]Reading cache
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.

Checking package manager
Reading package lists... Done
Building dependency tree
Reading state information... Done
Hit http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit http://archive.ubuntu.com/ubuntu bionic InRelease
Hit http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Fetched 0 B in 0s (0 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done

Restoring original system state

Aborting
Reading package lists... Done
Building dependency tree
Reading state information... Done
=== Command detached from window (Mon Aug 11 18:33:29 2025) ===
=== Command terminated with exit status 1 (Mon Aug 11 18:33:39 2025) ===

AI 又说了，你要打开 /etc/update-manager/release-upgrades 文件，找到 Prompt=lts，在它前面添加以下两行：

[crayon-69d545d1dbf31881142444 inline="true" ]CheckPCI=no
CheckUSB=no

然后执行 do-release-upgrade -f DistUpgradeViewNonInteractive，再次失败。

无奈之下，先把 /etc/apt/sources.list 做了个备份，将其中的 bionic 全部替换成了 focal（sed -i 's/bionic/focal/g' /etc/apt/sources.list），然后执行了 apt update 和 apy full-upgrade -y。完成后重新打开 这份 WSL 实例，果然升级成功，libc.so 的版本升到了 2.31。于是满心期待地执行了 edit，呜呼呀，怎么界面看起来像是 VI？连退出的命令都没错，显然又有乌龙发生，应该是升级后的系统把 /usr/bin/edit 给覆盖了，八成成了 vim 的符号链接。

于是又把 edit 解压一次，这次执行就没问题了吧？嘿，报错：

[crayon-69d545d1dbf33216231645 inline="true" ]./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./edit)
./edit: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./edit)

除了把一行 2.28 的 glibc 找不到的信息消失了以外，涛声依旧。感情就是消遣俺来着。老夫还是先缓缓吧。

讨论链接为：https://github.com/CLAY-BIOS/Lenovo-ThinkPad-T450s-Hackintosh-OpenCore/issues/137；

下载链接为：https://drive.google.com/file/d/1Wi4aq5cRqrWG0htYbBOUXW5_Mi7UpBTj；

是为备用。