原文地址：http://www.reactos.org/zh/newsletter_62.html
时事通讯 62 期
by Z98 on 2009-07-21
translated by samuel1991 on 2010-01-05
   PSEH 损坏
在NT 操作系统下，结构例外的处理已被使用作为在内核模式时保障探究用户模式的内存缓冲和分页内存。这个需求从而推动由 KJK::Hyperion 所创作的PSEH 库。这是由于GCC 不支持相关的功能。自从上次试图对 GCC 增加 SSH 的支持失败后， ReactOS 保留依赖于PSEH。最近，ARM 团队提交一些代码从而揭发一个在PSEH 库的麻烦错误并且由KJK 主导的调查该问题在分析代码时又发现另一个错误。这两个错误是非常严重的，因为它们将在发生例外时造成重大的问题。
第一个错误牵涉到嵌套的 try/catch 块，当一个例外被调用并在内层块抓到并且另一个例外则是在外层块中被调用，代码将不会跳到外层块的 catch 句子而是内层块。执行的过程则会再次于内层块继续执行。由于代码时刻都被跳回去，这将导致一个无限循环。这正是发生在trylevel 内层块并没有在代码离开该块时弹出并留在该堆栈中。这导致PSEH 认为它还在内层快。
这当然导致在错误被触发时操作系统无法使用，正是在ARM 提交之后并在自动化测试时结合以便触发它。有了Stefan Ginsberg 的一些帮助，KJK 能够找出在嵌套try/catch 块的错误根源并且现在自动化测试又恢复正常了。
T第二个错误是与第一个类似，是在例外的执行框架并没有从堆栈中移除，这将是一个完全随机的结果。真正的坏事是此错误也能够在没有嵌套 try/catch 块时触发。如此一来即使没有导致操作系统瘫痪，它也基本上导致随机堆栈损坏并且也能够影响其他东西以致难以追查损坏。既然这个现象每次在 SEH 提出例外时发生，若它正是自从引进 PSEH 2 后许多随机崩溃 ReactOS问题的导因将不会令人感到意外。讽刺的是，一个相同的问题也存在于PSEH1 并且有了相同的修正。KJK 的PSEH 测试套件也帮忙了，有一次他添加一个缺失的完整性检查。当然，增加该检查导致他的代码在多数的测试中失败直到他修正该问题。
   XLATEOBJ
XLATEOBJ 是一个有几个相关函数的数据结构以便帮助在不同表层之间翻译颜色，比如从位图到显示格式的颜色。既然这个操作时常都在发生，因此它必须快速执行。很遗憾 ReactOS 的实现并不是，当其中的一个函数使用一系列的if/else 句子以决定如何执行翻译。Timo Kreuzer 应用回调功能在需要时才做应该做的事并在特殊格式里有几个优化过的函数来取代它。另一个 Timo 想要做的更改是与其让它每次在 BitBlt 操作时从分页池中动态分派XLATEOBJ ，现在将从堆栈里分派。
通常一个像素对像素的翻译是在翻译颜色格式之间时完成。正如其名称所说的，当使用一个画笔模式时，一个小部分的模式将被应用在目标表层上。在画笔使用之前，一个调用到驱动的程序已由 GDI 通过DrvRealizeBrush 函数来完成以便翻译画笔模式到目标表层的颜色格式。这就称之为目标实现。与此同时， GDI 能够在驱动报告显示卡不支持该功能时创建自己的画笔目标实现。 ReactOS 此前没有这么做，可是Timo 已经在他的工作副本上做出更改并确保在提交后并不会打断任何东西。
   Arwinss
Aleksey Bragin 最近开始一个名为Arwinss 的分支，似乎代表以另一个形式重写的Win32 子系统。他也发出一封电邮来解释为什么他这创建它并选择这样的方式。该总结的论证是归功于 Aleksey 对当前Win32 子系统的不满并且也有许多错误。当其他几位开发者也付出了许多时间并努力尝试让该系统运作，那里仍然有持久的严重错误。许多这类的问题是由于过去的破解和错误的实现所致并且要修正它们基本上是代表要重写整个子系统。Aleksey 因此觉得采取进一步的事情，即为基本上重新实现每样东西。
该分支有相当可观的Wine 代码，由最新 Wine 发布所引进的。这次的差别是Wine 的架构是原封不动。Windows 的层次调用可以说是令人惊讶的复杂，许多却不在 Wine 里复制。Aleksey 选择这个简单化并凝聚层。他也为此在子系统的内核部分创建一个相对较小的win32k 组件，同样的借用一些Wine 代码来提供 Wine 用户模式 DLLs 的接口更加容易但添加他自己的更改以便让整个东西能在 NT 操作系统里能够运作。这些更改很可能是最具有争议性的。在当前的情况下使用该分支，以Kamil Hornicek 的说法是，感觉上就在使用ROS 0.1.0。文本显示是完全错位以及压碎在一起，并且颜色翻译的问题导致预料的蓝色标题栏变成褐色。预期这将随着越来越多的组件放置在
正确的
地方而带来改善，可是其功能则在那时之前将被削弱。
有几位开发者为此评论 Aleksey 的作品并且不是每一位都支持这样的方式。Timo Kreuzer 指出长远以来，这有伤害正确的实现 Win32 子系统的风险。Timo 是其中一位开发者主张正确的实现并复制 Win32 接口以及其设计连同于所有相关的阶层。虽然在初期里看似有许多不必要的工作，Timo 深信这会造成一个更兼容的系统过 Wine所能够达到的。这是因为 Wine 所采取的捷径。
Aleksey 的小工程极可能造成一些风波，至少在与其他开发者所关注的问题能够和解之前。与此同时，它也能够带来重新开始的可能性从头开始完成实现而无需破解。只有时间才能最终告诉这样的做法是否可行。