一块碎裂的Athlon处理器与裸露硅片封装的兴衰
拆散热器时，一块AMD Athlon XP处理器的硅片整块碎裂脱落，但CPU此前一直正常工作。文章借此回顾2000年前后Intel和AMD曾采用裸露硅片的flip-chip PGA封装，因硅片太脆弱、装散热器时受力不均就会裂，很快被带金属盖的封装取代。Intel的LGA处理器更结实，但弱点转移到了主板插槽。
Os2museum
OS/2 Museum，致力于 IBM OS/2 操作系统的历史、保存与技术探索的博客。
评论
点赞
收藏《Comanche：过度杀伤》——1992年游戏因CPU段属性差异在Pentium上崩溃的技术复盘
1992年游戏《Comanche: Maximum Overkill》因使用不安全的代码序列，在386/486系统上可靠运行，但在部分Pentium及后续Intel CPU上崩溃。问题根源在于Pentium架构对实模式下CS段属性的处理方式与旧CPU不同：386/486在实模式远跳转时自动将CS改为可写，而Pentium忽略该属性且不修改。游戏在切换至保护模式后尝试通过CS段覆盖写入内存，导致部分Pentium系统触发通用保护异常（#GP）。作者通过实测验证了该现象，并指出BIOS是否重载CS寄存器是决定兼容性的关键因素。
Windows 16位内存管理
少见的深度剖析 16 位 Windows 内存管理内部机制的技术文章，来自 os2museum 博客，作者拥有一手经验和调研功底。文章从 8086 实模式的历史约束讲起，详细解释了 NE 可执行格式如何支持段式内存管理、GlobalAlloc/Lock/Unlock 句柄系统的设计动机、可移动/可丢弃段标志的实际含义、以及 Windows 为何需要特殊的函数序言（prolog）来修补 DS 寄存器。尤其有价值的是对 Microsoft C 编译器「几乎秘密」的 /Aw 和 /Gw 开关的考证、Windows 模块加载器如何实时修补被导出函数入口点、以及和 OS/2 内存管理的对比，揭示了在 286 硬件保护模式缺失下 Windows 做的那些「脏活」——比如通过 BP 寄存器的自增来标记栈帧，供内存管理器安全地移动段。此外还梳理了 SDK 中的 Shaker、HeapWalker、Stress 等压力测试工具的设计由来。不是泛泛的历史回顾，而是可复用的技术细节和工程智慧沉淀。
VGA 内存访问为何如此复杂
作者亲身经历VGA模拟调试，指出VGA/EGA最大的坑不在硬件本身，而在文档质量。IBM官方手册只告诉读者“该设成什么值”，却不解释每个bit到底控制什么。Compaq的EGA技术文档则清晰说明：SR4[2]管CPU写入、GR5[4]管CPU读取、GR6[1]管地址映射——三个bit各司其职，只是通常被一起设置。Matrox的规格书进一步揭示了GR6[1]替换A0地址线的具体机制。作者还深入分析了CRTC字访问模式与Odd/Even寻址的对应关系，指出这些bit可以被单独翻转产生大量“未文档化”组合，而100%兼容性必须正确实现每一个bit的行为。对硬件模拟、操作系统底层开发和复古编程感兴趣的人，这篇文章提供了极其稀缺的一手经验和可复用知识。
当网络不通时：一次Intel网卡UDP校验和卸载的踩坑记录
一篇非常硬核且充满个人色彩的网络故障排查实录：作者试图让Windows 11连接一台老旧Tyan服务器管理卡（SMDC）的IPMI，发现所有Windows机器都无法通信，而同硬件切换到Linux下却一切正常。通过Wireshark确认远端有UDP回复包后，PktMon揭示了真相——Windows TCP/IP栈因"校验和无效"丢弃了这些包。最终定位到Intel I211/82579LM网卡驱动的UDP接收校验和卸载（Rx checksum offloading）存在bug，把合法的小包误判为无效而丢弃，关闭该功能即解决问题。文章还深入分析了可能根因（IP Packet ID字段与RFC 6864的冲突），以及为何不同网卡硬件表现不同。这是一篇典型的"踩坑+取证+修复"型技术好文，有完整推理链条、一手实验数据和可复现解决方案，对运维、虚拟化及网络调试从业者价值极高。
神秘的CPUID位：AMD Athlon Thunderbird中未公开的Bit 18之谜
作者在测试一颗2001年AMD Athlon 1200（Thunderbird核心）CPU时，发现扩展CPUID叶80000001h的EDX寄存器中有一个完全未记录的bit 18被置为1。所有官方AMD文档均标记该位为"保留"，但实际CPU返回值C1C7_FBFF与文档所列C1C3_FBFF不同。经过对多版AMD手册的逐版比对、社区成员提供的数据挖掘，以及一位前AMD员工在上的确认，最终揭露：bit 18其实是ECC能力标识位。AMD原本计划让Socket 462的Athlon支持ECC，因此预留了该CPUID位，但在后续修订中决定仅在Athlon MP保留ECC支持，于是从公开文档中抹去了这一位，留下了"存在但从未被文档化"的幽灵位。文章混合了亲手硬件测试、datasheet版本考古和社区协作破案，是一场对25年前硬件工程决策的逆向追溯，阅读体验如同技术侦探小说。
8086系统上的8087协处理器仿真机制
一篇罕见的底层技术考古，详细拆解Intel 8087浮点协处理器在8086/8088系统上的软件仿真机制。作者用MASM 1.25和3.0亲手编译测试代码并反汇编分析，完整还原了Intel E8087仿真库（1980年）与Microsoft DOS工具链（1983-1984年）的实现细节与关键差异。核心机制巧妙：汇编器正常生成8087指令但附加特殊fix-up符号标记，链接时通过选择不同库决定是否仿真——链接E8087.LIB时，fix-up将ESC/WAIT指令替换为软中断INT。Microsoft版本使用INT 34h-3Dh，并增加了运行时检测优化：若真实8087存在，首次执行仿真指令时动态替换为真实FPU指令，实现零性能损失。文章还对比了Intel ASM86 V3.0更完整的原始实现（支持无等待指令和所有段覆盖），附有SYMDEB调试器反汇编输出、fix-up值数学推导公式、Intel vs Microsoft fix-up名称对照表，以及旧版MASM的bug记录。信息密度极高，是x86历史爱好者和底层开发者的深度参考。
每日学点旧知识（十八）：FPU（浮点协处理器）检测是如何工作的？
作者在修复386SX无FPU系统的浮点运算bug时，发现Intel官方文档对FPU检测机制的描述存在严重缺失，于是亲自实验揭开真相。本文不是泛泛的技术回顾，而是一手调查记录：作者在自己的80386DX-33（无387协处理器）上实测发现，即使没有FPU，386的FNSTSW指令仍会向内存写入FFFFh，386远比文档承认的更"理解"387指令。文章从8086/8087通用协处理器架构讲起，详述286/287改用I/O端口通信、386/387的分段越界中断（不可恢复的Interrupt 9）、486内置FPU后的简化，完整勾勒了x86浮点检测机制演化脉络。作者还指出IBM PC的BIOS设备字因DIP开关说明颠倒而不可信、ESC指令在286文档中被刻意隐藏等冷门史实。对复古计算、底层OS开发和x86架构爱好者来说，这份带着真实困惑和实验验证的深度调查，比任何教科书都更有价值。
C语言位域陷阱
不同C编译器对位域（bit-field）的整数提升规则存在根本分歧，同一段看似正确的代码可能在MSVC下输出一种结果，在GCC/Clang下输出截然不同的结果。作者从亲手踩坑的真实bug出发，给出可复现的最小测试用例，并追溯C99/C11标准中关于位域类型的模糊乃至矛盾表述。更难得的是，作者系统测试了从16位到64位、从1980年代到今天、涵盖Microsoft C 5.0、Borland C++、Watcom C、Digital Mars、IBM VisualAge、GCC、Clang等十多个编译器的行为，整理出一份罕见的跨编译器兼容性对照表。结论是：C语言位域自1970年代诞生以来语义始终未彻底确定，C11有改进但2022年仍有未解边缘情况，写可移植C代码时必须刻意规避此类陷阱。文章兼具第一手踩坑经验、标准原文考证和历史编译器实测，对C/C++开发者有直接的实用价值。
C语言位域陷阱：不同编译器间的行为分歧
C语言位域在不同编译器间存在严重行为差异：MSVC将unsigned位域始终视为无符号类型做零扩展，而GCC/Clang将宽度小于int的unsigned位域提升为signed int后做符号扩展，导致同一段代码输出截然不同的结果。作者在一次debug中触发了这个隐藏多年的bug，并为此测试了从MS C 5.0、VisualAge C++、Borland C++、Watcom C到Digital Mars等数十个历史编译器版本，逐一确认跨编译器的行为分歧。文章深入拆解C99与C11标准中整数提升规则的措辞变化，引用WG14缺陷报告DR#120（1993年）、N1260（2007年）和N2958（2022年）等文档，说明该争议自上世纪90年代持续至今仍未完全解决。对涉及位域与移位/类型转换交叉的C/C++代码，这是极易被忽视但后果严重的可复用踩坑经验。
一台百年历史的Consul打字机？
一台1926年产的美国Remington打字机上，赫然印着1960年代捷克斯洛伐克Consul品牌的商标。作者从祖父遗留的这台打字机出发，通过序列号查证、历史报纸档案检索、键盘布局对比和维修手册分析，展开了一场跨越百年的侦探式考证：梳理了捷克键盘布局从奥匈帝国德捷双语版到现代标准的演变，还原了Zbrojovka Brno兵工厂从1932年代理生产Remington到战后自创Consul品牌的历史脉络。大量一手照片和报纸资料为证，开放式结局让这个关于机器、人与历史的谜题更耐人寻味。核心悬念——Consul logo为何比品牌本身早出现二十多年——至今没有确切答案，但清晰的推理链条本身就足够让人一读到底。
DOS 内存管理
这篇关于 DOS 内存管理的深度技术文章来自 OS/2 博物馆博客，作者以一手源码分析还原了 DOS 1.x 到 5.0 的内存管理演进。核心看点：DOS 2.0 内存管理源码实际编写于 1982 年而非官方注释声称的 1983 年 3 月；详细拆解了 MCB（内存控制块）结构、ALLOC/DEALLOC/SETBLOCK 三个核心函数实现细节和边界行为；揭示了多个鲜为人知的陷阱和 bug——SETBLOCK 在失败时已部分修改内存的 bug（微软后续版本未敢修复）、零大小内存块的产生机制、以及任何进程可修改其他进程内存块所有权的安全隐患。还梳理了 DOS 2.11 加入但未文档化的分配策略接口（INT 21h/58h）以及 DOS 5.0 对 UMB 上端内存的支持扩展。对系统编程和复古计算爱好者来说含金量极高。
破解 DXP 与 SXD 自解压软盘镜像格式
一篇个人逆向工程 1990 年代 DXP 和 SXD 两种自解压软盘镜像格式的技术探案记录。作者从发现 DXP 压缩算法基于 LHA（lzhuf.c）开始，通过反汇编自解压存根、识别 lh1/lh5 压缩方法变种、破解不同版本 CRC 算法差异，最终完整解码了 Disk Express 和 CopyQM Plus 创建的镜像格式，并顺带分析了 IBM 专用变体和 TeleGet 格式。全文充满真实踩坑经历和现场发现，提供了可直接使用的代码和逆向结论，对复古计算、软件存档和数字保存领域有实质参考价值。
《链接器与加载器》书评
资深程序员对 Levine 经典技术著作《Linkers & Loaders》的详细书评。该书出版于 1999 年，系统讲解链接器和加载器的工作原理——从 1940 年代的早期链接/重定位、ABI 与多种目标文件格式（COM、a.out、ELF、PE/COFF、OMF），到存储分配、符号管理、库搜索、重定位、位置无关代码、共享库、动态链接及 C++ 链接优化。书评逐章梳理内容，点出该书的核心价值：不讲如何使用链接器，而是讲为什么需要链接器以及它究竟做了什么。作者特别强调书中丰富的历史线索能解答很多难以查证的问题（如 ranlib 的作用、符号下划线前缀的由来等），并认为即使资深程序员也能从中受益。书评也客观指出，若出修订版需补充 AMD64、OS X 格式等内容，但整体内容至今仍具参考意义。这是一篇有个人判断、有领域经验、非模板化包装的真挚技术书评。
OS/2 Warp PowerPC 版回顾（2011）
一位技术收藏家在Power Series 830机器上亲手安装并深度体验了IBM 1995年低调发布的OS/2 Warp PowerPC版——这款仅限少数客户的半成品是PowerPC桌面平台的绝唱。作者详细测试了安装流程、DOS/Win-OS/2 x86模拟性能、多媒体播放等，并深入剖析了基于Mach微内核的架构、ELF格式和MetaWare工具链。虽然系统网络功能缺失、稳定性欠佳、应用为零，但其x86模拟器效果惊人，多媒体子系统优于同期x86版，还率先引入了GRADD显示驱动和Unicode支持——这些技术后来回流到了Intel版Warp 4。文章还交代了Power Series硬件与RS/6000工作站的血缘关系，以及IBM流产的Workplace OS计划。适合操作系统史和复古计算爱好者。
OS/2 显示驱动动物园
核心看点：作者亲身考证 OS/2 从 1.x 到 Warp 4 近二十年间显示驱动模型的完整演变——16 位汇编驱动、32 位驱动、SOFTDRAW 软件光栅化、GRADD 简化模型。这不是泛泛历史回顾，而是基于亲自翻阅 IBM/Microsoft DDK 样本代码、驱动参考手册和源码的实地考察笔记，详实记录了各版本驱动接口变化、文档版本混乱现象（IBM 自己的版本号标注都自相矛盾）以及各种兼容性陷阱。文章还给出了为虚拟化 OS/2 编写高分辨率驱动的具体选型建议：16 位模型只能用于 1.x/2.0，32 位 SVGA 驱动可移植但只支持 8 位色深，S3 驱动（源自 XGA/8514/A）支持多分辨率和色深是更优基础，GRADD 仅 30KB C 代码即可实现最简驱动。适合对操作系统底层、古董显卡驱动或 OS/2 技术史有深度兴趣的读者，信息密度极高且有可复用的实操指引。
Solaris 2.1 x86版：Sun首次登陆PC的UNIX考古
Sun在1993年就把Solaris搬到了x86 PC上，比Windows NT 3.1还早两个月。这篇来自OS/2 Museum的深度技术考古，详细记录了Solaris 2.1 x86版的内核架构（可加载模块设计，当时只有Windows NT和AIX有类似能力）、OpenWindows 3.1图形桌面——融合X11与NeWS窗口系统，后者由Java之父James Gosling参与开发，是一个超前但最终失败的路线。文章追溯了Sun从386i工作站到x86 Solaris的脉络，包含一手安装体验（需要SCSI CD-ROM、特定网卡）、硬件兼容细节、多线程/SMP支持情况，以及AnswerBook电子文档系统等特色。评论区还延伸讨论了8514/A显卡标准、NetWare NLM、AIX模块加载等深度话题。最终指出：在x86平台上真正击败Solaris的不是Windows，而是Linux。
混乱的软盘母盘压制记
一篇令人拍案的技术考古文：作者发现一套IBM TCP/IP 2.0 for OS/2软盘镜像布满疑点——文件时间戳散乱、各盘OEM标识五花八门（IBM 20.0、DOS 4.0、IBM 3.3混用）、盘中还夹带了OS/2多媒体工具包的无关联文件。按常理这必是后期篡改盘，但作者翻出二十年前的原始软盘，用Kryoflux硬件逐扇区验证后确认：这些盘确系IBM原厂出品——只是母盘制作过程极其草率，制作人直接拿了手头各种旧盘删掉文件就拷贝新内容，连盘上原本的OEM标识都没改写，README也比安装文件早了好几个月。文章还横向对比了IBM、Microsoft和Novell三家公司在90年代对发行文件时间戳的不同策略：IBM和Microsoft常人工设定统一时间戳，Novell则保留原始时间戳。这一差异使时间戳分析成为鉴别软盘真伪、判断文件是否被修改的有力手段。作者以第一手经验展示了数字考古中的典型困境：看似破绽百出的东西，可能恰恰是原汁原味的真品；而IBM当年这种粗放的压制方式，注定要在几十年后把每一位档案管理员搞得一头雾水。
8×19 文本模式字体起源探秘
一篇关于BIOS 8×19字体起源的深度技术考古。作者通过手头保留的Intel AL440LX、AN430TX等老主板，亲自动手编写工具dump BIOS ROM、解码Phoenix BIOS镜像，追溯了Intel主板上使用的8×19像素特殊字体的来龙去脉。文章不止于截图罗列，而是从1996年到2013年跨越多代主板进行实机验证，最终给出了完整时间线：1996下半年出现第一种8×19字体（斜线零），1997上半年换用第二种（点零），此后被Intel沿用十余年，甚至进入了UEFI 2.1规范成为标准窄字体。文章还挖掘了字体的编码压缩方式——BIOS只保留实际用到的扩展字符以节省空间。对复古硬件、BIOS历史和字体爱好者来说是一篇不可多得的原创研究。
1990年代网络往事：微软 LAN Manager 2.0 考古记
作者通过亲自安装收藏的原始软盘与盗版副本，挖出了微软 LAN Manager 2.0 一段令人哭笑不得的历史：内置 admin 密码被设了90天有效期，而 LM 2.0 在1990年6月编译完成后因依赖 OS/2 1.21 迟迟无法发货，等到秋季用户真正拿到手时密码早已过期，导致无人能登录管理服务器——堪称自我封杀的经典操作。文章不仅考证了 LM 2.0 的真实发售时间线（8月？还是更晚？），还从 KB 文章和软盘实物中梳理出 2.0→2.0a→2.0b→2.0c 完整的 CSD 补丁体系，记录了 WD 网卡驱动因默认内存映射冲突而崩溃的踩坑经历，以及盗版副本中意外包含的调试符号和 Debug 内核等彩蛋。对 OS/2 和早期 PC 网络技术史感兴趣的读者，这是不可多得的一手史料。