来自:https://reactos.org/blogs/newsletter-102/

你好ReactOS的追随者和爱好者！自从我们发布第101份时事通讯以来已经有很长一段时间了，到目前为止，还没有发布进一步的更新。虽然ReactOS Twitter帐户确实不时提供公告，有关工作应用程序的帖子等，但整个项目正在发生的事情并没有被提及。我们将要讨论的大部分内容是发布和整体 ReactOS 开发的当前情况。

为什么发布新版本的 ReactOS 需要这么长时间？你们死了吗？

最新版本是ReactOS的0.4.14，发布于2021年12月16日。仅该版本就花了一年时间进行设计。当时，ReactOS 遵循 3 个月的节奏，每3个月发布一次新版本。但自2021年以来，ReactOS仍处于0.4.14。你们死了吗？
答案当然是否定的，我们处理发布的方式已经改变。过去，ReactOS的发布是为了数量而不是质量。3个月后的每个新版本都与上一个版本相似，除了少量添加的功能和错误修复。但总的来说，版本之间的净差距并没有那么大。一段时间以来，我们已经制定了一条规则，即要使新版本达到“发布”状态，它需要具有相当低的回归量（不超过 20），并且稳定性不得受到引入新功能或在开发过程中完成的代码更改的严重影响。
换句话说，ReactOS 项目现在专注于提供高质量的版本，这排除了3个月的发布节奏。无论如何，以前的方法对于像我们这样规模的开发团队来说是不可行的。
预计发布新版本需要更长的时间，尽管这些版本现在将更加充实，并具有更多的改进。如果您迫不及待地想要测试最新的更改和功能，您可以随时尝试夜间构建（也称为实验性构建）。

发展现状

在去年和 2023 年初，ReactOS开发人员和贡献者都在研究项目的许多部分，最关注的领域是内核。其他与内核无关的领域是应用程序，特别是我们的画图和记事本程序，输入法编辑器（IME）以及其他内容，例如ReactOS测试基础架构。

ReactOS x64端口状态

ReactOS的x64端口虽然仍处于起步阶段，但在稳定性方面已经稳步变得更好。当时，ReactOS几乎无法启动，即使启动，通常只需执行简单的任务即可立即崩溃或BSoD。在Timo Kreuzer （tkreuzer）的帮助下，x64端口已经达到了可以容忍的状态，ReactOS现在可以毫无问题地运行。

尽管问题仍然存在，并且兼容性不如x86版本，但更多的应用程序甚至硬件驱动程序已经开始工作。请注意，由于缺少 WoW64，x64 端口目前不会运行任何 x86 应用程序。

WHS 测试修复

WHS测试机器人（代表Windows Home Server的首字母缩略词）是运行Windows Server 2003的机器人，它执行整个ReactOS测试套件基础结构，确保每个测试用例在Windows环境中通过测试结果。这有助于了解Windows在向它提供某些测试输入时的行为方式。众所周知，由于测试未通过甚至崩溃，WHS 测试用例基础设施会失败很多。在 2023 年 1 月的黑客节期间，Timo Kreuzer （tkreuzer）、Mark Jansen （learn_more） 和 Thomas Faber （ThFabba） 共同修复了一些测试用例。由于他们的努力，WHS现在可以通过所有测试。

画图和记事本改进

多亏了Katayama Hirofumi MZ，油漆和记事本都得到了生活质量的改善，杂项修复等等。值得注意的是，他在调整应用程序窗口大小时修复了 Paint 上的一些闪烁问题，并实现了“文本工具”功能。此外，他还改进了记事本的性能，实现了“正在打印”对话框，并提供了一些杂项修复。

安全子系统改进

George Bișoc（GeoB99）通过新东西和错误修复逐步改进了内核的安全子系统（Se），主要是显着改进了安全访问检查和访问令牌。
访问检查是内核执行的操作，用于验证请求者是否可以访问对象。如果请求者没有访问对象的正确权限，或者对象本身阻止其他人执行访问控制列表 （ACL） 强加的某些操作，则访问将被拒绝。SepAccessCheck中发生了一次黑客攻击，无论安全描述符施加的安全限制如何，都可以向任何人授予访问权限。这可能会导致不良行为者篡改和玩弄物体。
多亏了他的工作，SepAccessCheck中的hack已被删除，安全访问检查现在可以运行，内核可以防止任何试图以不当访问权限访问对象的人进行任何未经授权的访问。他对安全子系统的未来计划是对所有对象实施安全审核，并在需要时进行其他改进。

注册表改进

为了使ReactOS达到测试阶段，它必须解决两个主要的里程碑 - 稳定性和损坏。通常，ReactOS 中的损坏可能以文件系统和注册表损坏的形式表现出来。虽然可以通过选择我们目前支持的更现代的文件系统（例如 BtrFS）来防止文件系统损坏，但注册表损坏本身就是死刑，因为 ReactOS 目前没有实施任何自我修复机制来从损坏的注册表配置单元中恢复系统。因此，用户被迫对系统进行干净的重新安装。最坏的情况是，系统仍然可以启动，但由于用户配置文件已损坏或丢失，因此卡在登录提示对话框（也称为“Ctrl + Alt + Del”对话框）上。后者通常发生在 ReactOS 在全新安装后强制关闭之后。
George Bișoc 目前正在通过实施必要的注册表自我修复机制和 CmCheckRegistry 来改进注册表，CmCheckRegistry 是一项基本功能，可验证注册表中是否存在注册表的任何损坏部分，并采取适当的措施从此类损坏部分恢复注册表配置单元。虽然他的工作目前正在进行中（#4571），但到目前为止，他已经从测试人员那里收到了一些积极的结果。他的一小部分工作已被合并，这修复了近十年来无法工作的 ReactOS 注册表刷新器！此修复程序还解决了由于强制关闭系统而导致用户配置文件丢失的问题，因此您不应再期望像以前那样经常看到臭名昭著的“Ctrl+Alt+Del”对话框提示。
此外，他正在研究注册表缓存实现（#5088），因为 ReactOS 没有正确同步缓存的信息，从而导致结果不一致。
目前，大部分工作仍在坚持，因为它使我们的引导加载程序大小大于应有的大小，从而阻止了 ReactOS的AMD64版本启动。

输入法项目

输入法编辑器（或 IME）是一个组件，它有助于通过使用字符序列键入输入设备上最初不存在的字符。ReactOS中的IME在很大程度上是一个存根，但值得庆幸的是，Katayama Hirofumi MZ已经对此进行了广泛的研究。这极大地有助于CJK支持，并允许为不同的区域设置安装自定义 IME。片山写了一篇关于他的工作的文章，其中的日语部分是在ReactOS中使用MZ-IME 编写的，这是它的英文部分：
距离我上次报告已经过去了七个月，我想解释一下日本在 ReactOS 中输入的现状。我们已经确认日语ReactOS识别并实际可以使用MZ-IME日语输入，这是一种自制的测试IME。
在 IMM32 实现几乎完成之后，剩下的问题是 USER32 端的实现，其中默认过程以及默认 IME 窗口和 EDIT 控件的处理尚未编写。默认过程需要处理多个 IME 消息。默认 IME 窗口是不可见的窗口，在 IME 消息传递中是必不可少的;EDIT 控件是一个所谓的文本框，需要正确处理某些 IME 消息。实现 IME 消息处理时，IME 组合字符串窗口和候选窗口正确显示。

视频： https://www.youtube.com/watch?v=Dv58IV_vUxY

请注意，命令提示符和丰富编辑控件的日语输入尚不可用。仍然存在一些故障和不稳定。请注意，ReactOS IMM目前是为较旧的系统开发的，不支持较新的TSF兼容 IME。缺陷和问题可以在 https://github.com/katahiromz/ImeStudy/issues 报告。

其他亮点

Dmitry Borisov（disean）修复了由于Windows Server 2003中的IDE驱动程序堆栈关闭而导致的BSoD。
    Win32后端内核模式子系统组件（win32k.sys）正在稳步改进，许多人进行了改进和错误修复，特别是Timo Kreuzer，James Tabor（jimtabor），Jerome Gardou（zefklop），Thamatip Chitpong（TAN-Gaming）和Katayama Hirofumi MZ。
    会话管理器子系统 （SMSS） 的某些部分已由 Hermès Bélusca-Maïto （#4821） 清理和改进。这包括清理 SM 客户端库 （SMLIB） 中的旧代码和已弃用的代码。此外，已经实现了一个API，以允许ReactOS使用Win32以外的其他子系统。此外，客户端/服务器运行时子系统 （CSRSS） 已针对此目的进行了略微调整 （#4802）。

有关更多更新和最新消息，请查看ReactOS推特。

主分支之外

ReactOS一直不仅仅是一个操作系统。我们是一个专注于 Windows 生态系统的人员社区 — 通过各种项目来研究和记录 Windows 内部，改进应用程序中的 Windows 支持，或以其他方式使更广泛的 Windows 开发人员社区的生活更轻松。事实上，大多数开发人员第一次接触 ReactOS 可能不是通过下载操作系统，而是在 Web 上查找未记录的 API 并最终进入我们的 Doxygen 生成的文档时。

因此，过去两年中的许多工作也发生在我们的主源树之外，值得一看：

Joachim Henze 继续将所有旧版本从0.4.7改进到0.4.14，方法是移植回回归和一些优化的安全修复程序，您可以在 sourceforge 上找到所有这些版本的更新 iso。有关已应用修复的完整列表，您可以查看 0.4.7、0.4.8、0.4.9、0.4.10、0.4.11、0.4.12、0.4.13、0.4.14。

Colin Finck 一直在尝试使用Rust编程语言进行Windows开发，并且发布了多个相关的库。第一个是nt-hive，最初于2021年2月发布，它为Windows注册表配置单元文件的内部结构实现了解析器。紧随其后的是2022年1月的ntfs，这是一个更雄心勃勃的项目，旨在提供NTFS文件系统读取器作为各种场景的可重用构建块。该库已在虚拟FOSDEM 2022上发布，并附有关于 NTFS内部的演示。幻灯片中有关NTFS内部的演示也在这里。最新添加的是当年晚些时候的 nt-list，它是围绕 Windows 链表（也称为LIST_ENTRY和SINGLE_LIST_ENTRY）的类型安全和惯用的Rust包装器。它已在 2022 年欧洲Rust大会上展出。用于分析apiset DLL的库目前正在筹备中。

最终，这些库都应该在Rust驱动的引导加载程序中使用。但是它们中的每一个现在都可以在各种上下文中使用，从低级系统开发到用户模式应用程序。这已经在发生。