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

Magnus Olsen，在 1976 年出生于 Skarholmen （位于斯德哥尔摩省的西南郊区），瑞典。自从 2002 年以来一直都在参与 ReactOS 的活动并且自从那时起已经在工程许多不同的部分给予贡献。
    开始
您是如何参与 ReactOS？
我在完成某个工程之后就寻找不同的开源工程并最终加入 ReactOS 工程为一名开发者。我已经知道 ReactOS 并且在 2002 年以来一直都在放眼关注本工程。我原先要开始一个操作系统能够与 Windows 兼容的个人工程。尽管，我明白在一个合理时间框架下一个人能够编出这样的操作系统是不可能的。因此我必须选择当中有几个有与 Windows 兼容为目标的工程。Wine, WineX, EOS, Moblius, ReactOS 以及其他更多的工程。相对于其他的工程，Wine 和 WineX 这两者有最高的 Windows 兼容性，可是我不喜欢这个概念在 Linux 里运行 Windows 应用程序。Unix （以及 Linux）并不适合一般使用者使用。那么我又看了 EOS，这个工程使用 Linux 内核以及 ReactOS, Wine 和其他工程的代码，虽然我也不喜欢该工程。因此我必须从这两个工程之中选择其一： Mobius 和 ReactOS。这两个工程都有同样的目标去完成一个兼容于 Windows 的操作系统（应用程序以及驱动程序）。我就比较它们的差别：什么内核设计，几位开发者，什么许可证，等。Moblius 工程只有两三位开发者，然而ReactOS 就有许多开发者。此外，Moblius 志在 Windows 9x 而 ReactOS 是 Windows NT。 那么选择就简单多了；我决定加入 ReactOS 工程并作为开始，我编写了一些组合代码，当时是 2003 年。此后由于我私人的原因就消失了超过一年。可是 Aleksey Bragin 最终能够说服我返回并且我也提交我完成许多的作品。这些都是关于 DirectX 标题以及其他东西。
所以在此前您一直都为 Windows 编程程序？
我一直以来都在编程于 Commadore 平台，Amiga，C64 和个人计算机。我从来就没有在当中这些平台里放弃编程。有时我也在其他平台来编写代码。
您是否有任何 Windows 的经验？或者您是在不得已的情况下才学的？
我对 Windows 相当丰富的经验但是我在开始编写代码之前也花了一些时间来学习一些此前对我而言是个新的范围或者寻求建议以及让代码随着时间的前进而改善。在 ReactOS 里工作是非常有趣的。

    与 ReactOS 所在的乐趣
您最喜欢处理ReactOS 的哪个部分？
DirectX，当我有时间。当到了 DirectX 的内核部分，却在编写实际用户模式的 DLL 文件时一点也不好玩。据我所知它是 DirectX 中最令人厌烦以及最复杂的部分。
您所做的什么工作是当中最具有挑战性的？
最具有挑战性？我不晓得，也许是 DirectX，它是我花最多时间的地方；或者是修正错误和新增的东西于 win32k。
如果您有一样东西希望 ReactOS 能够做到，那会是什么？还是那个已经完成了？
我要看到 Final Fantasy 7 和 Guild Wars 都能运作，那是我在空余时间里唯一玩的游戏。那也是我其中的一个原因，处理 DirectX。
您真的喜欢 ReactOS 的哪一个部分？
我喜欢 Win32k，它是非常的复杂并且在处理它是非常有趣，以及修正错误。
您已经参与 ReactOS 的活动一段时间了，可是最近的日子里您变得比较活跃。有没有一个特别的理由？
我在 ReactOS 里活跃的唯一原因是，我觉得这个工程很有趣，并且若不是有某人的支持下，我很可能在这个夏季就离开 ReactOS 并辞退开发者的一份子。今年初有很多弊端并且讨论最终以代码审查以及带来许多倒退现象为句号。可是与此同时，我认为我们也几乎成功的把所有 ReactOS 已知的倒退现象修正并且让它更加兼容于 Windows。

    工作
在此活动之前，您对 ReactOS 最可观的贡献是什么？
我不晓得。也许是修正错误以及实现 "strechblt"，并修正一些 DirectX 对 ReactOS 的支持。但像我之前所说的，我不晓得。
您有哪些 ReactOS 的地方是从来未涉足过？
很难说，我避开"ntoskrnl" [编按：ReactOS 的内核]，包括编写代码以及修正其错误是因为我不了解其内部关于它如何运作的细节。Ntoskrnl 是个非常复杂，跟 win32k 一样，虽然后者对我而言是相对比较容易让我修正错误以及实现一些的新的东西。
您对 ReactOS 所添加当中哪一个是最有趣的？
如何使用 DirectDraw 硬件抽象层的支持文档。如此一来，您就不必去阅读整个微软MSDN（微软软件开发者网络）以及微软DDK（设备驱动程序开发包）文档。况且有些 MSDN 的部分是错误的，比如您应该在某个结构下使用什么成员，或者是结构的错误版本。所以，您当然需要先在微软软件开发包和 DirectX 软件开发包的文档里阅读关于其结构的样貌是什么才能够写出一个代码。当然，请用点脑筋。
您现在是否正在处理任何重大的 ReactOS 工程？
请先阅读关于当前的 "ReactOS 状态报告"，为此我正在计划以及尝试集中精力继续跟随开发计划。尽管如此，我每次也做侧线项目以及不在计划所包括的工程。有时候，我会觉得这类工程不受时间框架所影响是挺有趣的，就如刚才所说过的，我喜欢享受编程的乐趣。
除了一切，您也在 ReactOS 邮件列表和 IRC 频道里相当活跃。这样会不会耗费您许多的时间？
是的，但是保持联系并且与用户和开发者聊起一些课题并从中享受其乐趣也一样重要。我花了许多空余时间到 ReactOS 的开发。
您是否曾经工作于 ReactOS 的任何其他部分？
我正在工作于ReactOS 的许多部分，因此对我而言难以说明哪一个部分我不曾看过或编写其代码。您需要在 ReactOS SVN 里检查更改日志。
您使用什么开发环境？
我正在使用Windows 2000/XP 来构建 ReactOS，这是个人们询问 ReactOS 时非常明显的问题。

    未来
为什么有人要运行一个 Windows 的克隆？为何不要直接运行真的东西？
ReactOS 是个免费又开源的软件。所以您可以回到代码里修正问题并发送补丁给 ReactOS。您也可以在 ReactOS 里报告错误并且它们将会被修正，虽然有些问题所需的修正时间会比其他较长。然而如果您向微软报告一个错误，他们很可能需要很长的时间才会修正该问题或者完全不给予理会。这里就是不同的地方。在 ReactOS 里，我们关注错误的问题并且我们希望修正所有错误的问题。有时是某个实现的缺失并且如果某个东西是在缺失实现一个 API 或者堆栈如 USB 或者网络的情况下就需要一段时间才能将它准备就绪，以便实现API 某某。目前在0.3.0 发布里，ReactOS 有了稳定的网络支持。当然还有 USB 堆栈， 但是现在 USB 堆栈还未准备就绪，并且只适用在 USB 的鼠标及键盘。在 ReactOS 0.3.1 里， USB 堆栈将会改善并且有更强大的功能，如USB 磁盘存储器。ReactOS 里有许多有点和它的原因。与此同时，您也可以反问我为什么有人会要一个 Unix 的克隆？（编按：这里指的是 Linux）
所以为什么要完成的列表是当前的模样呢？
我们正在工作于我们喜欢的部分并且毫无疑问的有些部分要处理它确实不是那么有趣的。我们尝试同意在每一个发布里有个共同的路线规划图。开发者“甲”要修正 “乙”问题，然而开发者“丙”却要实现某个新的 API 等等。我们将不会限制每位开发者应该专注于什么地方，每个人都应该做那些对他（她）而言是有趣好玩的部分。
您现在是否计划处理任何重大 ReactOS 的任务？
我已经有了一个重大的任务并不打算再接收这类重型任务。但我应该会接收较小的任务。
如果您能够增加'一个'功能到 ReactOS，那会是什么？
目前我本人在内心中有个点子，但仍然未被确定下来。
您有没有希望 ReactOS 能够做到，但现在不能？
许多东西，比如我要 USB记忆棒开始运作。Aleksey 已经在这个方面努力中并且我们可能在 ReactOS 0.3.1 里看到 USB 磁盘存储器 :-)
您是否曾经希望那里有更多的开发者？
是的，多一些开发人员应该不伤大雅。我们真的需要更多开发者以便加快开发的进程。如果您是一名开发者并且想为 ReactOS 工程出一份力，请参加 #reactos IRC 频道和、或ReactOS 的邮件列表。请参阅 reactos.org 以获取更多信息。
您认为ReactOS 是否有其他的东西必须给予专注？
我们必须专注于每样东西。但是每位开发者能够只专注他（她）喜欢做的事。

    兼容性
您认为 .Net 会不会给予 ReactOS 过时？
不会，我完全不认为。ReactOS 将会使用 Mono 或者 dotGNU 为 dotNet 的框架并且这样就能够使我们与微软 Windows 处在同一个联赛。我们将在未来近期的日子里决定哪一个工程最适合 ReactOS 的需要。
您认为 .Net 会不会给予 WinAPI 过时？
不会，我不认为。这是因为微软的dotNet 框架使用原生 Windows 的 API，就如现有的API 多加一层。
您现在认为哪一个部分是最需要开发的？
我们必须集中于让更多的网络应用程序能够运作并且去除一些图形错误于Win32k 以便让更多应用程序正确的运作以及让图形朝向正确的方向前进。可是我与其他人所谈起这个课题的答复却是他们要看到 USB 并在 ReactOS 里使用 USB 记忆棒并且 ReactOS 就应该能够从 USB 磁盘存储设备里启动。当我与公司谈起这个课题时，他们时常回复说他们要在 ReactOS 里看到Samba 网络的支持。ReactOS 0.3.1 有可能有 USB 磁盘存储设备和 Samba-tng 的支持。
微软将在近期内发布 DirectX 10，那里是否有显著的增加？
是的，现在 DirectX 的驱动程序将在不同的kmode ["内核模式"] 里工作，但这会移动某些API 到用户模式以及添加新 Directdraw/d3d 如何从 Win32k枚举的方法。我不晓得微软是否会为 Windows XP 更改它吗，我没有时间研究它。
    恭喜您目前所有的成就并且感谢您接受本采访。

ReactOS团队成员访谈录-"Magnus Olsen"
原文地址：http://www.reactos.org/zh/interview_3.html
by Klemens Friedl on 2006-11-28
Magnus Olsen
由 Klemens Friedl 与 Magnus Olsen 进行的采访
这是第三个与 ReactOS 开发者进行采访的采访系列。这几个星期里，我们将会有个好的收集关于展示 ReactOS 背后的人才。
Magnus Olsen，在 1976 年出生于 Skarholmen （位于斯德哥尔摩省的西南郊区），瑞典。自从 2002 年以来一直都在参与 ReactOS 的活动并且自从那时起已经在工程许多不同的部分给予贡献。
    开始
您是如何参与 ReactOS？
我在完成某个工程之后就寻找不同的开源工程并最终加入 ReactOS 工程为一名开发者。我已经知道 ReactOS 并且在 2002 年以来一直都在放眼关注本工程。我原先要开始一个操作系统能够与 Windows 兼容的个人工程。尽管，我明白在一个合理时间框架下一个人能够编出这样的操作系统是不可能的。因此我必须选择当中有几个有与 Windows 兼容为目标的工程。Wine, WineX, EOS, Moblius, ReactOS 以及其他更多的工程。相对于其他的工程，Wine 和 WineX 这两者有最高的 Windows 兼容性，可是我不喜欢这个概念在 Linux 里运行 Windows 应用程序。Unix （以及 Linux）并不适合一般使用者使用。那么我又看了 EOS，这个工程使用 Linux 内核以及 ReactOS, Wine 和其他工程的代码，虽然我也不喜欢该工程。因此我必须从这两个工程之中选择其一： Mobius 和 ReactOS。这两个工程都有同样的目标去完成一个兼容于 Windows 的操作系统（应用程序以及驱动程序）。我就比较它们的差别：什么内核设计，几位开发者，什么许可证，等。Moblius 工程只有两三位开发者，然而ReactOS 就有许多开发者。此外，Moblius 志在 Windows 9x 而 ReactOS 是 Windows NT。 那么选择就简单多了；我决定加入 ReactOS 工程并作为开始，我编写了一些组合代码，当时是 2003 年。此后由于我私人的原因就消失了超过一年。可是 Aleksey Bragin 最终能够说服我返回并且我也提交我完成许多的作品。这些都是关于 DirectX 标题以及其他东西。
所以在此前您一直都为 Windows 编程程序？
我一直以来都在编程于 Commadore 平台，Amiga，C64 和个人计算机。我从来就没有在当中这些平台里放弃编程。有时我也在其他平台来编写代码。
您是否有任何 Windows 的经验？或者您是在不得已的情况下才学的？
我对 Windows 相当丰富的经验但是我在开始编写代码之前也花了一些时间来学习一些此前对我而言是个新的范围或者寻求建议以及让代码随着时间的前进而改善。在 ReactOS 里工作是非常有趣的。
    与 ReactOS 所在的乐趣
您最喜欢处理ReactOS 的哪个部分？
DirectX，当我有时间。当到了 DirectX 的内核部分，却在编写实际用户模式的 DLL 文件时一点也不好玩。据我所知它是 DirectX 中最令人厌烦以及最复杂的部分。
您所做的什么工作是当中最具有挑战性的？
最具有挑战性？我不晓得，也许是 DirectX，它是我花最多时间的地方；或者是修正错误和新增的东西于 win32k。
如果您有一样东西希望 ReactOS 能够做到，那会是什么？还是那个已经完成了？
我要看到 Final Fantasy 7 和 Guild Wars 都能运作，那是我在空余时间里唯一玩的游戏。那也是我其中的一个原因，处理 DirectX。
您真的喜欢 ReactOS 的哪一个部分？
我喜欢 Win32k，它是非常的复杂并且在处理它是非常有趣，以及修正错误。
您已经参与 ReactOS 的活动一段时间了，可是最近的日子里您变得比较活跃。有没有一个特别的理由？
我在 ReactOS 里活跃的唯一原因是，我觉得这个工程很有趣，并且若不是有某人的支持下，我很可能在这个夏季就离开 ReactOS 并辞退开发者的一份子。今年初有很多弊端并且讨论最终以代码审查以及带来许多倒退现象为句号。可是与此同时，我认为我们也几乎成功的把所有 ReactOS 已知的倒退现象修正并且让它更加兼容于 Windows。


    工作
在此活动之前，您对 ReactOS 最可观的贡献是什么？
我不晓得。也许是修正错误以及实现 "strechblt"，并修正一些 DirectX 对 ReactOS 的支持。但像我之前所说的，我不晓得。
您有哪些 ReactOS 的地方是从来未涉足过？
很难说，我避开"ntoskrnl" [编按：ReactOS 的内核]，包括编写代码以及修正其错误是因为我不了解其内部关于它如何运作的细节。Ntoskrnl 是个非常复杂，跟 win32k 一样，虽然后者对我而言是相对比较容易让我修正错误以及实现一些的新的东西。
您对 ReactOS 所添加当中哪一个是最有趣的？
如何使用 DirectDraw 硬件抽象层的支持文档。如此一来，您就不必去阅读整个微软MSDN（微软软件开发者网络）以及微软DDK（设备驱动程序开发包）文档。况且有些 MSDN 的部分是错误的，比如您应该在某个结构下使用什么成员，或者是结构的错误版本。所以，您当然需要先在微软软件开发包和 DirectX 软件开发包的文档里阅读关于其结构的样貌是什么才能够写出一个代码。当然，请用点脑筋。
您现在是否正在处理任何重大的 ReactOS 工程？
请先阅读关于当前的 "ReactOS 状态报告"，为此我正在计划以及尝试集中精力继续跟随开发计划。尽管如此，我每次也做侧线项目以及不在计划所包括的工程。有时候，我会觉得这类工程不受时间框架所影响是挺有趣的，就如刚才所说过的，我喜欢享受编程的乐趣。
除了一切，您也在 ReactOS 邮件列表和 IRC 频道里相当活跃。这样会不会耗费您许多的时间？
是的，但是保持联系并且与用户和开发者聊起一些课题并从中享受其乐趣也一样重要。我花了许多空余时间到 ReactOS 的开发。
您是否曾经工作于 ReactOS 的任何其他部分？
我正在工作于ReactOS 的许多部分，因此对我而言难以说明哪一个部分我不曾看过或编写其代码。您需要在 ReactOS SVN 里检查更改日志。
您使用什么开发环境？
我正在使用Windows 2000/XP 来构建 ReactOS，这是个人们询问 ReactOS 时非常明显的问题。
    未来
为什么有人要运行一个 Windows 的克隆？为何不要直接运行真的东西？
ReactOS 是个免费又开源的软件。所以您可以回到代码里修正问题并发送补丁给 ReactOS。您也可以在 ReactOS 里报告错误并且它们将会被修正，虽然有些问题所需的修正时间会比其他较长。然而如果您向微软报告一个错误，他们很可能需要很长的时间才会修正该问题或者完全不给予理会。这里就是不同的地方。在 ReactOS 里，我们关注错误的问题并且我们希望修正所有错误的问题。有时是某个实现的缺失并且如果某个东西是在缺失实现一个 API 或者堆栈如 USB 或者网络的情况下就需要一段时间才能将它准备就绪，以便实现API 某某。目前在0.3.0 发布里，ReactOS 有了稳定的网络支持。当然还有 USB 堆栈， 但是现在 USB 堆栈还未准备就绪，并且只适用在 USB 的鼠标及键盘。在 ReactOS 0.3.1 里， USB 堆栈将会改善并且有更强大的功能，如USB 磁盘存储器。ReactOS 里有许多有点和它的原因。与此同时，您也可以反问我为什么有人会要一个 Unix 的克隆？（编按：这里指的是 Linux）
所以为什么要完成的列表是当前的模样呢？
我们正在工作于我们喜欢的部分并且毫无疑问的有些部分要处理它确实不是那么有趣的。我们尝试同意在每一个发布里有个共同的路线规划图。开发者“甲”要修正 “乙”问题，然而开发者“丙”却要实现某个新的 API 等等。我们将不会限制每位开发者应该专注于什么地方，每个人都应该做那些对他（她）而言是有趣好玩的部分。
您现在是否计划处理任何重大 ReactOS 的任务？
我已经有了一个重大的任务并不打算再接收这类重型任务。但我应该会接收较小的任务。
如果您能够增加'一个'功能到 ReactOS，那会是什么？
目前我本人在内心中有个点子，但仍然未被确定下来。
您有没有希望 ReactOS 能够做到，但现在不能？
许多东西，比如我要 USB记忆棒开始运作。Aleksey 已经在这个方面努力中并且我们可能在 ReactOS 0.3.1 里看到 USB 磁盘存储器 :-)
您是否曾经希望那里有更多的开发者？
是的，多一些开发人员应该不伤大雅。我们真的需要更多开发者以便加快开发的进程。如果您是一名开发者并且想为 ReactOS 工程出一份力，请参加 #reactos IRC 频道和、或ReactOS 的邮件列表。请参阅 reactos.org 以获取更多信息。
您认为ReactOS 是否有其他的东西必须给予专注？
我们必须专注于每样东西。但是每位开发者能够只专注他（她）喜欢做的事。
    兼容性
您认为 .Net 会不会给予 ReactOS 过时？
不会，我完全不认为。ReactOS 将会使用 Mono 或者 dotGNU 为 dotNet 的框架并且这样就能够使我们与微软 Windows 处在同一个联赛。我们将在未来近期的日子里决定哪一个工程最适合 ReactOS 的需要。
您认为 .Net 会不会给予 WinAPI 过时？
不会，我不认为。这是因为微软的dotNet 框架使用原生 Windows 的 API，就如现有的API 多加一层。
您现在认为哪一个部分是最需要开发的？
我们必须集中于让更多的网络应用程序能够运作并且去除一些图形错误于Win32k 以便让更多应用程序正确的运作以及让图形朝向正确的方向前进。可是我与其他人所谈起这个课题的答复却是他们要看到 USB 并在 ReactOS 里使用 USB 记忆棒并且 ReactOS 就应该能够从 USB 磁盘存储设备里启动。当我与公司谈起这个课题时，他们时常回复说他们要在 ReactOS 里看到Samba 网络的支持。ReactOS 0.3.1 有可能有 USB 磁盘存储设备和 Samba-tng 的支持。
微软将在近期内发布 DirectX 10，那里是否有显著的增加？
是的，现在 DirectX 的驱动程序将在不同的kmode ["内核模式"] 里工作，但这会移动某些API 到用户模式以及添加新 Directdraw/d3d 如何从 Win32k枚举的方法。我不晓得微软是否会为 Windows XP 更改它吗，我没有时间研究它。
    恭喜您目前所有的成就并且感谢您接受本采访。