采访 Matt Pietrek

我们曾听取 Wintellect 的 Jeff Prosise 和 Microsoft 的 Lon Fisher 的解释，了解 .NET 对我们意味着什么。现在，Win32 领域的专家 Matt Pietrek 将分享他对 .NET、在 NuMega 的工作以及软件开发未来的看法。Matt 多年来一直撰写 MSJ 和 MSDN 的“幕后花絮”专栏。他是许多优秀编程书籍的作者，目前在 Compuware Corp. 的 NuMega Lab 从事高级研究。请访问他的主页了解关于 Matt 的一切。

稍后将留出时间让 Matt 回答更多问题。Matt 的回答很可能会引发更多问题，请尽早提出，他将在时间允许的情况下尽力回答。

 

您如何看待将 .NET Framework 移植到非 Windows 平台的可能性？目前技术上可行吗？还是存在必须解决的问题？您认为我们是否会在 Linux 上看到此类移植？您对此有何预测？

我认为现在 .NET 可以移植到其他平台，如果有人愿意这样做的话。毕竟，微软表示他们正在考虑将部分或全部内容（我记不清具体细节了）提交给某个标准化机构。

如果你从 .NET 的运行时类、执行引擎等方面来看，你会发现有大量的代码与特定的 CPU 和/或操作系统无关。字符串类就是字符串类（希望如此！）

当然，.NET 中存在一些可能无法移植的功能，例如经典的 COM 互操作。如果有人（非微软）提供 .NET 实现，这些功能可能不会被移植。这就是生活。如果您担心编写的 .NET 代码未来可能在某个非微软的实现上运行，那么就不要使用这些功能。老实说，Java 和 Unix 今天也存在同样的问题。如果您开始使用某些特定于某个实现的炫酷功能，移植性可能会成为问题。

我们会在 Linux 上看到 .NET 吗？说实话，我不知道。但是，基于 WINE 等项目，如果有人真的愿意投入精力让 .NET 实现运行在 Linux 上，那我也不会感到惊讶。如果是这样，那就祝他们好运。

考虑到 .NET，我想知道您对 Windows CE 的未来走向有何看法。我注意到 Compuware/Numega 的工具似乎并没有特别支持 Windows CE。有些产品如果无法收回投资，就没什么意义了，我认为 CE 市场一直很小，但我想知道您认为 CE 作为目标平台的未来会怎样？它是否只是未来推出的“精简版”CLR 的宿主？

嗯……好问题。以微软的风格，他们可能会推出（或帮助硬件供应商）从头开始打造 100% .NET 设备。同时，他们可能还会继续推广 CE 至少一段时间。可以看作是在赛道上有两匹马。如果 CE 最终成为重要平台，那么他们不会放弃它。我也看到了未来版本的 CE 可能会托管一个精简版 CLR 实现的可能。谁知道呢？

至于 Compuware/NuMega 对 CE 的支持，我知道 BoundsChecker 中有/曾有过对 CE 的支持。诚然，这可能不是 CE 专家们所期望的全部功能，但至少做了一些努力。我敢肯定，Compuware/NuMega 这样的公司将资源投入在哪里是由市场需求和市场份额决定的，这并不奇怪。

我听说 .NET 支持 COM 和 Windows API。而且，正如我阅读文档（.NET 开发环境）时对 C# 和 CLR 的理解，它也可以支持平台独立性。平台独立性是一个非常重要的问题，C# 的目标就是实现它。而 .NET 中的其他东西（XML、SOAP 等）也似乎旨在实现平台独立性。

那么，您如何解释 .NET Framework 的这两个相互矛盾的特性呢？平台独立性 vs COM、Windows API 支持？

我并不认为存在多少矛盾。C# 是一种语言。您可以用一种语言编写可移植的代码，也可以用同一种语言编写特定于平台的代码。这在 C 语言方面已经有 30 年的历史了。在我看到的 C# 语言定义中，没有任何东西将它与 Windows 绑定。但是，您可以选择使用和/或编写依赖于 Windows 功能或底层硬件平台的 C# 类。

CLR 的情况也基本相同。我绝对可以看到有一天它可以在 Windows 之外运行。然而，它有“逃生舱口”，可以让你使用 Windows、COM 以及任何你需要的其他东西。微软非常聪明地加入了这些功能，否则他们将需要付出巨大的努力才能让人们放弃他们现有的代码。说到底，微软自己也有这个问题。您能想象在未来一年内，所有 Office 产品和所有 Back Office 产品完全托管在 .NET 上吗？而不使用 PInvoke 和 COM 互操作之类的东西？

简短的回答是：如果您想要可移植性，您必须明智地选择您使用的功能。这个概念在 .NET 中当然不是新的。

我非常想听听 NuMega 早期作为一个小公司，您和团队是如何努力发布下一个版本的。我知道这也不是真正的问题，但我一直在使用 BoundsChecker，我很想听您讲述一些关于一切如何开始的有趣故事。您是什么时候加入 NuMega 的？您是创始人之一吗？您的角色是如何随着时间变化的？我有一种印象，您一开始是编写所有代码，然后不知不觉中转向了更纯粹的研究角色。

啊…… excelente 的问题！我将按稍微混乱的顺序回答它们。

我在 1993 年加入了 NuMega，当时被 Borland 解雇了。我绝对不是创始人之一，但属于最初的 10 人以内。

我加入时，有两个创始人、两名程序员（其中一名不在办公室）、一名办公室经理和一名销售/营销人员。在我之后不久，又有几位很棒的人加入，但在最初的两年里，公司规模仍然很小。

两位创始人 Jim 和 Frank 是很棒的人。我仍然会定期见到他们，并且住在他们所在的小镇。我甚至没有经过正式面试。我只在两次不同的场合和他们通过电话交谈，大部分谈话内容是如何改进 SoftIce。当我接到工作邀请电话时，我简直不敢相信，我觉得自己资历不够。

NuMega 早期的很棒之处在于它是一家非常注重家庭的公司。似乎所有的家庭成员都相互认识，我们总是聚在一起做些什么。我们也没有像现在大多数初创公司那样工作到很晚。我们都很擅长自己的工作，并且工作时间也很正常（比如说，上午 9 点到下午 5 点）。如果你有好的产品，并且存在很高的进入壁垒，你就不需要承受现在似乎每个人都承受的压力。据我回忆，我们甚至没有费心去追踪假期。每个人都凭直觉知道，只要工作完成了，过多的正式程序只会碍事。

我加入时，主要产品是 SoftIce for DOS 和 Windows，以及 BoundsChecker for DOS。我直接投入了 BoundsChecker for Windows 的首次发布（您必须记住，在 1993 年，这将是针对 16 位 Windows 3.1 版本）。我的第一个大任务是编写参数验证系统。团队基本上是 Frank，也就是 SoftIce for Windows 的专家，还有我。您绝对想不到有多少代码是从 DOS 产品中复制过来的。

BoundsChecker 1.0 发布后，我接管了，并成为了 BoundsChecker 2.0 的“负责人”。说“负责人”有点夸张，因为基本上就我和那位不在办公室的程序员。SoftIce/W 的人回到了他原来的岗位。

有一个有点幽默的故事是关于技术支持的。当时，如果有人打电话咨询 DOS 产品的支持，他们会和创始人之一通话。如果有人打电话咨询 Windows 产品的支持，他们会和 SoftIce for Windows 的专家或者我通话。后来我们有了专门的支持人员，但能够直接从客户那里获得关于我们做得对不对的反馈，这真是太棒了。

到了开始开发 Win32 版本的时候，我做了所有最初的核心工作，后来才让 Frank 加入帮助他进行符号表代码。在 UI 方面，那位不在办公室的程序员做了大量工作，将 16 位 UI 代码转换为 32 位。随着时间的推移，许多更棒的人（包括 John Robbins）被聘用，他们不幸地使用了我的代码 J

在我 NuMega 的职业生涯中，我几乎一直专注于 BoundsChecker。从 16 位代码开始，到 32 位代码，再到最近的 64 位工作。幸运的是，我有 5 年的时间从过去的错误中吸取教训，所以我最近的大部分工作都是在一个经过改造的 BoundsChecker“引擎”上进行的。这个引擎将在未来 32 位和 64 位版本的 BoundsChecker 中使用。这个引擎还包括 .NET 支持。能够从零开始，真是太好了！

除了 BoundsChecker 相关的工作，我还涉足了其他领域，包括研究。我刚才提到的引擎最初是一个研究项目。其他研究领域可能包括技术评估、竞争对手分析，以及任何我能为公司提供合理价值的领域。尽管如此，我仍然认为自己内心是一个程序员。

您如何做到始终走在时代前沿？

像我这样的大多数时间都在工作、拥有完整的家庭生活、有妻子、需要通勤、还要修剪草坪的普通程序员，能否像您一样始终走在时代前沿？

很有趣你会认为我走在时代前沿，因为我总是感觉自己落后于时代。我努力和我的妻子、两岁的孩子以及房子过着“正常”的家庭生活。为了平衡我的生活，我不在工作时加班 14 个小时，并且在家时尽量不碰电脑。当然，有时我需要在家里高度专注（比如写专栏的时候），但我肯定不像以前那样整天泡在电脑前。

所以……我必须慎重选择我投入的精力。我意识到有些领域我没有时间去学习。我了解自己的优势，并努力至少在这些领域保持自己的水平。我还有 NuMega “架构师”的优势。因为我需要跟进未来的发展趋势，所以我通常可以利用这些知识来指导我从事一些外部活动，比如我的专栏。

您认为如果 .NET 成功，您未来会涵盖哪些主题？您会（不）涵盖 IL 和 JIT 吗？您认为 Win32 的未来有多重要？那些精通 Win32 API 的人是否总会有一席之地？

好问题！我对 .NET 的底层原理已经基本了解，但仍有很多需要学习的地方。很多很棒的信息（例如 IL）已经文档化了。你只需要稍微挖掘一下就能找到你想要的。一次要理解的东西太多了！

我做的很多事情都是基于现有的文档，然后加入我自己的理解。不像那些试图为整个 API 编写文档的人，我拥有选择一个领域进行深入研究的便利。我可以选择我认为重要的点，并专注于让这些点尽可能清晰。所以，是的，我认为我也会涵盖 JIT 编译和 IL，但直到我对它们有足够的了解并能有条理地谈论它们为止。我也不想操之过急，写一些处于变动中的、很多人可能还没有准备好的东西。

至于 Win32 API，我认为它将继续很重要。重点不在于 API 本身，而在于对系统中所有层及其如何集成知识的理解。我说过很多次了，但值得再次强调：软件是分层编写的。你对这些层理解得越多，你就会越有价值，无论是在作为程序员，还是在调试时。我不认为自己是一个特别出色的程序员。我所知道的是系统的大部分是如何组合在一起的。