Community > ReactOS Newsletter Archive > ReactOS Newsletter: 时事通讯 68 期

时事通讯 68 期

by Z98 on 2010-01-22
translated by samuel1991 on 2010-03-06

ARWINSS, 第三次将更具吸引力，或许

现在出现越来越多推测究竟 ARWINSS 什么，要做什么，以及它能做什么，尽管 Aleksey Bragin 已经对此做出几次声明。这个推测已经到达人们在没有完整的相关信息下做出推测，尽管他们多数的推测都是错误的程度。ARWINSS 并不是要“取代”当前的 Win32 子系统。它存在其实是个并行的努力以便通过应用不同的设计而非复制 Windows NT 的方法来克服当前 Win32 子系统的限制。而且，ARWINSS 只与 Win32 子系统相关，所以它只是本工程的一个部分并不是代表整体上的操作系统。所以声称 ReactOS 正在“重置”或“重新启动”的说法至少显得过于夸张。过了时间 ARWINSS技术上的功劳及过失将会变得更明显然而原来的 Win32 子系统将会继续，但并没有什么东西会避免两个共存。这将为 ARWINSS 提供非常高层的策略观点并希望澄清这不是什么重大工程的整顿以及 ReactOS 的设计。

至于 ARWINSS 本身，其实现是基于 Wine 目前所使用的架构。在 Wine 里有几层，有多数的可以重新使用的代码用做于用户模式的驱动程序将能够抽象出底层的图形系统。要在 Wine 里使用每个图形系统则需要一个分开的驱动程序并且当前有个 X11 驱动程序，名为 winex11 并且 Quartz 驱动程序有些工作进展。那里并不存在一个 Win32 图形系统的驱动程序，很可能在过去的日子里是基于这个东西显得多余的原因。ARWINSS，则实现该驱动程序，名为 winent，作为 Wine 所实现的某些 Win32 DLLs 的一层以及 Win32 子系统的内核组件，为 Win32k。传统上那些 Win32 DLLs 将会通过 Syscalls 直接调用到Win32k，可是 Wine 的实现却如在上面所说的，期望一个之间的层。更何况，用户模式的驱动程序只处理与图形系统交互以及某些其他Wine's DLLs 所需的服务和资源是并且是由 wineserver 所提供。幸好，多数 wineserver 所提供的功能已经在 ReactOS 里实现，所以 Aleksey 就重新调用DLLs 所调用的到 ReactOS 的库及函数。Winex11 在好些图画甚至在库里的存在已经导致好些推论 ReactOS 某种程度上将考虑使用 X Windows。可是，如上面所指出的，winex11 已经存在并且只是作为初步移植而简单的带进来。其实是非常肯定它将不会被 ReactOS 里使用并且将由 Aleksey 所编写的 winent 驱动程序所取代。因此没有一位开发者工作于 ARWINSS 有任何的假象关于 X Windows 而且在X11 的注意力则突如其来的出现，因为这与他们的工作无关。

一个额外1要注意的一点是关于ARWINSS 和 Wine 在 Unix 的差别。因为 X Windows 系统一直都处在用户模式，要与它沟通需要某种远程过程调用而在很长的一段日子里 X Windows 提供少许的帮助以便让这些调用更廉价或者更快。相对于在用户模式和内核模式之间的系统调用，这样的操作显得很昂贵。这些局限将伤害了 Wine 的性能但是在 ReactOS 的 winent 驱动程序只是简单的执行syscalls 到 Win32k 的内核模式。

内存管理进展

Art Yerkes 的工作关于缓存控制分支已经在上几个月里看见重大的进，有了 Art 重新实现以及简化某些组件。其中一个要被重新实现的是平衡器，它会决定什么时候分页将需要被写出到磁盘。另一个相关组件是已被修改后的分页写入器，当Art 终于简化在分页时的资源锁定才能将它运作。当分页管理器需要逐出分页以便为新数据制造空间 (mpw)，它会尝试寻找未被更改的分页，或为“干净”，从而无需执行磁盘输入、出以便写出到该分页。其中一个调整以便帮助这个功能是定期在系统休闲时写出“肮脏”分页以便减少存在肮脏分页的数量，正是mpw 做的。可是，此前这个无法在 ReactOS 运作是由于理论上吸引人但是非常复杂的方法来处理同步内存操作。

原先在 ReactOS 的内存管理代码是相对简单而随着时间的过程更多的代码已被添加以便处理资源同步以及解除死机或避免它。一个尝试处理资源管理是pageops，它代表当它在特定进程里处理特定地址时故障处理的状态。Art 并不晓得其他人使用pageops 并且这个概念很可能是 David Welch 所建立，他是前ReactOS 内核的代表。可是，实现在ReactOS 却在页面故障处理器里出现大量复制的代码。这是由于需要记录当时其他故障处理器可能正在 访问还是做什么。Art 就在他的分支里移除 pageops，这是通过使用一个前哨价值以便将其他代码进程从敏感区中隔离直到它们被信号可以通过。当这是个非常简单的方法来应对共享访问，它是最直接和简单的方式以便开始运作。现在ReactOS 的优先权里，可以正常工作的功能比起理论上的最优化来的更高。

另一个 Art 做的更改是分页管理器如何决定输出什么分页并且在缺乏物理内存时重新使用它。之前所发生的是特定内存位置最终会将其被吃掉以便完成所提交的要求。假如：如果系统因为用户分页的关系而需要更多空间，用户分页将会被清洗以便完成这些要求。这在特定操作造成持续分页时造成重大的性能后遗症，由于分页管理器吃掉刚引进到物理内存的分页。分页管理器于 Art 的分支就带来更灵活的功能并且避免进入这样的状况。

Art 在他的分支里做的另一个重大更改是分页和段落是如何被映射。段落是内存界里的另一个抽象并且是由数个分页而组成。之前，唯一的方法来判断某个分页所属的段落是检查该段落所映射到的地址空间。可是，也有情况之下是当某个段落并没有映射到任何一个地址空间，这将在尝试将分页输出某个东西时造成后遗症。Art 发现到一个方法来辨别一个分页所属的段落是通过在内存管理器所使用的其中一个数据结构里借用几个比特来解决这个问题。

总的来说，所有完成的工作将使得分页在 ReactOS 里更加稳定，至少在Art 的分支。分页是在处理当操作系统或应用程序需要比物理内存还要多的内存的状况时显得重要。此前，从性能和数据完整二者的观点来看，ROS 以非常糟糕的方法处理它。现在 Art 能够安全的运行 ROS 在系统只有非常低的内存 (32MB)。比这样还低或许已经不太可能因为要考虑到代码的大小以及首先所需保留在内存的数据才能帮助完成分页的工作，尽管真的已经没有多少需要尝试降低内存，因为这样资源受限的系统恐怕只能够运行 ROS。

Ext2 支持

有了他的进展在缓存控制器处在良好的状况，Art 也成功让 ReactOS 启动并使用一个 ext2 分区。安装向导本身就不给予它的支持，所以Art 基本上就是引导 ReactOS 到一个分区并再使用 GRUB 来载入 freeldr。除了由 Pierre Schweitzer 所做的作品于文件系统运行时库，Art 只需做出少个添加。当中最简单的是移除 oplocks，一个功能主要依赖网络文件系统。其实没有本地文件系统需要它，可是 Matt Wu，他是 Art 目前所使用的 ext2 驱动程序的开发者，宁愿遵循编写文件系统驱动程序的指导原则并呼吁他们遵循这些推荐的做法。这巧合的让 Matt 的驱动程序可以作为的参照测试对象。我们也需要两个其他更复杂的添加 ，包括内存控制块以及锁定特定范围。这两者都牵涉到映射文件系统块到磁盘块。现在仍然需要几个基础设施的更改以便完整的使用 Art 和 Pierre 作品的优点。如刚才所提起的，现在安装向导其实不支持使用 ext2 分区并且引导器需要一些注意。尽管如此，这些将作为踏脚石以便在未来里使用更高级的文件系统并且目前正在开发新的 FAT 驱动程序很可能将会从这两人所做中惠及一切。最后，应该注意的一点是许多这些工作是在分开的分支而非在主干里进行，所以或许还需要一段时间里程碑点的发布才会提供这个功能。