找到一个现成的项目，很老很老了（当然 Bambook 本来就很老很老了）：https://github.com/zhanzushun/Bambook-Factory。

另一个看着也有关，先列到这儿：https://github.com/quake/BambookPlugin。这里的 bambook-sdk 看上去是官方的，就是不知道版本是不是最后更新的。

还查出来当年盛大的一个技术人员（似乎就是 SDK 团队的？）的一篇文章：《开发应用程序 白拿 Bambook》。

SDK 的下载就得到互联网历史博物馆里翻腾了https://web.archive.org/web/20140904082059/http://bbsdk.sdo.com/download_sdk.do。只可惜，有链接，没有文件了，例如 C++ 的最终版本真实链接是 http://static.bbsdk.sdo.com/sdk_src/BBSDK_0.9.7.0_CPP.zip，这顶多知道个文件名。

• 移除之前的登录用户信息；
• 清除掉所有发现的需要在线使用的功能入口（登录、更新、分享、推荐、天气等等）以及大部分弹框提示（如果不是全部的话）；
• 文案精校，对大部分交互过程中的中文文案进行了校对和大量格式修正，甚至包括深藏于启动画面和锁屏画面中的提示语；把无用的一些其它语言的资源进行了彻底清理；
• 功能缺陷的修复，例如进入已读完的类别后，方便快速地切换回书架；
• 内核缺陷的修复，例如在某些高版本 Windows 系统上会发生 USB 连接后无法建立 adb 连接；
• 恢复可以 adb install 命令直接安装 app 的能力；

在以上工作完成后，又特意制作了干净的可供后续作为原始刷机源的映像备用。

原本还计划装个浏览器的，后来考虑到系统是 Android 2.2，而且硬件平台又是 MIPS，架构实在太老旧，遂打消此念。

那下一步做什么呢？倒是可以考虑把桌面端工具做一下，可以方便地管理书架/书籍。

在搭建好基本开发环境和写完第一个 demo 程序成功运行之后，便陷入了无尽的沉寂。说实话，Kindle 都懒得开机，更何况它。要想把它整治出俗，那可是相当大的一番工程。

这些日子又看到了在角落里吃灰的它，联想到这些天来 AI 已经在日常的工作学习中占据越来越大的比重，觉得也许 AI 能让它换发一下生机。

第一件事是让 AI 看看能不能精简一下系统。结论比较明确，原版系统本身就没太多额外的应用，精简的空间很小。第二件事则是让 AI 再看看能不能把已经无法使用的各种需要原厂商服务器的在线功能的入口都屏蔽掉，回答是可以。就在要让 AI 发力开始有成效的工作之时，魔幻来了，它突然不能通过 ADB 访问了，哈哈哈哈哈！

感觉就像是自己骤然迸发了求生欲，现象就是插入电脑，设备管理器显示正常，驱动也没问题，但就是连不上！截止发稿时，尚未恢复！接下来俺将尝试各种方法来拯救/折磨它，钦此。

那还是在上个世纪的九十年代，在学校一进大门的行政楼里，某个系的机房。花钱买的机时到点后走得匆忙，一张心头好的 3.5 吋软磁盘落在了驱动器里，待到想起来再去找，已然不见踪影。

磁盘里是一款软件，清楚地记得我在标签上还写着名字，叫“VP2”，它可以放音乐文件，声音很好听。尽管是 DOS 下的软件按，可它的界面是图形化的，而且是那种漫游形态的。简单点说，就是软件的界面其实比屏幕还要大，就像游戏里面的地图。它的界面宽度是做成和屏幕宽度一致的，因此只能上下漫游，从上到下它的界面做的很像当年高端大气上档次的组合音响，尤其是分频示波的小窗口更是令人印象深刻。类似的效果要到更往后，Winamp，以及更后一点的千千静听才再次能有所超越。

就这样，我失去了我钟爱的一张软盘，里面放着我钟爱的一款软件。几十年过去，虽然并非经常，但绝对不止一次想起它。终于在昨晚，向 AI 发出了协助请求。由于时间过于久远，AI 并没有给出非常确切的回答，但它给出了一个最佳推测，“Virtual Player”。实不相瞒，这两个单词也正是我之前一直认为应该是的名字，很可惜每次用它进一步搜索都无功而返。

可偏偏就是这次，有了结果。首先是找到一个 YouTube 上的视频，确认了长相，在这里：Visual Player 2.0, DOS MOD player, Big Psyco mode。然后又在另一处找到了下载链接，在这里（需要注册）：Download Visual Player 2.0 by Luis Crespo | VETUSWARE.COM – the biggest free abandonware collection in the universe。

尽管那充满颗粒感的界面已经远远不能够跟现在的图形系统相比较，但在得到这个结果的瞬间，老夫是欣喜的。然后开始自我怀疑，为什么以前没有找到？倒回头去看视频的时候，发现也仅仅是两年前才发布上去的。而且在 Reddit 上有一个 3 年前的提问，相当怀疑提问者跟我要找的是同一款软件。从这个帖子的回复里，才发现一个更古早的视频链接，里面已经有 VP2 的界面，但那个视频的曝光度几近于无。

除了软件名字以外，还回想起了它所支持的音乐文件的格式，MOD。我在给 AI 提问时仅能模糊地说大概是“MIDI”。从相关信息上看，MOD 似乎要优于 MIDI，而且需要 SoundBlaster 也就是曾经辉煌一时的“声霸卡”的支持，并非我之前印象里的 PC 喇叭（当然我怀疑它可能也优化了对 PC 喇叭的输出质量，仅怀疑，未验证）。这个对特殊硬件的某种依赖或者优化，也可能在某种程度上解释了当年我为什么会去一个其它院系的、一般我都不太会去的机房去上机。

在要关闭标签页的时候，看到前一个视频的视频主写的介绍里有这么一句话：I’ve been looking so long for this software! 可见吾道不孤，令人感慨唏嘘。

三十多年了，此番终结。

前几天出了一趟门，换一个地方无所事事，倒是每天有面吃。这个幸福虽说对健康无益，可毕竟实在是对胃口，或者说口味。

这么荒废的十天一过，今天又是驱使 AI 的一天。每每令人或开心，或恨铁不成钢，不过总体下来，它还是比一两个活人程序员更靠谱，也更勤快的。

上午兜妈说她的电脑打不开了，老汉过去盘查一通下来，换了个电源适配器，好了。把换下来的电源适配器继续排查，发现竟然是电源线坏了（应该里面有地方短路了），这种情况实在少见，所以不由得上来记一笔。过些时再找个三眼电源线来，就可以原地复活了。

前两天的时候，Windows 突然报系统盘空间吃紧，也许是跟最近颇为安装了几个 AI 工具有关，要知道现在的这些 AI 工具大部分都是把 Electron 作为核心技术栈来使用，打出来的包安装之后随随便便就得一两个 GB，空间消耗吓人。于是找来磁盘占用分析工具帮助分析，看哪些可以卸载掉。

当然了，HeyTapThemeEditor 就在清退之列。到系统设置里卸载它，可是每次执行过程刚刚开始，它就会报一个错，说“HeyTapThemeEditor 正在运行”，而且也不能够自动关闭，卸载无法完成。

无论是拿进程管理工具查看，还是拿窗口遍历工具查看，都没有发现其它与 HeyTapThemeEditor 相关的处于运行状态的进程。只好怀疑它很愚蠢地把它自己当成了问题所在。由于它的报错信息里清晰地包含了“HeyTapThemeEditor”字样，而含有“HeyTapThemeEditor”字样的窗口被俺第一时间认为是它的检测目标，于是请 AI 临时手搓了个脚本，遍历所有窗口，把标题里含有的“HeyTapThemeEditor”去掉。去掉是成功了，但是错误没有消除，依然不能卸载。

只好再次仔细检查卸载程序的进程树。Uninstall HeyTapThemeEditor.exe 是安装路径下首先被执行起来的，它会在系统的临时目录里创建一个名为 Un_A.exe 的可执行程序然后将之启动，若半途退出卸载过程，则临时目录里的内容也被清除。看上去很标准的手法，也没什么问题。

不过等等，似乎不大对。通常说来，临时目录里的卸载程序启动的时候，安装目录里的内容就不该再有保持活着（执行中）的了，因为要为删除操作创造条件。而当前的状况是，安装目录下的 Uninstall 似乎把 Un_A 加载起来之后一直在等待中，会不会就是这样产生了互相锁死的问题？

于是在报错之际，将临时目录里的 Un_A 复制了一份备用，然后把报错的卸载过程退出。再直接去运行复制出的那个 Un_A，果然，卸载得以顺利完成（见下图）。

此问题在 OPPO 官网提供的最新版的主题设计器中仍然存在。

今年是个特殊的年份。兜哥寒窗苦读（是不是真的“苦”，含苦量究竟如何，那当然自当别论），总算告一段落。进考场，出考场，经过众人瞩目的漫长四天，等结果中。“希望本就是无所谓有，也无所谓无的”，俺想。除这一重外，三太爷还正式可以使用“年过半百”这个称号了呢，可以说是往日觊觎已久，今时花落吾家。

今天是个特殊的日子。二十多年前，也是端午后的第二天，当时尚且年轻的三太爷急冲冲地赶回老家，去见慈母的最后一面。承受着巨大的疼痛，她老人家神智已经昏迷，饮食、言语均已失能，皮包着骨，似乎惟余粗重的呼吸。木然的三太爷在亲友近邻的催促中出门找最近的大夫，返回家中时母亲已然离去；木然的三太爷又在亲友近邻的催促中到镇上的邮局去打长途电话，把这个消息同步给二哥。电话两头，兄弟相互沉默，继而抽泣。她在世时给我转述她的母亲（也就是我的姥姥）说她的话：自从你嫁给人家张家，没过过一天好日子。子欲养而亲不待。这是种痛，然后当时的痛，并不是它。这种痛，要随着岁月，慢慢显现、慢慢积厚、慢慢迸裂，还要你不能像当时一般表现——或者说发泄——出来。

今天是个特殊的日子，父亲节。对于老夫，“这节日更就是无所谓有，也无所谓无的”。但昨晚发生了个小插曲，所以需要记一笔。兜哥约了同学一起看电影，电影看完回家，拎过来一只袋子，说是父亲节礼物。看了一眼，都是文化衫，数量还不少，高达三件。一件是星战题材，一件是唐老鸭，还有一件，嗐，瞅我这记性，没记住。兜哥说，他猜测我最喜欢的应该是星战那件，而唐老鸭无能暴怒的那件，则是他觉得跟我在某些时刻的形象非常匹配。至于最后一件，对不住，还是没想起来，只能记得颜色实在是太亮的色，俺穿着它的时候应该不多。

其实根本就在于作者提到该插槽需要配置一下才能启用：

改天有空了可以试试。

可是逐步地，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 也就这个价。唉，黑苹果的迁移大业，先停停吧。

为了叙述方便，我把一开始升级成功时采用的 EFI 称为第一版本，简称 E1，后面找到的、测试离线新建用户成功的 EFI 称为第二版本，即 E2。当然，前文里其实也已经透露出，最后发现无论是 E1 还是 E2，都不能使得升级前已经存在的用户登录进入桌面，而离线新建的用户无论是用 E1 引导还是 E2 引导，也都能进入桌面。

区别在于，E1 的相关资料、讨论中，均未有进一步处理图形性能的内容，而 E2 的说明里则非常清晰地包括了此部分的内容。简而言之，其核心症结以及相应的处理手法如下：

• 为了能够顺利安装 macOS Sequoia，需要在 OpenCore 的 config.plist 中将 T450s 伪装为一台 MacBookPro16,3 设备；
• 安装成功后，图形处理方面是不完善的；此不完善之处，需要借用 OpenCore Legacy Patcher（也即 OCLP）来进行完善；
• 而由于 OCLP 运行时，是自动检测当前设备以进行修补，那么就不能让它把 T450s 识别为伪装的 MacBookPro16,3 设备，而要设别为真正与 T450s 匹配（接近）的 MacBookPro12,1，否则修补就会错位；
• 上述矛盾，需要借用 macOS Sequoia 的 USB 安装盘来解决：把安装盘上 EFI 里的伪装设备从 MacBookPro16,3 改为 MacBookPro12,1，并使用它把安装好的 macOS Sequoia 引导起来，这时执行 OCLP；
• 执行完毕后，把安装盘的 EFI 同步到硬盘上的 EPS 分区里，应该就告功成了；

再按照上述理解进行操作后，macOS 从硬盘引导起来就完全正常了，而且之前不能登录的那个用户自动就复活了。不过在过程中，也遇到了两个问题，记录于下。

第一就是出于已经形成的认知，认为 E1 和 E2 版本的 EFI 尽管不一样，但其功效应该无甚差别，因此在 USB 安装盘的 EFI 是 E1 的情况下，按照对 E2 文档的理解，直接把伪装设备的型号（以及序列号等）从 MacBookPro16,3 改为 MacBookPro12,1，但这样改后用 E1 引导硬盘上的 macOS 会失败。把 USB 安装盘上的 EFI 从 E1 替换为 E2 并设置型号等信息后，再次引导硬盘上的 macOS 则成功了。

第二是在引导成功后，执行 OCLP 时发生了错误，报 Unable to resolve dependencies: 'com.rim.driver.BlackBerryUSBDriverInt' names a dependency on 'com.apple.iokit.IOUSBMassStorageClass', which was not found.。在网络上搜索到此处，根据一名为 Rochmind 的回答，到 /Library/Extensions 下，把两个以 RIMBB 开头的内核扩展模块移走了，再尝试 Post-Install Patch 就顺利成功了。