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

时事通讯 63 期

by Z98 on 2009-07-31
translated by samuel1991 on 2010-01-05

测试中断

这几天以来自动化测试套件用于测试每个 ReactOS 版本抵达 MSI_Winetest 时就会停留于无限循环。在测试后，有几个人已经发现到这个问题并提出几个可能性但是Jeffrey Morlan 最终提交一个补丁似乎能够修正它。该问题似乎出现在LoadLibraryExW 函数，确切问题是在当已设置 LOAD_LIBRARY_AS_DATAFILE 标记。该函数接收为DllName 的输入，是一个被要求加载的库名称。若该库有空格，该函数将会分派一个私有副本并把它们给裁剪。一旦该函数完成自己的工作后，它会释放这个私有副本。可是，由Dmitry Chapysev 所提交的副本是试图把私有副本给释放，无论它是否正在使用。当该字串符不需要被裁剪时，却试图释放这个副本时将造成内存损坏，从而造成这个无限循环的问题。Jeffrey 的提交修正这个问题并且测试套件不再遇到这个问题。尽管测试套件看似无限死机，它也迅速揭发这个错误。否则，这个错误可能在很长的时间未被发现并最终以更严重的方式打击我们。

MSVC 的修正

Stefan Ginsberg 已经查看每个ReactOS 的模块以便处理数个语法问题阻止 MSVC 编译ReactOS。GCC 比起MSVC 在代码语法时会比较宽容，也由此一来某些在ReactOS 的常规代码对GCC 完全可以被接受时，将造成MSVC 失败。其中一个例子是样品函数的定义，当返回类型和调用常规的位置和分组时有所不同的时候。MSVC 预期调用常规和函数名称要由括号分隔，然而 GCC 却不需要这样做。这个特殊的问题分布于所有的代码但幸好这个问题要查找和修正的难度其实是相对容易的。

一个更麻烦的问题浮现在GCC 对自己调用的函数不会提出警告。虽然说这类递归调用是有自己的用途，但是在这个情况下的结果是更糟糕，因为这导致一个无限递归的调用。该问题源自于w32api 标题使用 mingw 以便于Windows 的开发。在标题上，函数ExAllocatePoolWithQuotaTag 已经被定义为ExAllocatePoolWithQuota。这造成一个非常奇怪的情况，由于ExAllocatePoolWithQuota 只包括简单的调用至 ExAllocatePoolWithQuotaTag 虽然前者函数的用途是为后者作为包装。已被编译的代码使用这些标题并试图使用ExAllocatePoolWithQuotaTag 函数也极可能导致无限循环，最终使得堆栈不胜负荷而造成蓝屏。即使MSVC 的警告程度为最低时也发现这个问题并对此给予警告，然而 GCC 似乎并没有发现或者在乎这个问题。

ARWINSS 已经回来了

由于对 ARWINSS 的表达式数量有限，所以对于它的作用似乎仍然存在相当可观的疑惑。许多人解读为Win32 子系统的替代品，然而它却不是。这是因为此前没有做出明确的声明并导致一些泛滥的推测。有鉴于此， Aleksey Bragin 已经声明 ARWINSS 的用意是存在为临时措施，将利用Wine 在运行 Windows 应用程序的进展以便使得 ReactOS 有更加多功能。人们仍然回忆那段0.3.1 发布的那段日子里当ReactOS 超级不稳定。内核重写的进展是非常缓慢但在移除所有之前允许系统运作的破解。由于组件之间瓦解，开发者正在处理其他组件也受到很大的负面影响直到破解已完全被移除后，这从而导致开发过程缓慢许多了。为了修正 Win32 子系统就需要相同程度的中断是因为关键性的组件有一些严重的问题。Jim Tabor 和 Timo Kreuzer 两人已经挣扎以确保在重写系统时将倒退问题最小化，但这是个来回的战斗。有些东西需要存在，然而某些重大的重构和重新编写仍在进行中而这是ARWINSS 能够使用的场合。虽然它是否能够长期在位则有待观察，因为它们之间的差别能够进行那些在现有 Win32 子系统所不能进行的实验。

即使考虑到这一点，不是每个人都同意ARWINSS 的必要性。原先有几位开发者认为 Aleksey 试图在主干里取代Win32 子系统并对此存在不良反应。虽然对此澄清后，可是仍然有些顾虑于ARWINSS 将会分散当前重写的注意力。尽管如此，ARWINSS 整体上也是在揭穿一些在操作系统里的有些有趣的问题。我们真的希望ARWINSS 能够对工程做出正面的贡献，但是只有时间才能告诉这一切。