Home >ReactOS News >News #48: 年度回顾
2009-01-16, Z98
年度回顾
translated by samuel1991 on 2010-02-06
回顾 2008 年
年度回顾
2008 看见总共 四个 ReactOS 工程的发布，当中所有都是在内核重写完成之后而发布的。因此人们在 0.3.1 发布所见到的不稳定已经大大的减少并且在真实硬件里运行 ReactOS 有个更高的成功率而非仅仅虚拟机。但这不代表系统能够可靠的运行，但是我们已经达到更靠近的一步。发布的数量肯定比前几年高，这是由于工程在一段时间停顿而导因正是内核的不稳定。
正如每个人能够看见的，2008 年对我们而言非常忙碌，并有着持续的发展进展以及为我们希望能够在将来实现的新措施铺下基础。与此同时，数年前所付出的努力终于看见初果，将使得ReactOS 更具有功能以及更加稳定。这里我们将列举一些对社区或许会所感到兴趣的进展和努力。
旧和新血
今年有好些人加入本工程为开发者，许多人是长期社区成员，并且至少一人从他的中断后重新加入本工程。一共有十个新加入和一个重返者现在与我们同行并且为开发工作付出了许多。第一对是在年初时加入我们，他们名为 Andrey Korotaev 和 Dmitry Chapyshev。 Steven Edwards，我们 Wine 联系人联系了一段时间再重归我们。在他之后就接着Matthias Kupfer，一个在社区里的老手，以及Jeffrey Morlan，在近期内发现本工程才成为一位开发者。过后， Stefan Ginsberg 加入并且在一段时间里获得最年轻 ReactOS 开发者的荣誉。这个荣誉随后就传给 Cameron Gutman，另一位论坛成员最终加入 IRC 以便联系开发者也一并获得 SVN 的访问权。此时， Samuel Serapion，名义上是时事通讯的另一位撰写人也获得提交权限。自此，他并未撰写另一份时事通讯。最后三位是Michael Martin，Gregor Schneider，和Kamil Hornicek，他们之间全都在一个月内加入。有了更多的人手，ROS 的前景肯定更加乐观。
图形
自从内核本身已经在某个程度上稳定下来，因此注意力已经转移到图形子系统。代码其实是非常陈旧以及应用许多的破解，可是修正才是使得更多应用程序能够运行的关键。最终，数位开发者已经开始基本上是个 Win32 子系统的重新编写。主要目的是整理实现以及内部架构和数据结构，当中一些是在 Windows 的实现里不存在的。如果我们真的要兼容的话，这是无法接受。因此 Timo Kreuzer 开始将它们拆散。当中多个数据结构其实是现有的结合或者是揉的结果。Timo 已经能够取出一个ROS 特定结构并且以正确实现的代码将其给替换了，但是许多类似的情况仍然存在并且分散在许多不同的地方。若要完全将全部给替换将需要一段时间，尤其那些代码已经演变到需要依赖这些错误的数据结构。
另一个内部问题获得很大的注意将是在 Win32 子系统里的相互依存。由于开发在许多其信息能够公开获取时就开始了，所以做出某些推断关于它们是如何一起链接。这导致环形依存，从而模块都相互依赖而非从上到下分层的依存模式。Eric Kohl 花了可观的时间尝试理清这个问题而当中的一个成功是修正CSRSS 在其初始化不要使用shell32，一个组件在 CSRSS 启动时根本都还未载入。这不幸运的将不会解决所有相互依存的问题，但是Jim 仍然继续他的搜索。
第三个架构问题围绕着Win32 子系统的是实现ReactX，我们DirectX 的代替品。Magnus Olsen 在本年里发现到这样的努力将需要比原先所估计的付出更多时间 ，尤其支持硬件加速的三位渲染。因此就有两个短期解决方案诞生。第一个牵涉到使用 Wine 代码，并翻译Direct3D 调用到他们相近 OpenGL 的对应，来做同样的工作于 ReactOS。我们确实有对OpenGL 支持硬件加速，所以这个作弊确实能够改善性能。可是，Magnus 仍然希望做个正确的实现而无需通过 OpenGL 所安排。第二个方法是改善Win32 子系统到能够在 ReactOS 里运行微软官方DirectX 运行时的程度。这就必须修正DirectX 所依赖的内部架构并且将它们做得与 Windows 相似。要让微软的 DirectX 运行时在 ReactOS 里运行的工作早在 2004 年就开始并且开始显示可见到的进展。DirectX 驱动程序能够载入以及简单硬件加速的二维渲染能够运作，可是三维仍然还是有一段距离。这个工作是由 Magnus Olsen, Timo Kreuzer, Jim Tabor, Maarten Bosma, 和 Alex Ionescu 的联合工程，并且现在最近 Kamil Hornicek 也加入这份工作。许多部分仍然需要完成，可是我们现在正处于能够看见的进展而非只是内部。
最终，应该注意的是大量的修正错误也连同大量的基础设施工作一起正在进行中。渲染基本图形已经逐年正在改善中，并且更多的应用程序现在能够正确的运作，因为它们能够正确的绘画出。这样的成果部分是更新我们从 Wine 所借来的代码，但其他都是我们自己开发者的努力成果。这不是小事一桩，由于修正在 Win32 子系统里架构的错误将会拆散破解曾经使得东西能够正确的绘画，为此Win32 开发者必须修正长期以来的问题以及由于比较正确的实现从而拆散的破解。
文件系统以及内存
工作于这两个组件是并肩进行，由于文件系统的驱动程序相当依赖内存管理器所提供的服务。是在 2008 年里工作才正的开始填补阻止我们使用除了 FAT32 以外文件系统的漏洞。这两个最大的阻碍是非常不完整的文件系统运行库以及极度不正确实现共同缓存 (CC)。
共同缓存的问题已经在好一些时间前就知道了，也在以往里有数个努力去重写它。事实上，CC 并不是分开的组件，而只是揭穿从内存管理器 (MM) 的功能。这表示如果我们要有个正确的 CC，我们就需要有好的 MM。不幸的，这不是我们要见到的。CC 和 MM都应该有一个抽象的程度但是我们的实现基本上将它们混在一起。因此第一步骤应该是解耦它们，正是由 Aleksey Bragin 所发起并且由Art Yerkes 接纳 NoCc 努力的宗旨。Aleksey 计划NoCc 先拆下CC 应该提供的功能，如此一来我们就可以先操心在修正根本的内存操作才尝试理清 CC 应该做什么。一旦我们肯定内存管理器能够正确的运行，那么我们能够尝试为 CC 实现缓存的算法。Art 居然成功分隔这两者，并消除共享数据结构由开始至终就不应该存在的。他随后也实现一个简单但最近所使用的缓存算法并且能够让 ReactOS 引导到图形界面直到它崩溃。考虑到 CC 基本上是在刚开始的努力时几乎不存在的，已经完成了许多但是今年需要完成才能够跟进。
另一个组件文件系统驱动程序则大量的依赖文件系统运行时库。 许多的 FsRtl 其实并不存在，既然 FAT32 是够简单到能够运行而无需大量的破解。Pierre Schweitzer 原先加入以便帮助 ReactOS Build Environment（ReactOS 构建环境），但在 2008 年里转换到FsRtl。他已经在另一个分支完成了好一些作品，实现缺乏的功能于FsRtl 和服务在另一个组件FsRtl 所依赖二者也。这是另一个初步行动则需要时间才能够有成果，但是到此阶段后，我们就能过开始更认真的努力来支持较新的文件系统。
移植
在 2008 年里开始两个努力以便移植ReactOS 到不同的架构， x64 和 ARM。两者都见到可观的发展，而 ARM 的移植现在已经到达能够着手处理在引导过程里初始化用户模式组件的程度。x64 移植则比较缓慢但是也获得局部的启动。两个努力都在内存管理器里发现许多错误，也惠及 x86 平台的工作。许多x64 的作品仍未完全合并到主干，然而ARM 的工作已经在主干里进行。尽管如此，所完成的工作将能够为未来开发提供强有力的基础并且一个成功的移植也表示为 ReactOS 开启新的机遇。
基础设施
我们也在过去的一年里尝试一些方法帮助开发者能够更加具有生产力。除了搬迁服务器和其升级，本工程也开始在自动测试系统为每个修正版测试。第一步在这个过程是完成Sysreg 程序，由Johannes Anderwald 和 Christoph von Wittich 所编写。现在运行于构筑机器， Sysreg 目前只运行Winetests 并且在第一个失败或崩溃时停止。逐步的，它将运行所有的测试于 Rostests 模块并把全部给完成无论其失败。目前Sysreg 所生成的报告是非常多的文字并且 Colin Finck 以及社区的其他成员正在努力为它提供较好的网络界面。我们希望在今年内看到成果。
另一个重大的添加是 ReactOS代源码更新后的Doxygen 页面。出现在较早 Doxygen 版本的错误导致我们代码之内有个无限循环导致没人理会生成新修订版的说明。这表示目前的说明是真的无望的过时以便让任何人希望使用它。现在系统能够正确的运行，我们也能够使用Doxygen 的其他功能以便记载开发过程并提供更好的引用以方便那些希望学习代码的人们。
Bugzilla（错误追踪器）也有好些改进。感谢维基（英文）所新增的调试文章，要报告错误的人现在能够提供有用的信息和调试记录，从而提升报告的质量。Bugzilla 也有重大的整理以及改进后的维护，从追踪到标记已解决的问题，直到消除重复报告以及照顾所提交的补丁以便让开发者能够更快的审查它们。
Coverity 扫描
我们通过 Urias McCullough一位 Haiku 社区的成员而认识 Coverity，并提交我们的代源码以便分析。被添加作为一个开源项目 Coverity 的分析将在长期而言是个重大的好处，并协助我们避开某些错误以及提供检查整体的质量。
编译器
本工程当中最大的问题在应对 GCC 为主要的编译器是缺乏结构异常处理的支持。KJK::Hyperion 出产PSEH 库以便弥补这个问题并在去年底更新到第二版。它仍然有一些初期出现的问题，而这是KJK 仍在进行修正，但这应该能够带我们到更靠近的一步以便在代码于 GCC 和 MSVC 时使用一个异常处理方案。这将会是非常有用的，既然 KJK 也开始努力让ReactOS 能够在MSVC，微软编译器里编译。这两个合在一起将随着发展时能够可观的帮助我们提升代码质量。
社区资助点子 (CFI)
过去以来这个计划已经多次提议，但直到 2008 年中时才有认真的努力去筹办它。CFI 的用意是让社区成员为他们所要的特定功能完成并且为此而捐款。它的用意是让开发者有必要的资金，如此一来他们就能过付出必要的时间来完成该功能而无需担心现实生活的财务责任。某些工程已经收到一份合理的捐款并且我们希望 CFI 整体上将能够在未来的日子里办得成功。该努力目前还在进行中，并有个计划并筹办，可是开发者已经开始初步的工作于一些所建议的工程。
