原文地址：http://www.reactos.org/zh/interview_2.html
ReactOS团队成员访谈录-"Alex Ionescu"
by Klemens Friedl on 2006-11-21
Alex Ionescu
由 Klemens Friedl 与 Alex Ionescu 进行的采访
这是第二个与 ReactOS 开发者进行采访的采访系列。这几个星期里，我们将会有个好的收集关于展示 ReactOS 背后的人才。
Alex Ionescu （右旁的那一位）
Alex Ionescu 是在 1986 年出生于布加勒斯特，罗马尼亚（欧洲）。他目前居住在蒙特利尔，加拿大并且是康科迪亚大学软件工程系的学生。他自从 2004 年以来一直都参与 ReactOS 的活动并且已经为许多不同的部分做出贡献。最近他的许多作品都是围绕在内核和HAL （硬件抽象层）相关的工作。
    开始
您是如何参与 ReactOS？
当我对编写自己的操作系统感到十分兴趣的时候我就与 ReactOS 接触并且也在发现 NT 内核和其服务是多么良好及丰富的设计。我原先对 ReactOS 没有抱上多大的希望直到我看到 0.2.0 的发布，终于增加一个图形界面。我在 0.2.2 的时候开始加入并且开始提供小补丁。在那时候我完全不会 C 语言。
所以到那时之前您都是为 Windows 编写程序？
是的，我是工作于组合语言，研究计算机病毒，以及编写 VB 程序来揭发某些 NT 内核和服务的功能。
您是否还记得您所提交的第一个补丁？
是的，它是个非常简单的补丁以便在内核里被 Ps（进程管理器）所杀的线程时能够保存线程的退出时间。
您是否还记得您第一次对 ReactOS 做了什么工作？
我第一个真正的工作是添加为数大约 1400 位存根到内核。直到那时之前，原先的概念只不过是只有函数被导出后将会事先被实现。这是非常糟糕的，因为如果一个函数不存在时，驱动程序则完全不会被加载。事实上最好有所有的函数存在，然后再存根它。至少驱动程序会先载入而且您可以查看其他 API 是否能够完好运行，您可能最终都无需该 API 也能够完好运作。
    与 ReactOS 所在的乐趣
您最喜欢处理ReactOS 的哪个部分？
多数我最喜欢处理 HAL（硬件抽象层），因为它是与内核一样低的层次但是比较分割又独立的组件。在一些工作量下，您甚至可以轻易将它运作于 Windows NT。当然，我也喜欢在内核上工作，可是兼容性以及损坏问题可以是令人非常心痛不已，从而破坏了其乐趣的性质。
您所做的什么工作是当中最具有挑战性的？
很可能是工作牵涉到 FreeLDR 以及内核和其他镜像是如何的载入，和重写对象和进程管理器，因为它们是非常重的组件。但是我要说当中最具有挑战的是底层微内核的工作于 Ke，例如系统调用句柄，系统自陷，中断，异常以及线程调度 + 上下文、切换，还有在 HAL 处理 IRQ / 中断的工作。
如果您有一样东西希望 ReactOS 能够做到，那会是什么？还是那个已经完成了？
我真的非常希望我们有个新的资源管理器壳，好像 Windows，而非目前我们所有的壳，因为坦白地说多数人会觉得非常不具有吸引力以及非常破损。
您已经在 ReactOS 的内核付出许多。当中您真正喜欢哪个部分？
我喜欢的部分是进程和对象管理器，以及执行单位。因为它们是大但相对简单的组件，而且您将能够学到很多关于如何应对整个 NT面向对象的性质以及它是如何处理用户模式。
    会议
您已经给了许多关于 ReactOS 的会议及讲座，您觉得遇见其他开发者是否有用？
通常是的，因为深入到社区的其他成员时常将能够给您新的点子和见解，也同时给您一个公正的进展意见以及您在整体上您在这个行业里所做的改变。当然，有时会出现一些负面的观点，但是那些将会帮助您更好的准备如何去应对它们。


那么在您曾经到访过的地方中，哪一个是您最喜欢的地方？
我非常喜欢波士顿，但我常去那边，所以自从我到访过 GooglePlex 后 ReactOS 带我到最酷的地方应该是加利福尼亚州山景城。
    工作
您已经参与 ReactOS 的活动一段时间了，可是最近的日子里您变得非常活跃（而且很可能是以较轻微的说法）有没有一个特别的理由？
因为当您要达到终点时，您会感受到一种赶紧的压力。没错，我现在就能够看到隧道末端所散发的曙光。说真的，我们只剩下几样东西在内核和 HAL（硬件抽象层）需要完成，过后我就会称我们已经完成了 60-70%。或许再多八至十二个月的工作，而且那也包括像 kernel32, ntdll, csrss, smss 和其他底层组件能够与它沟通的东西。我认为一旦那些组件能够运作后，并且 Wine 的库也看似做得非常好，这是因为它们既然能够在 Linux 下运行许多应用程序，就只剩下 GUI （图形界面）子系统 (win32k.sys) 来支持用户模式的应用程序。在那个工作也完成之后，我很可能处理网络的用户模式以及内核模式，然后再看未来又拥有什么。很肯定不是对声音的支持，因为我个人不认为我本身对它有充分的准备。
在此活动之前，您对 ReactOS 最可观的贡献是什么？
我认为我所做的每个贡献都是一样可观；其实非常难说某些贡献会比其他贡献来得重要。我曾经几乎重写每个内核模块，也处理过看似“微不足道”的东西如 MSVC 的兼容性，可是我觉得两者都一样重要。
您有哪些 ReactOS 的地方是从来未涉足过？
许多。所有 Wine 的 DLL，所有应用程序，例如 PnP 管理器或者内核的保安子系统，等。
您对 ReactOS 所添加当中哪一个是最有趣的？
我认为是能够被 NTLDR 引导的功能（编按：NTLDR 是 Windows NT 及未来的引导程序），尽管它只是局部可用。在未来的日子里，我希望我能够在空余时间里继续在这一方面工作，并且增加我们的兼容性。
您现在是否正在处理任何重大的 ReactOS 工程？
是的，我正在尝试让硬件抽象层能够与 Windows 兼容。
除了一切，您也在 IRC 频道里非常活跃。这是否意味着耗费您许多的时间？
我通常会避开论坛因为 IRC 是我花最多时间的地方。我是频道主人，所以我必须时常在线以便回答问题，和与其他开发者联系。我能说 IRC 每天耗费六到八个小时，但在这期间我也做其他的东西。
您能否稍微解释进程管理器？
没问题。进程管理器 (Ps) 基本上是负责在 NT 系统里所有的进程，线程以及任务对象。因此每当您开始一个应用程序时，和其线程以及系统进程于内核所在的位置将被该组件所管理。
虽然这里牵涉到大量的用户模式，尤其是开始一个进程的时候，内核就是管理它与其他组件比如执行单位，内存管理器，保安子系统等的关系。
您使用什么开发环境？
我使用 Microsoft Visual Studio 2005 SP1 以及 WDK（Windows Driver Kit，Windows 驱动程序套件）。
所以除了 ReactOS 之外，您是否也参与其他的工程？
是的，我处理 TinyKRNL，基本上也是个重新实现 NT 内核和驱动，以及其子系统，但是是为了教育目的。我预计它将会与 ReactOS 共享许多内核和硬件抽象层的代码，而驱动的部分将从零做起，因为 ReactOS 还不支持这些功能。
您是如何去开发这些东西？
我阅读相关书面说明，使用符号，从文件的转储字符串，并使用我所编写的特殊程序以便在所给予的函数创建所有调用链和全局变量的访问。这样我就可以了解它想做什么。它也指出 ASSERT 和其他字串。
您已经提出一些术语对于一些人可能听的不太熟悉。能否解释其中的一些？
一个 ASSERT 是一个特殊检查，它代表当前在 Windows 组件里的调试库，也会显示一行实际的代码并确认一个变量的数值是否为结构的成员之一。它能够给我们一些关于代码正在做什么和什么结构，常量已被使用和其意思的见解。符号是微软发布里包含那些信息关于“内部 API”，“变量名称”以及“在所关联的可执行程序里所用的结构”的特殊文件。