原文地址：http://www.reactos.org/zh/interview_6.html
by Klemens Friedl on 2006-12-28

Art，在 1974 年出生于费城，PA，美国。自从 2002 年以来他一直都参与 ReactOS 的活动并主要贡献在 Win32 的键盘代码以及网络代码。最近许多的作品都是与网络相关的工作，以及逐渐的诞生 PowerPC 架构的移植。
   开始
您是如何参与 ReactOS？
我在网络上看过 ReactOS 首批图片运行 GDI （图形，但没有窗口）测试程序并继续观看而听过它。我希望参与并在为 loadros 和 kernel32 编写一些补丁之后获得这个机会。
所以到那时之前您都是为 Unix 编写程序？
自从放开 16 位的 Windows 编程以及其 Windows 95 和 98 的脆弱环境之后，我一直以来都是位主导 Unix 的人士。我当时在处理 ReactOS 之前真的不了解关于原生 API 和 Win32 API 之间的关联，但是我从中学习了许多并且在我未来的工作中编写 Windows 应用程序的过程相对的较简单了。我不晓得谁能够在搜索并比较于 Wine 和 ReactOS 代码之前写出 Windows 的稳定商业软件。
我喜欢 Unix 模式以及 Unix 的软件开发哲学。Unix 的应用程序一般上不会不自量力并且时常以可靠性作为构建的主要目标。比起围绕在 Windows 对此非常漠不关心的开发社区是极大的反差。事实证明，为什么 Windows 应用程序在 90 年代的一段时间里有非常复杂的原因为什么非常糟糕的可靠性，
尽管此后Windows 软件整体上以稳定性而言已经算是进步了一大级别。
话虽如此，我已经完全适应两个环境。
您是否有任何 Windows 的经验？或者您是在不得已的情况下才学的？
我有一些，足以成为危险人物，但不足以了解原生 API。我对 Win32 看似对多数当我在做我的工程工作时所学的良好的做法不配而感到非常失望。我所学到到是Win32 总是 在优雅的外层上安装并且有个非常瘦小的 Windows 内核。一旦在美国的反托拉斯诉讼案的影响变得明显后，原生 API 的说明书（此前都是某些人有那种时间窥探或者有那些有特权访问的人士们所专属的地区），已经变得广泛使用被微软本身所记载的说明。 这也有助于我的能力去明锐的观察 Windows 是如何组装在一起
并成为一位更成功的Windows 编程员，与此同时也帮助编写 ReactOS。
您是否还记得您所提交的第一个补丁？
那个是现在已经不复存在的loadros 磁盘操作系统 (DOS) 的程序。我对 DOS 命令行的长度限制过短并且所有的驱动程序以及注册表配置单元都在那里指定而感到很恼火。
当我尝试增加一个驱动程序，我就缺乏空间，所以我扩展了 loadros 以便直接从文件中读取。
您是否还记得您第一次对 ReactOS 做了什么工作？
我在 ReactOS 做的第一个重大工作是在 Win32k 的键盘代码，包括载入Windows 样式的键盘 DLLs。这个过程很好玩并且我从中学习了许多关于多语文支持的知识。

    与 ReactOS 所在的乐趣
您最喜欢处理ReactOS 的哪个部分？
说真的我并没有最爱的范围，可是我对网络代码有些经验。为此，处理 tcpip 是个合适我做的地方。
您所做的什么工作是当中最具有挑战性的？
移植到 PowerPC (PPC)。若要完成它，我就需要恢复一个方法，以生成为 PowerPC 可执行程序的 pe-coff, little endian，并且学习许多关于 PowerPC 架构以及某些 PowerPC 硬件的种类。如往年一样，我有非常稳定的工具并且能够良好运行以及有个能够在一台 G3 的麦金塔里运行一个兼容于Open Firmware 的 freeldr。我才刚刚开始进入 Windows Internals （Windows 内部，一本书籍）并且开始实现 PPC 的内核部分。
如果您有一样东西希望 ReactOS 能够做到，那会是什么？还是那个已经完成了？
我很高兴当 GvG 首次能够让 Firefox（火狐）载入一个页面。Hpoussin 让我感到高兴，因为他接受我疯狂点子的一个分支 (green.sys) 并且真的转化成一个美好的东西。
您已经为 ReactOS 的网络（架构）付出许多了。除此之外，您还真的喜欢什么部分？
如果我能给一句忠言，我会给的是“把一切您所能做的都放在库里，如此一来就可以链接到用户模式的应用程序”。我和 Royce Mitchell 在从 Oskit 导入 TCP 时做到了。这也提供我们一个非常清楚的调试环境以便帮助我们的进展。我不相信我能够在不使用如上的方式下写出新的内核代源码。
您想要处理 ReactOS 的那些工作范围？
我现在深陷于移植工作，但这也会帮助我进入两样令我感到困惑的东西，但是目前我没能力深入其中。ReactOS 的MM（Memory Manager, 内存管理器）和 CC（Common Cache, 共同缓冲）并没有与真正 Windows 有应有的兼容性（尤其是CC），而且我非常希望看到 ext2 驱动能够在 ReactOS 下运行。我已经与 Hartmut (PBUH) 和 Filip 参与一个分支以便尝试它，但最终我并没有贡献多少。当我在相关领域中学会更多后，我希望能够做出更加可观的贡献。
您也为 ReactOS 做了什么其他的东西？
我将自己视为 ReactOS 的一种倔老头以及口述历史家以及一名编程员。可能我在这个程度上没人要，但是是我认为它有个好处并且是自然过来的东西。
当我在频道 (IRC) 时，我试图作为正人+o 并且在频道内避免过于激动或个人化。

    会议
谈到 Wineconf，那是不是您第一次见到其他参与者？谁是当中您曾见过最有趣的人？
是的，当时于一月寒冷的天气在明尼苏达州遇见大家确实真的很好玩。我真的很失望我们与 Wine 工程人士的关系没有更加好。从我的观点，我们正在竞争，但是我们好像在竞争以家具搬上大楼的第二层；最终我们有相同的目标，即使走的方向是不同的。
您已经给了许多关于 ReactOS 的会议及讲座，您觉得遇见其他开发者是否有用？
是的，遇见其他开发 ReactOS人士的过程非常棒，并且我推荐每个人有能力的情况下都应该至少做一次。
那么在您曾经到访过的地方中，那一个是您最喜欢的地方？
肯定明尼苏达州。我曾经考虑在那里居住。
    工作
您有哪些 ReactOS 的地方是从来未涉足过？
在内核世界里，我不曾做过 USB, PnP, ACPI, 或 HAL （硬件抽象层）。 在用户世界里，我从来没动过shell32, comctl32 和其家族。
您对 ReactOS 所添加当中那一个是最有趣的？
我们的 AFD 是设计的非常好并且以简洁的代码下完成所需要的功能。我对此感到十分自豪。
您现在是否正在处理任何重大的 ReactOS 工程？
虽然已经超过两年（多数的部分里有大约一年休假），我一直都在进行非常缓慢但扎实的进展朝向 ReactOS 能在 PowerPC 里运作成为一个事实。
为什么？这是因为我一直所要接收的工程并且 ReactOS 是个独特的机会。我要 ReactOS 运行于 PowerPC 麦金塔以及 PReP boxen ，如我的 Thinkpad 860。既然其他操作系统的引导程序能够在 Playstation 3 里可用，我们或许能够探讨在 Cell 处理器 64 位的移植问题，利用 PowerPC 32 位为起始点，尽管64 位的 mingw toolchain 在英特尔世界里还未出现。
多半，这将使我继续参与ReactOS 工程的乐趣并保持我的联系。当我第一次能够在真实硬件 VGA里看到笑脸启动标志于我的麦金塔时，我当时真的欣喜若狂。
您是否曾经工作于 ReactOS 的任何其他部分？
我曾经写过我们的小DnsAPI 实现于 GNU 增加之上，这是超级酷的。
您使用什么开发环境？
我为 X86 环境里使用 64 位的 Gentoo 箱并且使用麦金塔 G3 以及一台 Thinkpad 860 来完成某些 PPC 移植的环节。
当然，人们会问最明显的问题是：为什么有人要运行一个 Windows 的克隆？为何不要直接运行真的东西？
其实，我与许多人所聊起的结果是（很可能是因为我个人一向来都深入在高科技社区）有了这个概念关于为应用程序软件提供一个能够运行于公平竞争环境的支配操作系统而无需担心制作多一个接口或者多一位用户将会在某个程度违反许可协议并在法律上感到无助。如果这句话，“最近的微软操作系统对于最终用户许可协议已经算是相当严厉”，听起来太夸张，那就表示您没有仔细阅读它。在可用性方面以及如何使用操作系统所收集的资料都有令人感到不安的地方。 ReactOS 是个开源、免费的操作系统软件将提供必要的现实检查以确保商业软件制造商不会成为一个寡头并限制用户的自由和褫夺更多用户私人信息的自由权。
所以除了 ReactOS 之外，您是否也参与其他的工程？
我是一个处于休眠状态的 SWIG Ocaml 模块维护者，并且我也编写 pycaml，对此我在某个程度上感到自豪。
您已经提出一些术语对于一些人可能听的不太熟悉。能否解释其中的一些？
AFD 是 Ancillary Functions Driver（辅助功能驱动程序）。换句话说，它是*其他*东西应该去的地方 。说真的，那是个驱动能够提供美丽 BSD 内核部分的接口到无情冷漠的 TDI 之上。
您是如何去开发这些东西？
我试图找个时间，通常在晚间时分，当我能够坐下来，并在我房里开音乐然后尽量集中精力在这些工程身上。我现在的状况下将会比较困难而且我的生产力不及以往。

    未来
如果您能够增加'一个'功能到 ReactOS，那会是什么？
我想要添加 Samba 文件系统，可是我认为我们应该先处理好缓冲管理器。 在这个情况下，我们最好还是谨慎的等待，因为我们真的互不兼容。
您认为哪一个 ReactOS 开发的部分最需要处理的？
缓冲管理器将是个无法去除的问题直到有人将它 100% 的修正问题。这是个浩大的工作而且难以分工。音响是个大毛球里共存但有时却是相互竞争的 API，而每个东西将在不同的应用程序类里呈现不同的性能模式。Silverblade 在这方面已经做得非常出色，因为他只通过其开始点来决定一切并且已经把相关事务弄得正确。
您有没有希望 ReactOS 能够做到，但现在不能？
每当一段时间里，当我再次于 Cygwin 里调试，我希望我能见到一些进展。我们已经非常靠近让 Cygwin 应用程序运行一段时间，但是Cygwin 所涵盖的 API 是非常广泛的，也因此需要一些时间才能让 ReactOS 足以使用它。这是令人感到难过因为我们能够从中受惠。
ReactOS 是否需要更多受虐狂的开发者来处理未记载的东西？
我们能够使用好的工程师来排除已记载的功能。我并不认同在 ReactOS 里必须先实现每样东西才能使得内部首次运作。我们近期来当正在忙于使得内部能够调谐的工作时却已经在用户可见的功能上出现倒退现象，而我对此感到十分羞耻。
您是否有特定关于 ReactOS 应该集成什么东西但却没有的点子吗？ReactOS 现在是否显得过多的移动目标？
在某种程度上，我认为现在 ReactOS的不稳定对我的用处不大。这不是任何单一个人的过失但是出于本身的需要，如今我现在不能再次那么的投入。
您是否曾经希望那里有更多的开发者？
是的。我非常想念Royce 和 gvg。
您是否曾经希望外头有个 ReactOS 的发行版？
是的，而且它一定会发生。唯一一样东西阻止 ReactOS 的是它还不够准备让人关于每次升级 ROS 时就必须重新安装 Abiword 而感到愤怒。一旦我们有了一些观众，就会出现一批'高级用户'人潮来利用其 ReactOS 工作光盘 (LiveCD，无需安装的光盘) 的简易度来制作某种形式的轻巧 ReactOS 拯救盘。（类似某种备份后的系统）
您认为ReactOS 是否有其他的东西必须给予专注？
我们必须集中精力记住为什么我们会这么做。我认为我们最近已经非常严格，并且已经失去以前处理 ReactOS 工作的乐趣的视线。因为没有人能够领到薪水，所以乐趣是真的唯一能够激发我们继续做下去。
如果工作于 ReactOS 已经不再有任何奖励，因为它已经太过于结构化或者过于敌视的环境下，那么开发者就会离开。我认为我们曾经见过这样的问题而且不幸的我们还会有更多的案例直到情况改善后。
    兼容性
您认为 .Net 会不会给予 ReactOS 过时？
不会。
您认为 .Net 会不会给予 WinAPI 过时？
不会。
您认为现在 ReactOS 有什么需要专注于的应用程序支持？
Office，游戏， Flash 以及传统应用程序。如果我们能够在当中每个组别里运行多数的应用程序，那么我们就赢了。
那么关于 dotNet 的支持呢？我想到的两个东西是 Mono 和 dotGNU。
对我们而言这不是问题。我们将应用现有免费及自由的实现并放在一起，作为 mscore 的替代品。随着这些实现越来越扎实，我们的 .Net 支持也会随之改善的。
    与公司互动
在说服您的老板让您向自由软件界贡献究竟是多困难的？
我其实已经有好几次工作于开源软件以获取我的薪水。我最新的作品是为我的雇主做个SWIG 的 C# 模块。
    结尾
最后感想？
我最近又有了多于的时间投入在 ReactOS，并且它已经允许我在我的子工程里获得可观的好处。希望我能做近期里又能够做出一些有趣及有用的贡献。我现在一直都存在即使有时我有超过 60 小时的工作星期从而避免我对其做出多大的贡献。我希望能够继续成为 ReactOS里最佳的倔老头，坚定朋友以及口述历史家。
    恭喜您目前所有的成就并且感谢您花费这个时间接受本采访。

ReactOS团队成员访谈录-"Art Yerkes"
原文地址：http://www.reactos.org/zh/interview_6.html
by Klemens Friedl on 2006-12-28
Art Yerkes
由 Klemens Friedl 与 Art Yerkes 进行的采访
这是第六个与 ReactOS 开发者进行采访的采访系列。这几个星期里，我们将会有个好的收集关于展示 ReactOS 背后的人才。
Arty
http://www.reactos.org/media/pictures/2006/arty.jpg
Art，在 1974 年出生于费城，PA，美国。自从 2002 年以来他一直都参与 ReactOS 的活动并主要贡献在 Win32 的键盘代码以及网络代码。最近许多的作品都是与网络相关的工作，以及逐渐的诞生 PowerPC 架构的移植。
    开始
您是如何参与 ReactOS？
我在网络上看过 ReactOS 首批图片运行 GDI （图形，但没有窗口）测试程序并继续观看而听过它。我希望参与并在为 loadros 和 kernel32 编写一些补丁之后获得这个机会。
所以到那时之前您都是为 Unix 编写程序？
自从放开 16 位的 Windows 编程以及其 Windows 95 和 98 的脆弱环境之后，我一直以来都是位主导 Unix 的人士。我当时在处理 ReactOS 之前真的不了解关于原生 API 和 Win32 API 之间的关联，但是我从中学习了许多并且在我未来的工作中编写 Windows 应用程序的过程相对的较简单了。我不晓得谁能够在搜索并比较于 Wine 和 ReactOS 代码之前写出 Windows 的稳定商业软件。
我喜欢 Unix 模式以及 Unix 的软件开发哲学。Unix 的应用程序一般上不会不自量力并且时常以可靠性作为构建的主要目标。比起围绕在 Windows 对此非常漠不关心的开发社区是极大的反差。事实证明，为什么 Windows 应用程序在 90 年代的一段时间里有非常复杂的原因为什么非常糟糕的可靠性，
尽管此后Windows 软件整体上以稳定性而言已经算是进步了一大级别。
话虽如此，我已经完全适应两个环境。
您是否有任何 Windows 的经验？或者您是在不得已的情况下才学的？
我有一些，足以成为危险人物，但不足以了解原生 API。我对 Win32 看似对多数当我在做我的工程工作时所学的良好的做法不配而感到非常失望。我所学到到是Win32 总是 在优雅的外层上安装并且有个非常瘦小的 Windows 内核。一旦在美国的反托拉斯诉讼案的影响变得明显后，原生 API 的说明书（此前都是某些人有那种时间窥探或者有那些有特权访问的人士们所专属的地区），已经变得广泛使用被微软本身所记载的说明。 这也有助于我的能力去明锐的观察 Windows 是如何组装在一起
并成为一位更成功的Windows 编程员，与此同时也帮助编写 ReactOS。
您是否还记得您所提交的第一个补丁？
那个是现在已经不复存在的loadros 磁盘操作系统 (DOS) 的程序。我对 DOS 命令行的长度限制过短并且所有的驱动程序以及注册表配置单元都在那里指定而感到很恼火。
当我尝试增加一个驱动程序，我就缺乏空间，所以我扩展了 loadros 以便直接从文件中读取。
您是否还记得您第一次对 ReactOS 做了什么工作？
我在 ReactOS 做的第一个重大工作是在 Win32k 的键盘代码，包括载入Windows 样式的键盘 DLLs。这个过程很好玩并且我从中学习了许多关于多语文支持的知识。
    与 ReactOS 所在的乐趣
您最喜欢处理ReactOS 的哪个部分？
说真的我并没有最爱的范围，可是我对网络代码有些经验。为此，处理 tcpip 是个合适我做的地方。
您所做的什么工作是当中最具有挑战性的？
移植到 PowerPC (PPC)。若要完成它，我就需要恢复一个方法，以生成为 PowerPC 可执行程序的 pe-coff, little endian，并且学习许多关于 PowerPC 架构以及某些 PowerPC 硬件的种类。如往年一样，我有非常稳定的工具并且能够良好运行以及有个能够在一台 G3 的麦金塔里运行一个兼容于Open Firmware 的 freeldr。我才刚刚开始进入 Windows Internals （Windows 内部，一本书籍）并且开始实现 PPC 的内核部分。


如果您有一样东西希望 ReactOS 能够做到，那会是什么？还是那个已经完成了？
我很高兴当 GvG 首次能够让 Firefox（火狐）载入一个页面。Hpoussin 让我感到高兴，因为他接受我疯狂点子的一个分支 (green.sys) 并且真的转化成一个美好的东西。
您已经为 ReactOS 的网络（架构）付出许多了。除此之外，您还真的喜欢什么部分？
如果我能给一句忠言，我会给的是“把一切您所能做的都放在库里，如此一来就可以链接到用户模式的应用程序”。我和 Royce Mitchell 在从 Oskit 导入 TCP 时做到了。这也提供我们一个非常清楚的调试环境以便帮助我们的进展。我不相信我能够在不使用如上的方式下写出新的内核代源码。
您想要处理 ReactOS 的那些工作范围？
我现在深陷于移植工作，但这也会帮助我进入两样令我感到困惑的东西，但是目前我没能力深入其中。ReactOS 的MM（Memory Manager, 内存管理器）和 CC（Common Cache, 共同缓冲）并没有与真正 Windows 有应有的兼容性（尤其是CC），而且我非常希望看到 ext2 驱动能够在 ReactOS 下运行。我已经与 Hartmut (PBUH) 和 Filip 参与一个分支以便尝试它，但最终我并没有贡献多少。当我在相关领域中学会更多后，我希望能够做出更加可观的贡献。
您也为 ReactOS 做了什么其他的东西？
我将自己视为 ReactOS 的一种倔老头以及口述历史家以及一名编程员。可能我在这个程度上没人要，但是是我认为它有个好处并且是自然过来的东西。
当我在频道 (IRC) 时，我试图作为正人+o 并且在频道内避免过于激动或个人化。
当事情过于激烈竞争时，我会尝试权衡并希望提供一个监督的力量。我不晓得我在那方面是否做得成功。
我说的是 1978 年的美德并且我补充我的论点，当时是西方文明的顶峰。
1978 年？现在的方式？
对。
    会议
谈到 Wineconf，那是不是您第一次见到其他参与者？谁是当中您曾见过最有趣的人？
是的，当时于一月寒冷的天气在明尼苏达州遇见大家确实真的很好玩。我真的很失望我们与 Wine 工程人士的关系没有更加好。从我的观点，我们正在竞争，但是我们好像在竞争以家具搬上大楼的第二层；最终我们有相同的目标，即使走的方向是不同的。
您已经给了许多关于 ReactOS 的会议及讲座，您觉得遇见其他开发者是否有用？
是的，遇见其他开发 ReactOS人士的过程非常棒，并且我推荐每个人有能力的情况下都应该至少做一次。
那么在您曾经到访过的地方中，那一个是您最喜欢的地方？
肯定明尼苏达州。我曾经考虑在那里居住。
    工作
您有哪些 ReactOS 的地方是从来未涉足过？
在内核世界里，我不曾做过 USB, PnP, ACPI, 或 HAL （硬件抽象层）。 在用户世界里，我从来没动过shell32, comctl32 和其家族。
您对 ReactOS 所添加当中那一个是最有趣的？
我们的 AFD 是设计的非常好并且以简洁的代码下完成所需要的功能。我对此感到十分自豪。
您现在是否正在处理任何重大的 ReactOS 工程？
虽然已经超过两年（多数的部分里有大约一年休假），我一直都在进行非常缓慢但扎实的进展朝向 ReactOS 能在 PowerPC 里运作成为一个事实。
为什么？这是因为我一直所要接收的工程并且 ReactOS 是个独特的机会。我要 ReactOS 运行于 PowerPC 麦金塔以及 PReP boxen ，如我的 Thinkpad 860。既然其他操作系统的引导程序能够在 Playstation 3 里可用，我们或许能够探讨在 Cell 处理器 64 位的移植问题，利用 PowerPC 32 位为起始点，尽管64 位的 mingw toolchain 在英特尔世界里还未出现。
多半，这将使我继续参与ReactOS 工程的乐趣并保持我的联系。当我第一次能够在真实硬件 VGA里看到笑脸启动标志于我的麦金塔时，我当时真的欣喜若狂。


您是否曾经工作于 ReactOS 的任何其他部分？
我曾经写过我们的小DnsAPI 实现于 GNU 增加之上，这是超级酷的。
您使用什么开发环境？
我为 X86 环境里使用 64 位的 Gentoo 箱并且使用麦金塔 G3 以及一台 Thinkpad 860 来完成某些 PPC 移植的环节。
当然，人们会问最明显的问题是：为什么有人要运行一个 Windows 的克隆？为何不要直接运行真的东西？
其实，我与许多人所聊起的结果是（很可能是因为我个人一向来都深入在高科技社区）有了这个概念关于为应用程序软件提供一个能够运行于公平竞争环境的支配操作系统而无需担心制作多一个接口或者多一位用户将会在某个程度违反许可协议并在法律上感到无助。如果这句话，“最近的微软操作系统对于最终用户许可协议已经算是相当严厉”，听起来太夸张，那就表示您没有仔细阅读它。在可用性方面以及如何使用操作系统所收集的资料都有令人感到不安的地方。 ReactOS 是个开源、免费的操作系统软件将提供必要的现实检查以确保商业软件制造商不会成为一个寡头并限制用户的自由和褫夺更多用户私人信息的自由权。
所以除了 ReactOS 之外，您是否也参与其他的工程？
我是一个处于休眠状态的 SWIG Ocaml 模块维护者，并且我也编写 pycaml，对此我在某个程度上感到自豪。
您已经提出一些术语对于一些人可能听的不太熟悉。能否解释其中的一些？
AFD 是 Ancillary Functions Driver（辅助功能驱动程序）。换句话说，它是*其他*东西应该去的地方 。说真的，那是个驱动能够提供美丽 BSD 内核部分的接口到无情冷漠的 TDI 之上。
您是如何去开发这些东西？
我试图找个时间，通常在晚间时分，当我能够坐下来，并在我房里开音乐然后尽量集中精力在这些工程身上。我现在的状况下将会比较困难而且我的生产力不及以往。
    未来
如果您能够增加'一个'功能到 ReactOS，那会是什么？
我想要添加 Samba 文件系统，可是我认为我们应该先处理好缓冲管理器。 在这个情况下，我们最好还是谨慎的等待，因为我们真的互不兼容。
您认为哪一个 ReactOS 开发的部分最需要处理的？
缓冲管理器将是个无法去除的问题直到有人将它 100% 的修正问题。这是个浩大的工作而且难以分工。音响是个大毛球里共存但有时却是相互竞争的 API，而每个东西将在不同的应用程序类里呈现不同的性能模式。Silverblade 在这方面已经做得非常出色，因为他只通过其开始点来决定一切并且已经把相关事务弄得正确。
您有没有希望 ReactOS 能够做到，但现在不能？
每当一段时间里，当我再次于 Cygwin 里调试，我希望我能见到一些进展。我们已经非常靠近让 Cygwin 应用程序运行一段时间，但是Cygwin 所涵盖的 API 是非常广泛的，也因此需要一些时间才能让 ReactOS 足以使用它。这是令人感到难过因为我们能够从中受惠。
ReactOS 是否需要更多受虐狂的开发者来处理未记载的东西？
我们能够使用好的工程师来排除已记载的功能。我并不认同在 ReactOS 里必须先实现每样东西才能使得内部首次运作。我们近期来当正在忙于使得内部能够调谐的工作时却已经在用户可见的功能上出现倒退现象，而我对此感到十分羞耻。
您是否有特定关于 ReactOS 应该集成什么东西但却没有的点子吗？ReactOS 现在是否显得过多的移动目标？
在某种程度上，我认为现在 ReactOS的不稳定对我的用处不大。这不是任何单一个人的过失但是出于本身的需要，如今我现在不能再次那么的投入。
您是否曾经希望那里有更多的开发者？
是的。我非常想念Royce 和 gvg。
您是否曾经希望外头有个 ReactOS 的发行版？
是的，而且它一定会发生。唯一一样东西阻止 ReactOS 的是它还不够准备让人关于每次升级 ROS 时就必须重新安装 Abiword 而感到愤怒。一旦我们有了一些观众，就会出现一批'高级用户'人潮来利用其 ReactOS 工作光盘 (LiveCD，无需安装的光盘) 的简易度来制作某种形式的轻巧 ReactOS 拯救盘。（类似某种备份后的系统）
您认为ReactOS 是否有其他的东西必须给予专注？
我们必须集中精力记住为什么我们会这么做。我认为我们最近已经非常严格，并且已经失去以前处理 ReactOS 工作的乐趣的视线。因为没有人能够领到薪水，所以乐趣是真的唯一能够激发我们继续做下去。
如果工作于 ReactOS 已经不再有任何奖励，因为它已经太过于结构化或者过于敌视的环境下，那么开发者就会离开。我认为我们曾经见过这样的问题而且不幸的我们还会有更多的案例直到情况改善后。
    兼容性
您认为 .Net 会不会给予 ReactOS 过时？
不会。
您认为 .Net 会不会给予 WinAPI 过时？
不会。
您认为现在 ReactOS 有什么需要专注于的应用程序支持？
Office，游戏， Flash 以及传统应用程序。如果我们能够在当中每个组别里运行多数的应用程序，那么我们就赢了。
那么关于 dotNet 的支持呢？我想到的两个东西是 Mono 和 dotGNU。
对我们而言这不是问题。我们将应用现有免费及自由的实现并放在一起，作为 mscore 的替代品。随着这些实现越来越扎实，我们的 .Net 支持也会随之改善的。
    与公司互动
在说服您的老板让您向自由软件界贡献究竟是多困难的？
我其实已经有好几次工作于开源软件以获取我的薪水。我最新的作品是为我的雇主做个SWIG 的 C# 模块。
    结尾
最后感想？
我最近又有了多于的时间投入在 ReactOS，并且它已经允许我在我的子工程里获得可观的好处。希望我能做近期里又能够做出一些有趣及有用的贡献。我现在一直都存在即使有时我有超过 60 小时的工作星期从而避免我对其做出多大的贡献。我希望能够继续成为 ReactOS里最佳的倔老头，坚定朋友以及口述历史家。
    恭喜您目前所有的成就并且感谢您花费这个时间接受本采访。