再次 Redmond - 第 3 部分

更多技术内容，以及您的 .NET 问题解答

.NET 是一件大事。一件非常非常大的事。您听过炒作，读过评论、白皮书和文章，但直到您坐下来整理周围的碎片时，才会意识到它不仅仅是一种新语言和更新的用户界面。一切都改变了——然而，您以前做的一切都将“照常运行”^{TM (1)}。嗯，几乎所有事情。

微软早餐

现在您可能已经听过这些一百万遍了，但如果您像我一样，那么听得越多，理解就越多。如果您觉得已经听过太多这些内容，那么您可以跳到我抱怨橙色奶酪的部分。

对于 Windows 程序员来说，底层的 Win32 框架仍然存在，但您与它交互的方式是全新的。公共语言运行时使您能够更快、更容易地编写代码，减少错误，并且更加安全。请记住——您不必以 .NET 为目标——您可以继续编写您的 C++ 非托管 COM 类并处理您自己的线程和封送问题，您还可以继续使用 ASM 和 C 编写高性能设备驱动程序——但对于我们这些喜欢周末的人来说，将会有带托管扩展的 C++、C# 和 VB（或 FORTRAN、或 COBOL、或 Objective Pascal，或...）。

然而我仍然觉得，人们对于采用 C# 这样的新语言，或者在 C++ 中使用托管扩展，或者信任垃圾回收不会罢工，都存在一些抵触。是不是因为开发者花费了太多时间，经历了太多痛苦才理解 COM、线程模型和深奥的 VB 技巧，以至于他们觉得随着新一代工具的出现，这些来之不易且宝贵的知识会重置他们的地位，使他们不再是昔日的专家？是不是担心他们所有的遗留代码将不再工作？或者是否有更基本的原因（C# 与 Java 之争？感知到的成本？“但 VC6 仍然有 bug！”这种还没学会走就想跑的论点？）？我希望听到你们的看法。

微软茶歇。

在基本的“给我看一个应用程序”层面，WinForms 取代了您习惯的通用控件。它们的工作方式大致相同，但气味略有不同，并有一个新的浅米色外壳。设计您的 GUI 变得容易得多。在设计器中向表单添加控件是直观的，控件在设计器中是活动的（例如，添加一个时钟面控件，您会在设计器中看到它在走动）。控件的属性页非常像 VB 风格，但更好用。那些玩过 Delphi 的人会在开始设计表单时产生一些回忆（考虑到是谁在做这个，这并不奇怪）。现在有“面板”可以容纳一组控件（类似于分组框），控件可以停靠在侧面，这意味着所有的调整大小和重新定位逻辑都由框架处理。

屏幕上的绘图也发生了变化。GDI+ 添加了大量功能，例如 JPEG/GIF/PNG 等支持、抗锯齿、Alpha 混合、渐变画笔等。ClearType 文本输出（使文本看起来很棒，尤其是在 LCD 屏幕上）已显著加速。GDI+ 严格只支持 2D，不使用硬件加速。微软将与硬件制造商合作，并期望在 2 年内实现硬件加速。3D 支持有点模糊，但如果它不包含在下一个版本中，我将感到非常惊讶。

编写代码可能是一种全新的体验。公共语言规范规定了跨语言使用的通用数据类型。显然有新语言——C# 是最引人注目的，但 C++ 有托管扩展，VB7 得到了很大改进，并且其他支持 .NET 的语言不断涌现。本质上，您现在可以选择最熟悉的语言并愉快地编写代码，知道其他人可以通过在他们希望的任何语言中从您的类派生新类来扩展您的逻辑，或者可以从任何语言/环境中使用您的组件，同样轻松自如。

Web 应用程序也大相径庭。Web Forms 取代了服务器端控件，消除了添加逻辑来维护状态（例如列表框中当前选定的项目）的需要，此外它们还负责根据客户端的功能或特殊性向客户端提供控件的表示。ASP.NET 取代了 ASP，将意大利面条式代码模型转变为逻辑/显示/事件处理程序模型。所有内容都经过预编译，您可以使用任何您想用的语言来编写网页。IIS 在性能、可伸缩性、资源管理和安全性方面得到了改进。想要更快的页面？尝试使用 ATL Server 来看看能否挤出更多性能。想继续使用旧的 ASP 页面和 COM 组件？没问题。它会工作的。

ADO.NET 取代了 ADO 的行集观念，并以 DataSets 的形式提供了替代方案。现在以类型安全的面向对象方式访问数据库信息。它更高效、更快、更不容易出错，您的代码也更具可读性。同样，所有内容都建立在现有 ODBC 数据提供程序之上，以确保一切都向后兼容。

PIII Xeons。我想这些是促销赠品什么的……

COM 在 .NET 中通过 COM 可调用包装器工作。您的 COM 客户端甚至不知道它们正在使用 COM 控件，因为它看起来像一个托管包装器。所有 COM 类型都映射到本机 .NET 类型。您也可以在非托管代码中使用托管组件。所有内容都通过 COM 互操作进行包装、打包和调用。

请记住，所有内容都构建在标准 Win32 之上。大多数功能都有托管包装器，并且大多数功能都已公开——但万一您遇到需要特定 Win32 部分的情况，P/Invoke 允许您从操作系统访问任何 Win32 API。我们还获得了源代码，而且很多。也许不是全部，但致力于这些工作的人正在努力将尽可能多的基类的源代码提供给我们。对我来说，这是一件好事。

旧的糟糕的打印 API 已被封装，使其更易于使用，并且随着新法律要求应用程序支持辅助功能，辅助功能 API 的封装将是一个天赐之物。

一个非常奇怪的地方。

编码约定也发生了变化。VB 程序员不会发现有什么不同，但 C++ 开发者可能会对缺少匈牙利命名法感到惋惜（或者庆幸——您说了算），而且不再有全大写的 #define 和常量名称，旧的 C 风格 variable_name_with_underscores 也肯定过时了。取而代之的是 camelCase 和 PascalCase 风格的变量名。变量前面没有 m_ 或 lptstr 意味着您的属性名称会整洁很多，但我在内部总是喜欢能够快速浏览代码，并根据变量的前缀推断出近似的变量类型。您可以叫我老派。

Beta 1 的用户界面，嗯，很有趣。如果您从未使用过 X-Windows，那么您可能会感到惊喜。否则，平坦的框突出显示菜单和控件可能看起来有点过时。

所有这些都适用于所有平台——从 Windows 95 到 Whistler（什么？没有 Windows 3.1？）。如果底层操作系统不支持某些功能（例如 GDI+ 功能或 Unicode），这些功能将由 .NET 在内部实现。.NET compact 肯定正在开发中，并将应用于 PDA、手机和游戏机等设备。

给 VB 程序员的一个有趣注意事项：Visual Studio.NET 包含迁移工具，允许您将 VB6 项目移植到 VB7。它们使用 AI 引擎智能地移植代码，任何模糊或有问题的区域都会被标记并显示相应的消息。

⁽¹⁾我不确定这是否已注册商标，但根据我看到它使用的次数，这只是时间问题。

您的 .NET 问题

Chris Anderson 已经善意地回复了您提出的 .NET 问题。

Stephen Kellett：.net 是否会有一个与 Java 虚拟机分析器接口 (JVMPI) 功能相似（希望不是实现方式）的 Instrumentation API？

Chris Anderson：CLR 有一套完整的 Instrumentation API 供分析器使用。我无法评论合作伙伴计划，但我们内部有一个分析器和两个调试器实现，它们都使用 Instrumentation 和调试 API。

Paul Wolfensberger：使用 ADO 时，通常有一组标志必须进行 OR 运算才能传递给变量……遗憾的是，如果变量是 DWORD 这样的类型，则这不是类型安全的……我希望看到一些允许开发人员指定类似“使用这些值来创建联合位标志值”的功能。

Chris Anderson：C# 完全支持枚举。此外，还有一个“Flags”元数据属性，向用户暗示这些值应该进行或运算。由于枚举是强类型的，我认为这解决了您的问题……

[Flags]
public enum MyEnum { Value1 = 1, Value2 = 2, Value3 = 4 }
string s = Enum.Format(typeof(MyEnum), MyEnum.Value1 | MyEnum.Value3, "G");

Jeremiah S. Talkar：.Net 平台是否会支持以下功能：

克里斯·安德森:

1. 我们在运行时拥有一个完整的代码访问安全系统。它基于一个基于证据的系统。我们允许对代码授予的权限进行细粒度控制，并且代码宿主（Internet Explorer、ASP.NET 等）可以为加载的代码提供策略或证据。
2. 我们与 Windows 2000 的 NLS 团队紧密合作，为 .NET 提供了功能完善的 I18N 和 L10N 系统。我们完全支持 Unicode，并拥有一个基于二进制和 XML 的资源系统。我们所有的控件都将本地化为（我相信是）8 种语言，并完全支持 Windows 2000 支持的所有语言。我们的 Visual Studio.NET 可视化表单设计器支持 Windows Forms 应用程序的可视化本地化。

Jeremiah S. Talkar：在观看了 MSDN 节目的第 5 集，其中包含一些关于 Intel Itanium 处理器 WIN64 发布版的一些细节后，我非常好奇 .Net 中像 C/C++ 这样公开指针的语言的指针大小（以及因此可用的地址空间）？

为了确保 .Net 特定的代码在未来的操作系统版本（如 WIN128、WIN256 等）上运行时（大部分未修改地）最佳运行，正在采取哪些设计考虑？或者在 .Net 下运行时，底层操作系统是否无关紧要？

Chris Anderson：我们将有一个“System.IntPtr”数据类型，它是一种“指针大小的整型”类型。在 Win32 上是 32 位，在 Win64 上是 64 位。这类似于为 Win64 C/C++ 库定义的 DWORDPTR。

Jeremiah S. Talkar：www.javasoft.com 网站上最近发表的一篇文章（对 .Net 的分析）提到了这样一个事实：除非 CLR 本身被标准化，否则 ECMA 标准 C# 的用处不大。

再多想一点，我倾向于同意这个结论。所以我想知道的是，.Net 团队是否同意这一点？如果答案是“否”，如果他们能提供理由，那就太好了。如果答案是“是”，那么了解正在采取哪些步骤来解决这个问题也很好。

Chris Anderson：CLI (Common Language Infrastructure) 是 C# ECMA 提交的一部分。CLI 定义了 C# 语言的最小“标准”运行时。我不是参与 ECMA 提交的团队成员，所以我无法具体评论哪些是提交的一部分，哪些不是。

Sandu Turcan：请问，他们是否考虑过在 .NET 中添加类似 expando 的功能？您不觉得能够将自己的数据与别人编写的类的实例关联起来会使生活更容易吗？这似乎实现起来很简单——在“object”中隐藏一个哈希表，问题在于您将数据映射到什么？是字符串吗？如果是，那么您如何确保没有人覆盖您的数据？

Chris Anderson：这会带来一些相当严重的性能影响。具体来说，系统中每个对象都会额外增加 4 字节用于 Hashtable 指针。此外，您现在会有两种类型的属性……expando 和实际属性……

SomeObject o = new SomeObject();
o.MyRealProperty = value;
o["expando"] = value;

这些扩展属性不会是强类型的，并且任何结构（值类型）都将被装箱以放入属性包中。

然而，我们完全理解语言会希望这样做。CLR 反射 API 允许使用 IReflect 和 IExpando 进行动态属性，以便人们找到这些属性。.NET 中的 JScript 支持使用这些来提供扩展属性。

下一步...

西雅图。再次。.

1. 安全和隐私
2. 国际化和本地化