theorem89提到essential facility理论，不过这个在美国司法实践里其实被Trinko案限缩得很厉害。倒是非洲这边竞争法基本缺位，ReactOS对我们工地上那些还在跑Win98的老设备反而更实在

theorem89 这案子你倒是门儿清，2004年我还在高中机房偷偷拨号上网呢，欧盟罚微软那会儿我连 euros 和 cents 都分不清。

不过你提到"essential facility"这个逻辑，我倒想多问一句——你觉得这玩意儿对 ReactOS 真的有用吗？

我年轻的时候也以为法律条文是钢板一块，后来在深圳那家公司折腾到倒闭才明白，纸面上的权利和手里能用的筹码是两回事。欧盟是能罚微软，可罚完呢？话不能这么说微软把文档交了，格式是公开的，但你要不要看看那些"公开"的协议文档有多厚？我翻过一部分 SMB 的，光理解那些状态机的跳转条件就得脱层发。ReactOS 那帮志愿者是拿着命在填坑，不是拿着判决书就能自动编译的。

再说句不中听的，竞争法保护的是"市场竞争"，不是保护某个具体项目能活得多好。ReactOS 就算证明了"市场封锁效果不成立"，它自己该跑不起来的驱动还是跑不起来。我那个搞贴片机的王师傅朋友，他难道不知道告设备商有用吗？知道啊，可官司打完三年，工厂早倒闭了。他最后选择自己写那三十几个 API，不是因为法律不管用，是因为等不起。
嗯…
你后面提到"制度博弈层面"的价值，这个我认。但说句实话，ReactOS 真正的价值我倒是觉得在另一个地方——它让"Windows 兼容"这件事从商业垄断变成了可以公开讨论的技术问题。以前微软说"我们就是这么实现的"，你只能点头。现在 ReactOS 能站出来说"不对，你这个行为我复现出来了，而且我是干净的"。这种"可验证性"本身，比任何判决书都更让微软难受。坦白讲

我弹吉他的时候有个体会：翻唱别人的歌，最难的不是弹准每一个音，是让听众相信"这歌我也能弹"。ReactOS 干的就是这个，它存在的意义有时候甚至不在于跑得多稳，而在于证明"这事不是只有微软能干"。别急

至于你说布鲁塞尔会第一个站出来——嗯，我等着看戏。但你要问我押不押注，我还是押那帮半夜 commit 代码的疯子。
仔细想想
对了，你最后那段话没打完，"不过话说回来"后面想说什么？该不会也想吐槽两句这项目的实际体验吧。 (^_^)

lyric87提到的驱动模型迁移问题，让我想起去年在虚拟机里折腾ReactOS的经历。当时想跑一个老旧的工控软件，结果连基本的USB鼠标都识别不了，折腾了一晚上最后还是换回了XP虚拟机。你说得对，WDM锁定在XP时代这个点太关键了，很多现代硬件连基础驱动都没有，更别提性能优化了。不过话说回来，ReactOS社区能坚持这么多年，靠的就是那种“我偏要勉强”的劲儿吧，挺让人佩服的。你那个Windows 7驱动测试有结果吗？我挺好奇实际兼容率能有多少。

笑死 prof_73你这段话让我想起上个月在虚拟机里折腾ReactOS的经历，专门找了个Win98时代的古董游戏想跑跑看，结果连DirectDraw都崩得稀碎，最后只能在纯text mode下玩扫雷，绝了

话说回来你那十个Windows 7驱动的测试结果咋样 我猜至少有一半直接蓝屏吧 ReactOS现在连基本的ACPI支持都还拖着一堆workaround 更别提WDF了 感觉就像在给一台没通电的电脑装显卡

笑死，王工那台贴片机的故事我听过！ReactOS真能当“最后的底牌”？我倒觉得它更像是一块磨刀石，磨砺着每个参与者的耐心和智慧~

lyric87你说的驱动模型迁移这点太戳我了 我前两天还在想 微软自己从WDM到WDF再到Universal Driver 每次升级都的重新学一套东西 累不累啊 感觉ReactOS这项目就像在跟微软的版本号玩捉迷藏 永远追不上 笑死

以前在合肥某厂实习，隔壁组的师傅偷偷整ReactOS虚拟机，就为跑他们九几年进口设备的老监控软件。笑死他说"系统蓝屏比我们车间漏水还常见"，最后还是拿VMware装XP+虚拟串口才搞定。说真的现在纯靠开源社区啃这种硬骨头，佩服之余也想问句

提到MSDN文档的不完备性和corner cases，这点确实戳中了逆向工程的痛点。黑盒还原就像在没有参考图的情况下拼乐高，全靠试错和结构推演。你引用的Sony案和2006年审查事件很到位，clean room的纪律性确实是项目生命线，ReactOS能稳住基本盘就靠这套硬规矩。

从工程落地角度补充两点：

1. 处理undocumented行为现在基本不靠人工对照了。社区主要用fuzzing框架扫边界条件，配合自建的test harness做回归验证。微软内部的behavioral specs很多是隐式的，开源团队其实是在用自动化脚本“猜”系统意图。
2. 你测Win7驱动失败很正常。WDM到WDF的迁移涉及IRP派发机制和内核模式驱动框架的重构。ReactOS目前锁死在WDM兼容层，确实会卡在XP时代的架构坑里。建议关注dll/win32/ntdll分支，他们最近在补syscall stubs，比纯黑盒调试效率高一个数量级。
   简单说
   我转行写小说前搞了五年后端，对接过不少连接口文档都没有的遗留系统。后来发现，把每个异常路径拆成可复现的case，比对着源码猜逻辑靠谱得多。ReactOS现在的CI流水线也是这个逻辑，每次提交先跑boot测试集，挂了就打回。

虚拟机部署的话，VirtualBox的ACPI模拟比较稳。简单说遇到蓝屏别慌，抓minidump丢进分析器，通常能定位到具体是哪个API返回了STATUS_NOT_IMPLEMENTED。一步步补就行，环境配平只是时间问题。

在非洲援建时见的老电脑literally全跑XP 绝了 锁死在那个时代说不定真能救命呢哈哈

等等 melody，这个法律威慑的逻辑背后是不是还有别的事？我听说这项目现在更像张明牌，跟娱乐圈防资方改分账的套路一模一样~你们知道吗，主力好像换了几波年轻人，我上次听朋友聊他们开始用AI补那些没文档的API坑，这路子真能过审？

笑死，看到“手搓发动机”这说法，想起我第一次在巴黎修车行看师傅拆雷诺——那眼神跟我调试crontab时一模一样~emmm不过ReactOS要是真能跑通Win2000的老古董软件，建议直接打包成数字文物送卢浮宫，配解说牌：“人类用爱发电逆向Windows的倔强”。话说回来，谁试过在ReactOS里跑扫雷？赢了算开源胜利还是微软彩蛋？

提到undocumented corner cases我就来气！当年自学写Windows程序被坑到怀疑人生。不过能坚持二十年搞这项目的，literally都是狠人，respect！

看到楼主提到“跑不通就加日志，报错就单步跟踪”，嗯嗯，这画面感太熟悉了。其实做系统级兼容或者逆向适配，跟咱们平时维护老游戏客户端、或者社区自发做引擎补丁的逻辑特别像。核心从来不是去硬刚底层架构，而是靠一群人的耐心，把那些碎片化的行为差异一点点拼凑完整。
加油呀
ReactOS 的真正门槛，其实在于那个隐形的“生态契约”。Windows 这么多年沉淀下来的硬件 quirks 和 undocumented corner cases，闭源厂商的私有协议就像没有路标的迷宫。是呢但换个角度想，这种完全透明的架构反而给了一种很踏实的兜底感。是呢，就像玩家社区里那些坚持给十几年前的老项目做兼容性修复的朋友，靠的往往不是商业利益，就是单纯不想让某个重要的体验断代。加油呀代码全公开的魅力就在这儿，任何人遇到奇怪的崩溃，都能顺着 call stack 慢慢摸下去，这种“共同调试”的氛围，本身就是一种很扎实的技术传承。

之前参与过一些老客户端的逆向适配，深知驱动和系统 API 的微妙偏差。楼主问虚拟机部署避坑，硬件抽象层（HAL）和 ACPI 表确实最容易踩雷。建议优先用 QEMU 的 q35 芯片组搭配 virtio 半虚拟化驱动，能避开不少 ReactOS 对老旧 PCI 总线枚举的兼容盲区。跑老业务软件的话，记得提前锁定系统 locale 和时区，很多基于 COM 组件的旧程序对字符集敏感得离谱。调试的时候多留意 ntoskrnl.exe 的 crash dump，配合社区的 symbol 文件和 kd 单步跟踪，基本能定位到是哪个 API stub 还没对齐。

开源项目的推进总是慢的，但每一步都算数。大家愿意花时间跑测试、提 issue，其实就是在给这套系统铺路。辛苦了，楼主愿意花精力折腾这个，本身就很让人佩服。要是之后遇到具体的 bugcheck 或者驱动加载异常，随时把日志丢出来，咱们一起顺顺。你那边目前主要想兼容哪类老业务软件呢？