简介

项目
10/26/2006

简介

布伦特校长
Wise Owl Consulting

2003 年 10 月

到目前为止，Microsoft® Windows® 本身已经以这种方式发展。最初，编写 Windows 应用程序意味着对 Microsoft Win32® API 进行编程。 (实际上，它曾经是 Win16 API，但它们在概念上是相同的。) Microsoft 将 Win32 API 设计为可由 C 程序调用的平面过程 API。曾一度，任何 Windows 应用程序开发人员都需要阅读 Charles Petzold 的介绍此 API 的 Windows 编程书籍。

Win32 API 的一个好东西是，它允许你执行任何你想要的任意操作。 (不太好的事情是，你几乎必须做你想要的一切。) 你首先破解所有 Windows 消息，并可以响应事件信号的任何适当 (或不适当的) 方式。你可以根据需要修改内存（你自己的进程的内存，甚至是另一个进程的内存），但安全允许。你可以按照自己喜欢的任何方式绘制窗口。你的工作只是在正确的时间将正确的位获取到屏幕的正确位置。

Windows 本身的设计实际上非常面向对象。操作窗口对象、使用图形笔等。但是，可以通过按正确的顺序调用数千个可用) 中 (正确的 API 并传递正确的数据类型来执行这些操作，在出错时，大多数情况下没有编译器的帮助。

当 Microsoft 首次发布 Windows 和几年后，软件开发人员通常会编写单一的独立应用程序。开发人员没有用于撰写应用程序的组件，也没有支持组合的机制;此外，应用程序没有尝试与同一系统上的其他应用程序通信，更不用说与不同计算机上的应用程序通信了。

1993 年，Microsoft 引入了组件对象模型 (COM) 。 Microsoft 将 COM 设计为尝试解决以下两个问题。 COM 引入了二进制标准，以便由不同源语言编译器生成的组件可以使用不可变接口定义进行互操作。分布式 COM (DCOM) 网络协议允许这些组件跨进程和计算机边界进行交互。

Microsoft 在 1993 年之后引入的许多 Windows API 都是基于 COM 的 API。两个示例是 Microsoft DirectX® 和 Shell 扩展 API。如今，Windows 拥有 10，000 多个 API，这些 API 由许多不同的开发人员在具有不同目标的多个不同团队中设计。因此，Windows 将一些 API 公开为动态链接库中的平面 C 语言入口点， (DLL) 。它将其他 API 公开为一组复杂的交互 COM 接口。可以使用其他技术访问其他 API。

实际上，你（开发人员）希望操作系统在大多数时间中保护你免受这种复杂性的大多数问题。因此，Microsoft 内外的许多不同的团队开发了各种框架库来简化应用程序开发。一些常用的框架库包括 Microsoft 基础类 (MFC) 、Microsoft ActiveX 模板库 (ATL) 、Microsoft Visual Basic® 中的库、Borland 的对象 Windows 库 (OWL) ，以及无疑许多其他库。

例如，MFC 尝试使用一组一致且面向对象的 C++ 类包装 Win32 API 的各种特性。当你选择的编程语言是 C++ 并且 MFC 库直接支持你想要执行的操作时，你的工作就很容易了。但是，当你想要一些略高于主流的东西时，你大多会再次依靠自己，事实上，情况比以前更糟，因为现在你必须弄清楚如何使用 Win32 API，以及使你的工作与现有 MFC 类互操作。

ATL 允许你编写极其高效的 COM 对象，并在较小程度上编写使用模糊和 (的 Windows 应用程序，以便许多开发人员) 对基于 C++ 模板的类知之甚少。说你很容易最终得到没有人能理解的高效对象，这并不遥远。

Microsoft 的 Visual Basic 团队采取了不同的方法。他们以易于学习和使用的语言和库包装了对 Win32 API 的访问，但代价是删除功能和选项。 Visual Basic 使得为应用程序和使用此类组件的应用程序生成组件变得非常简单。但是，Visual Basic 不允许你完全访问 Win32 API 提供的所有内容。有时，由于所选开发环境施加的限制，Visual Basic 开发人员根本无法完成任务。

在20世纪90年代初到中期，万维网起飞了。计算机开始变得越来越连接。最初，Web 浏览器只是呈现静态 HTML，浏览 Web 就像查看杂志页面一样。

当 Microsoft 在 1997 年发布 Internet Explorer 4 时，出现了其他可能性。开发人员可以创建包含脚本和标记的 HTML 文件。 HTML 对象模型中的对象获得了行为，你可以编写响应事件并提供自定义行为的脚本。 HTML 页面现在可以对客户端上的用户事件做出响应，并且响应速度比之前的基于 Web 的应用程序快得多，这些应用程序要求每次屏幕更新都往返到服务器。

Web 应用程序的一大优势是，只需将一组文件复制到服务器即可轻松部署应用程序。下次客户端浏览到应用程序时，她与最新版本交互。

Web 应用程序的另一大优势是内置支持富媒体集成。与目前通过 Win32 应用程序提供相比，基于流的页面布局和对多种字体、图形和多媒体内容的支持要容易得多，无论使用哪种框架。

但是，总体而言，目前编写 Web 应用程序仍然很困难，因为此类应用程序的编程语言和库支持有限。调试 Web 应用程序通常是一场噩梦。在许多方面，客户端用户体验仍然不如基于 Win32 API 的客户端应用程序提供的丰富体验，因为 Web 应用程序可用的控件集有限。

到 20 世纪 90 年代末，Windows 开发人员经常必须专攻。你是一名 Win32 API 程序员，可以缓慢地编写任何类型的客户端应用程序。或者，你是一名 Visual Basic 开发人员，可以快速编写相对丰富的基于表单的用户界面 (UI) 应用程序，但根本无法编写某些其他类型的应用程序。 MFC 开发人员在某种程度上跨越了这两个极端，尽管在实践中，你需要是一个熟悉 Win32 API 的熟练 C++ 开发人员，才能成为一个优秀的 MFC 开发人员。 ATL 和 COM 对象开发人员通常是系统的管道工，并为这些其他开发人员提供组件以供重复使用。

2000 年，Microsoft 引入了 .NET。确切的 .NET 的定义 因你询问的人员而异。在我看来，.NET 是一个新式软件开发平台，用于生成使用最新技术（如 XML 和 Web 服务）的 Windows 应用程序，其生成速度比以前快得多，同时仍允许访问你的传统代码。

一般情况下，.NET（尤其是托管代码）为软件开发人员提供了许多好处：

面向对象的、与语言无关的类型安全对象模型。
减少了不同版本组件之间的冲突。
由于常见的编程错误，减少了 bug 和安全漏洞的数量。例如，不再有缓冲区溢出，也不再出现内存管理错误。
所有开发人员都可以使用的单个框架和库集。 .NET Framework类库将最常用的 Win32 API 以及许多 SDK 提供的许多其他 API 封装在统一包中。
比之前可用的抽象更高。

在某些方面，.NET 只是一个新的面向对象的、与语言无关的框架，它封装了 Win32 API 的许多方面。就我个人而言，我更愿意将 .NET 视为 Win32 API 的一种最先进的替代方法，目前还不完整，但会随着时间的推移变得更加完整。

例如，.NET 版本 1.0 提供面向对象的、基于表单的客户端应用程序开发类。你可以将它们视为对基本 Win32 开窗 API 的包装器。但是，.NET 还提供封装 Web 应用程序开发和 HTML 加行为生成的 ASP.NET 类。这些类实际上扩展了 Windows API，并不是 Win32 API 中任何内容的真正包装器。 .通常，NET 对 Web 服务和 XML 的丰富支持是 .NET 提供的新功能的另外两个示例，而不是围绕现有 Win32 功能的简单包装器。

这本书的内容

本书重点介绍面向开发人员的 Microsoft“长角”功能。从开发人员的角度来看，“Longhorn”提供了新功能，我们可以在五个方面进行广泛分类：

“Longhorn”应用程序模型

“Longhorn”以更强大的新方式定义应用程序。

“Longhorn”API 是托管类，用于处理大部分编程事务并减少开发人员的工作负荷。支持 .NET 公共语言运行时 (CLR) 的所有第三方开发人员编译器和工具都自动支持新的“Longhorn”API。
“Longhorn”应用程序模型支持传统的基于表单和基于页面的新导航应用程序。基于应用程序页的导航支持由操作系统提供。
新的“Longhorn”安全和隐私模型是托管 API 和数字标识组合的结果，它从开发过程开始时就提供应用程序安全性。 “Longhorn”应用程序和组件是受信任的，因为它们使用托管代码。
“Longhorn”API 代表各种当代技术的最佳开发概念。在许多方面，开发人员不再受到十多年前做出的设计决策的限制。
自动进行应用程序状态管理和保留，以便更轻松地开发应用程序。
ClickOnce 部署技术支持复杂的部署功能，例如在程序文件中安装、版本控制、并行安装和 Drizzle 下载。
归纳 UI 引导用户完成任务。
平台中内置了辅助功能和自动化功能。应用程序会自动获得此类支持。

可信计算和安全性

“Longhorn”基于公共语言运行时代码访问安全性 (CAS) 模型，但具有重要的扩展。

“Longhorn”识别某些应用程序是完全信任的，而其他应用程序只有部分信任。完全参与“Longhorn”安全模型的应用程序将具有对“Longhorn”功能的完全访问权限。仅部分参与模型的应用程序将具有一些好处，尽管存在限制。
“Longhorn”提供一个超安全的托管代码运行时环境，称为安全执行环境 (SEE) ，可保护用户免受“不良”应用程序行为的破坏。
信任管理器为“Longhorn”应用程序提供评分系统，用于确定用户可以授予应用程序的建议信任级别。
“Longhorn”提供了一个安全信任中心，允许用户管理热修补程序和访问 Windows 更新。此外，安全顾问会通知用户安全风险和违规行为。
数字版权管理是托管代码的一部分，为知识产权提供强有力的保护。这样就可以在“Longhorn”环境中安全存储和传输以前易受攻击的知识产权。
“Longhorn”使用数字签名唯一标识用户和计算机。与用于验证的签名机构结合使用时，“Longhorn”可以安全可靠地识别计算方案中的单个用户。

丰富的存储和数据访问

“Longhorn”通过新的文件系统提供显著改进的应用程序数据存储和访问。

新 ADO.NET 改进了数据访问。
日常信息（如联系人、组织、地址等）的常见架构允许应用程序、操作系统和 shell 访问共享信息。事实上，新的 shell 用户界面是新存储系统中最重的用户之一。
应用程序可以将其他元数据附加到文件系统中的对象，这比使用传统文件系统可以更快地搜索和检索文件对象。
使用动态数据绑定自动将“Longhorn”环境中的对象更改传播到这些对象的其他实例。

通信和协作

“Longhorn”应用程序现在具有各种通信和协作功能。

会话和频道等功能为参与者提供了丰富的协作服务。
通信和协作功能可以通过防火墙和网络地址转换 (NAT) 安全地运行，从而允许遍历公司边界。
基于 Web 服务的标准化通信允许旧版和新应用程序参与协作。
基于服务器/基于对等的通信功能可以通过集中式基础结构运行，也可以直接对用户客户端进行操作。
虚拟状态支持允许用户通过类似于即时消息 (常见通知、邀请等) 功能与他人协作。
集成安全性是这些功能不可或缺的一部分。
可以识别 Shell 扩展性支持（例如协作 ** 谓词 (使用默认聊天客户端等) ），以便在“Longhorn”实时通信中使用熟悉的工具。
新的人员 Picker 控件等常见控件为通信应用程序提供高级应用程序支持。

丰富的演示文稿和媒体

开发人员可以使用“Longhorn”中提供的演示文稿和媒体服务更轻松地生成提供丰富用户界面的应用程序。

“Longhorn”为开发人员提供了丰富的图形类，这些类提供利用硬件加速的动画、效果和视觉上令人兴奋的图像。
强大的声明性和动态矢量图形允许为高分辨率输出设备灵活呈现和缩放，同时节省资源，因为图形是从描述性语言生成的。
轻松应用的动画提高了 UI 的可用性和连续性。
图形支持使用硬件加速 DirectX/3D 视频卡来创建更身临其境和流畅的环境。
应用程序可以无缝集成各种形式的用户界面-图像、视频、音频、矢量图形、控件、文本等。
新的布局模型允许富文本和媒体显示，因为框架会自动根据屏幕大小调整分页、位置等。
新的文本服务（如包含子像素呈现 (ClearType) ）允许在任何电脑上使用与可能的屏幕分辨率无关的 3D 加速器实现具有视觉吸引力的 GUI。
可以将不同的数据片段合并到容器中，这些容器可以在 UI 中移动。
根据类型、值或其他规则对数据进行条件转换，使开发人员工具能够创建更加明了的 UI。
广泛的多媒体平台允许音频和视频的无故障播放;电脑和消费电子设备之间的分布式 A/V 体验;最高质量的音频和视频编解码器;实时、高清内容捕获和编辑的高性能;丰富的 CD、DVD 和电视元数据服务。

你将在本书中找到的内容

其中每个主题都可以轻松自行填写一本书。因此，我不会在“Longhorn”中描述所有各种 API。我也不会深入介绍每种技术的详细描述。 这不是 API 或参考书。我相信，没过多久，你就能找到书店里提供的许多稍微编辑和重新整理的文档副本。

我要做的是告诉你如何开始开发“长角”。至少应该阅读第 1 章和第 2 章，因为它们涵盖了开发“Longhorn”平台应用程序所需的绝对基础知识。

第 1 章介绍了新的应用程序模型。不要通过 Go。不要收取 200 美元。你真的需要阅读第 1 章，否则你会在邮件中收到一个去监狱卡。我还介绍了第 1 章中的新标记/编程语言。无论你是 VB.NET 开发人员、C# 开发人员还是神话 COBOL.NET 开发人员之一，都需要学习这种新的标记/编程语言。阅读第 1 章：“Longhorn”应用程序模型。我不是在开玩笑事实上，现在去做，然后回来。我会等的

好了，现在你已阅读第 1 章并兴奋地生成自己的应用程序，你可能应该阅读第 2 章。其中介绍了如何编译、部署和运行“Longhorn”应用程序。因此，第 2 章也很重要，但没有必要急于去。这是一个非常耐心的章节，将等待你完成这个介绍。

其余章节介绍我在此简介中介绍的各种技术。第 3 章是使用新标记语言创建用户界面的精彩介绍，并为你提供了其功能风格。第 4 章介绍了新的文件系统 API，并可能导致你放弃 Win32 文件系统 API。

第 5 章介绍如何使用数据绑定将数据从几乎任何 .NET 对象移动到用户界面，然后再次返回，而无需编写任何过程代码。我在第 6 章中介绍如何创建功能强大、安全可靠的通信应用程序。最后，最后一章讨论了创建新式连接移动应用程序的一些准则。

感谢你一直待到这个漫长的介绍结束。现在是时候阅读第 2 章了。 (你以前读过第 1 章，不是吗？ ) 玩“长角”玩得开心。我当然有！

继续学习第 1 章：“Longhorn”应用程序模型

布伦特校长

Brent Rector 是 Wise Owl Consulting (www.wiseowl.com) 的总裁和创始人，在软件开发方面拥有 30 多年的经验。 Brent 设计并实现了操作系统以及新的计算机编程语言及其编译器。 Brent 于 1985 年开始使用 Windows 1x beta 开发 Windows 应用程序，此后一直参与 Windows 开发。他是许多 Windows 编程书籍的作者和合著者，包括 ATL 内部 和 Win32 编程。 Brent 也是 .NET 的 Demeanor 的作者，这是 .NET 应用程序的顶级代码模糊处理器。

IntelliSense、Microsoft、MSDN、MS-DOS、Visual Basic .NET 和 Visual Studio .NET 是 Microsoft Corporation 在美国和/或其他国家/地区的注册商标或商标。本文档所提及的其他产品和公司名可能是其各自所有者的商标。

通过

简介

简介

目录