Windows CE

本篇文件的主要目的是对比出在微软Windows CE(包括Pocket PC以及Windows CE .NET)上三种程序设计界面(API)的技术优点。通常，能拥有许多选择是件好事，但这也有可能导致我们要花更多时间在分析上。在选择应用程序接口的时候必须要深思熟虑，因为你所写下的程序代码不仅仅只是开发的时候要使用，也要考虑未来维护的便利性。

每个在本份文件中讨论到的应用程序接口(API)最初都是实作在微软桌上型(desktop)窗口上。实作在Windows CE .NET上的只是其子集合而已。如果你曾经在桌上型窗口下使用过其中任何一种接口，那么你将会发现其最核心的功能在掌上型窗口下一样支持。因此，你对前者具有的认知可能已足够你在后者作一个良

好的选择。不过事实上你还是没有使用掌上型应用程序接口(API)的经验，所以首先你必须决定要学习哪种。表格一摘要了这三种界面的优点及缺点，而文件的其余部分就是针对这个表格提供更详细的讨论。

表格一.三种Windows CE .NET程序接口的优缺处应用程序接口长处 Microsoft Win32 (C / C++)     执行文件跟动态连结函式库跑的最快且最小. 内存消耗最少. 对装置驱动程序来说是必须的选择. 对控制面板小程序(applet)是必须的选择.  扩充外壳(shell)的时候要用.像是Pocket PC上的今日桌面(Today screen)及使用者接口外观, 软件输入面板, 等等.  不需要执行期间程序(runtime)；Windows CE .NET本身就是执行期间程序. MFC (C++)   对象导向式. 继承, 封装, 多型,也被称作函式多载化. 容器类别支持数组, 表(list), 对象地图并简化数据处理(simplify data handling).   型别安全. 完整的MFC原始码与嵌入式视觉工具(Embedded Visual Tool)一同正式启用.  良好的工具支持. 一群程序魔术师们会为窗口、视觉函数(virtual function)新增讯息处里器,并新建窗体(form)及类别,. .NET Compact  设计精良的程序设计接口.  程序期间程序的大小. 目前尚在测  半自动清除内存,因此比Win32比起来较不易漏失内存.但因为MFC属于Win32上层的封装程序,因此还是很难不受影响. 执行期间程序的大小. 零售版mfc300.dll的大小是 404 KB.  程序导向, 非对象导向.  低阶应用程序接口，就像是Windows的汇编语言一样。因为拥有许多抽象(abstraction)而使它难以理解. 短处   突变出来的应用程序接口. 回收不用的内存空间是应用或驱动程序设计者的责任,使得这个应用程序接口(API)有漏失内存(memory leak)的倾向. Framework (C# and Microsoft Visual Basic® .NET)  对象导向式. 继承, 封装, 多型,也被称作函式多载化.  试阶段,但预期会小于2MB. 在受管理的程序代码(managed code)与未受管理的程序代码(unmanaged code)之间呼叫，开销很大.  与COM互通会有点不便. 需要写一个封装程序(wrapper)来呼叫COM的接口函式.  容器类别支持数组, 表(list), 杂凑表,字典(dictionary)以及堆栈   型别安全. 名称领域(namespace亦即区别XML文件中元素名称的一种方法).   自动内存回收,避免了漏失内存  可携的机器码指令集, MSIL / CIL,提供可携的二进制执行文件(.exe 及.dll).  需要显示型组态(IABASE) 的屏幕的显示平台, 但是此平台在无头(headless)及无标题组态(HLBASE)无法取得原始程序代码的是别号.  快速及易写的网站客户端服务(Web service client). 平台下却没有.   支持XML的处理. 良好的工具支持：整合表格设计师(integrated forms designer)让你更容易从工具箱(toolbox)拖曳工具.; 自动产生使用者接口元素(UI element)的程序代码.

Win32 应用程序接口

Win32是「Windows 32位应用程序接口」的简称。它是三种应用程序接口内历

史最悠久的，可以回溯到1992年启用的Microsoft Windows NT®。然而，它实际的年纪比这个更大。 Win32是以Windows 16位应用程序接口(Win16)为基础，而Win16早在1985年11月就跟Windows 1.01一起正式启用了。

其它的API皆极为依赖Win32 API。有人说过：「Win32是Windows的汇编语言。」即使你并不是选用Win32来当你的API，其它所用到的工具最后还是会呼叫Win32的函式来完成工作。这种事情在你要用到MFC或.NET Compact Framework不支持的功能时最为明显。MFC及.NET Compact Framework都允许你在此时连结入更底层的Win32 函式。

跟Windows桌上型(desktop)版本比较起来，Windows CE .NET支援较少的Win32

函式。虽然有些人会使用「子集合」这个名词来说明Windows CE内的Win32的地位，但是你也可以将之看作「Win32 API中最伟大的畅销作品」。设计Windows CE.NET的人为了让Windows CE .NET变小，慎重的挑选了应该包含及舍弃的函式，因此许多冗赘的函式都已被删除。例如，桌上型版本同时拥有TextOut跟ExtTextOut，但Windows CE.NET只有ExtTextOut。扮演与过去环境兼容角色的函式同样也被删除了。不支持Win16的登录(registry)函式，而只有最新的Win32版本是能被使用的。总之，Windows CE.NET上的Win32 是精简且兼容性高的，并只注重开发者会用到的工作。

Win32 API的好处

Win32 API是一条通往最小软件的路。Win32不像MFC和.NET Compact

Framework需要另外一个执行期间程序(runtime)。相反的，它本身就是一个执行期间程序。

Win32 API同样也是通往最快软件的路，这使得它成为作实时执行绪的理想选择。也就是说，如果你想要执行限时(time critical)的工作，你就应该使用Win32。MFC背负了C++带来的包袱，因此有点慢。

本文件内描述的另外一个选择.NET Compact Framework，会因为将微软中介语言(Microsoft Intermediate Language , MSIL)转换成原生指令集的这个动作而造成延迟。这只会在第一次将程序代码加载内存时发生，原来就存内存内的原生程序代码可被重复使用。此外，资源回收器(Garbage Collector)也有可能会在错误的时间执行，导致在限时程序代码中造成不能预期的延迟。

Win32同时也是兼容性最高的API。只要可以在Windows CE.NET内完成的东西，一定也可以在Win32 API内完成。甚至MFC的死忠拥护者也知道当某一功能在MFC内无法支持时，他们可以依赖Win32 API来完成。在这种情况中，全域运算子：「::」是MFC程序设计师最好的朋友。

虽然.NET内并没有全域运算子，.NET Compact Framework还是可以在需要的时候呼叫到Win32的函式。与MFC不同的是，在.NET有管理的部分与Win32未受管理的部分之间呼叫需要一些额外的支出，例如启动不同的平台(P/Invoke)。因此你从.NET Compact Framework拿取Win32函式时，必需要谨慎考虑。

因为Win32不需要执行期间程序，所以它也是一个最广泛被支持的API。如果你想写个可以在任何Windows CE平台上面跑的程序，Win32这条路准没错。如果

你想写个可以在各种不种平台间执行的应用程序，你就一定要使用Win32。我们同时也强烈建议您在写任何扩充操作系统的程序(例如装置驱动程序)时，记得使用Win32。

操作系统扩充装置

Win32对于某些组成因子来说是最好的抉择，特别是在想要支持范围广大的平台，但又不知道特定的执行期间程序是否会出现时。表格二陈列这些操作系统必要的扩充装置。

表格二建议使用Win32的组成因子 Component 装置驱动程序 Description 虽然Windows家族的其它操作系统皆定义了一个与Win32不同的装置驱动程序设计接口给它们，但是在Windows CE.NET中，Win32还是驱动程序们的官方程式设计接口. 特制的软件输入面板(SIP) 在口袋型个人计算机以及其它以Windows CE .NET为基础的装置上，SIP是指屏幕小键盘. 控制面板小程序(Applet) 在每个控制面板图示背后，都有一组动态连结函式库提供对话框、内容页(property page)、内容表(property sheet)以便订制出可安装的组成因子。 Windows CE .NET采用了可以让你订做使用者接口外观的面板。因此你可以任意的变换系统控制，以获得不同于正规Windows CE.NET的布置。这项功能在Pocket PC或是Pocket PC 2002上并不提供。 Win32比其它两种API提供更好的效能，因此Win32在你要编写限时程序代码时是不二的选择。使用者接口外观(UI skin) 实时执行绪

撰写Win32程序的挑战

Win32被视为是Win16的升级版。Win16跟微软开发的第一个图形使用者接口Windows 1.01同时出现。在那个时候，设计的焦点是放在作出一个方便使用的使用者界面即可。当时大部分计算机的使用者接口都是以字符为基础，而Windows 1.01成功的在1985年11月正式出线。苹果计算机的麦金塔比Windows

1.01稍微早一点点，在1984年1月启用。

Windows 1.01图形引擎(GDI)开发团队中穆林埃勒(Marlin Eller)曾表示：「虽然提高方便性是Windows 1.01着重的焦点，但是对于增加程序设计接口的便利性这点却不太获得重视，这个结果就是一个突变且前后不协调的API。」在很多情形下，参数栏都是空白，以便将来增加新的用途。许多函式也在没有解释的情况下就请你输入NULL或是零。

最明显的就是这两个常常要用到的函式：RegisterClass及 CreateWindow。前者要你将数据填入一个数据结构并传送这个地址，后者却是要你将所有的数据以一长串的参数传入。这种前后不配合的例子在Win32内一再的出现，造成了难学、难懂又难除错的Win32。

Win32：程序化的程序设计接口

Win16及Win32 基本上都是C的程序设计接口，因为C++是在它们之后好久才出现的。因为这个缘故，它们并不支持许多程序设计师视为理所当然的功能，例如函式多载化。换言之，Win16跟Win32是程序导向的程序设计接口。在C及汇编语言建立的API中，不会有类别或继承的功能。

这些API最棒的地方在于它们是以对象为基础(object-based)，而非对象导向的。会用这个术语是因为这个API广泛的运用了将数据包装在对象内的观念，并且里面有许多可以建立系统对象并回传控制柄(handle)的函式。例如你可以用CreateWindow这个函式来建立一个窗口，并回传窗口控制柄(window handle, HWND)。接下来你就可以藉由将控制柄传入函式的方式来移动，改变大小，隐藏，显示及删除窗口。事实上，最后一个删除窗口的动作是Win32 API的一个核心特性，而这个特性很容易让你写出容易漏失内存的程序。

如果你曾经当过管理者，你一定知道指派任务的重要。不管你是否曾分派过任务给人，你一定有过被分派任务的经验。这就描述了Win32管理系统对象的方法，因为这个任务是指派给你：一个程序设计师。

应用程序必需创造一个对象窗口，目录选单(menu)，对话盒，控制件，笔刷，字型等等以便能使用Win32。每当这个时候，内存就会被配置。每个程序都要摧毁它建造出来的对象以防内存漏失。若无法释放内存空间，就会发生每个软件的恶梦：内存漏失(memory leak)。如果有太多的内存漏失，无论是桌上型或是Windows CE.NET甚至是其它的操作系统都会当掉。

操作系统其实是有能力自动清除对象的，但是只有当Win32程序当掉的时候作这件事情才安全。不然，如果想要让一个程序执行很长的时间，就必须经过全盘的测试以确定它有自己清除对象的能力。

然而，现在已有种可以减轻痛苦的良药。Entrek公司开发出的

CODESNITCH(www.entrek.com)能够追踪并回报内存漏失。它会告诉你造成内存漏失的对象类型以及程序代码行数。CODESNITCH以猜测来取代真正追踪内存漏失这件麻烦事。

微软基础类别库

(The Microsoft Foundation Class Library, MFC)

当Win32发行后，程序设计师们还是努力的想创造出更好用的接口。MFC就是其中一个努力的结果，于1992年正式启用。

MFC被建造在Win32 API的上层。它对Win32程序设计师来说，是很容易上手的。因为它主要用户群就是用过Ｗin32后希望找到更好选择的人。因为这个原因，MFC命名的规则都延续自Win32。例如在绘图函式中，MFC使用了跟Win32一样名字的ExtTextOut、Rectangle以及BitBlt。大多数的时候，MFC内与Win32对等的函式是真的是用呼叫Win32做出来的。MFC比Win32还对象导向化，同时它也改善了Win32前后不同调的状况。例如Win16的MoveTo函数搬到Win32改叫做MoveToEx，但在Windows CE.NET根本没有这个函数。MFC会帮你处理细节，因此只要打上MoveTo即可。MFC提供了在不同平台间的原始程序代码可移植性。

对象导向方法的好处

MFC有个凌驾Win32的关键，那就是对象导向程序设计步骤。传统上就是指它可以支持继承，封装及多型。

MFC内可使用继承，其内的类别继承树更是庞大。就像在其它对象导向设计环境里，你可以从MFC基本类别出发来建造属于自己的独特类别。例如CWnd是每种窗口的基本类别；CView是专门给Document/View的窗口类别；CSrollView是CView的可拉式版本。

MFC的设计也支持了封装的功能。最基本的MFC类别将Win32的对象包装起来：CWnd包装Win32窗口、CDC包装Win32 DC、CListBox包装Win32 清单方块(list box)等等。MFC是以Win32为基础，因为都采用了跟Win32很像的名字以便惯用Win32的程序设计师使用。

多型(C++中支持)是指可用不同形式实作出同一方法的能力。MFC桌上型版本中也广泛的使用这项功能，例如CDC::TextOut有两个拥有不同参数的版本。然而在Windows CE.NET并不支持这项功能，因为相同函数若版本太多会占用过多的空间。在Window CE.NET执行的MFC亦奉行Window CE.NET的圭臬：让东西越少越好以保留更多的内存空间。

Document/View结构是个常常跟MFC有关联的基础模型。虽然你并不需要严格地遵照这个模型的规范，但不遵守规范的时候会需要剔除一些东西。

Document/View背后的基本想法就是：使用者会想建立、编辑、写入磁盘或从内存读出一份数据(亦即文件)，而这份数据可以不同的面貌(view)呈现给使用者。当你在Embedded Visual C++中使用开新计划精灵(New Project Wizard)时就能看到这种结构。你可以在对话式及Document/View式的MFC应用程序中做个抉择，但是运用Document/View最简单的作法还是以对话式为基础的。

另一个常在类别库出现的是容器类别(container class)，此外MFC还拥有数组、表以及对象地图。你可以用容器类别来聚集所有以CObject为来源的类别。若你想得到和在Win32内一样的帮助，那你就必须自己写程序代码。.NET Compact Framework提供了比MFC更棒的容器类别供你使用。

MFC在历史上曾经被那些想要在桌上型计算机建造应用程序的C++程序设计师们视为第一选择。它在使用者界面程序设计以及容器类别的使用上都给了我们很大的帮助，甚至还能支持所属操作系统的核心功能。例如，MFC为专在Windows CE.NET上使用的CCeDBDatabase 以及CCeDBProp提供了专属的类别。MFC只支持有在所属操作系统内出现的功能，若操作系统没有提供这项服务，那就表示MFC也不会支持它。例如Windows CE.NET没有ODBC 这个特色，在MFC中自然也就不出现了。

MFC的内存管理

既然MFC属于Win32的上层，而内存漏失又是Win32一项令应用程序及驱动程序设计师头痛的问题，那么MFC要如何解决这个问题？建构子及反建构子的出

现为MFC解决了部分的麻烦。对于GDI对象(例如位图bitmap、笔刷、字型、调色板以及所用到的区域等等)来说，在你摧毁MFC对象的同时，底下的GDI也会被清除。

然而，这些程序并不完美，因此你还是必须跟在用Win32时一样小心翼翼去注意对象是否已经真的被清除。用过MFC的桌上型开发者一定听过

AfxDumpMemoryLeaks这个函数。就像名字暗示的，它可以陈列出所有已被配置内存空间但还没被释放的对象。唯一的问题是，这个函数并没有出现在

Windows CE.NET版本的MFC…好险Entrek's CODESNITCH弥补了这个严重的问题。

.NET Compact Framework

.NET Compact Framework跟在Windows CE. NET上的Win32及MFC一样，都是其桌上型版本(.NET Framework)的子集合。.NET Compact Framework代表了下一个进化的阶段以及更精练的程序设计接口。.NET Framework.和它难兄难弟NET Compact Framework的出现解决了长久以来困扰Win32及MFC使用者的问题。当最终版正式启用后，它将会支持Pocket PC、Pocket PC 2002以及所有恰当以Windows CE.NET为基础的平台。

.NET Compact Framework：设计良好的API

.NET Compact Framework是个设计良好的API。跟MFC一样，都是对象导向式的，因此所有你需要的东西都包含在类别里。它之所以可以提供MFC没有的服务，是因为名称领域(namespace)的关系。虽然C++支持名称领域，但MFC并没有使用它们。在.NET Compact Framework里使用名称领域可以帮助组织API内的各项元素，以便在API内找到各种不同的功能。从使用者接口设计的行话来说，好的设计就反应在所有的元素都是可以找到的(discoverable)。譬如所有.NET Compact Framework支持的绘图功能都被放在System.Drawing这个名称领域中。而这个类别其中的一个成员：图形(Graphics)类别，等同于MFC中的CDC类别。你将会发现System.Drawing中的其它成员也都能输出图形。

另一项良好的设计呈现在容器(container)上。这不仅仅指出.NET Compact Framework有容器类别，更代表容器可被使用在.NET Compact Framework内任何地方。虽然在不同的地方出现，容器都能保有良好的一致性。例如每个Form都有ControlCollection,，ListBox 有ObjectCollection, 以及 DataSet 有

itsDataTableCollection，而这些例子都还只是所有范例中的一小部分。在每个这样的集合中，都有新增、移除以及得到列举子(GetEnumerator)这些方法。高程度的一致性意谓只要你熟悉其中一个集合，其它集合你就可以很轻易的上手。

.NET Compact Framework的内存管理

Win32及MFC都有内存管理的问题，大部分是靠程序设计师自行解决，即使不是全部。当你使用.NET Compact Framework撰写程序代码时，你是在一个内存管理良好的环境下写的。这个事实极为重要，因为「受管理的程序代码」(Managed Code)这个术语会跟.NET Compact Framework同时出现，而「未受管理的程序代码」(Unmanaged Code)就指的是那些不在.NET Compact Framework下撰写的程序代码。「未受管理的程序代码」意思是当你为对象(譬如字节、字符串、窗口对象或绘图对象等)配置内存时，执行期间程序会自动帮你追踪这些对象的动向。这些对象被使用完后，会自动被清除。因为系统有追踪对象的功能，所以它知道你何时使用完对象。它能清楚地纪录堆栈以及被放在堆栈上的对象。当内存所剩无几时，执行期间程序(称为共通语言执行期间程序，common language runtime, CLR)会清查堆栈上的对象，看看哪些是正在被使用的。使用中的对象会被保留，而用过的对象会被Garbage Collector捆起来一同摧毁以释放更多的空间。有Garbage Collector意谓.NET Compact Framework对需限时的程序代码来说，不是个好的选择，因为你无法预测Garbage Collector会在哪时候执行。

Garbage Collector的出现表示在C#这个语言里有新增(New)运算子却没有删除(delete)运算子。你可以把原来花在内存管理上的心思拿去思考如何处理手边的问题。

另一个也能建造出.NET Compact Framework的语言： Visual Basic .NET也与C#一样有Garbage Collector。使用Visual Basic 6的程序设计师将会很高兴听到Visual Basic.NET在Visual Basic 6下一样有新增运算子。而在他们了解到他们只有一种而不是两种内存配置运算子(没有CreateObject函式)后，他们将会更开心。既然这些对象的出现已没有必要，自然就消失的不露痕迹。

其它特色

.NET Compact Framework的类别集合(collection)跟MFC的类别库一样，能在应用程序开发上提供很大的帮助。就像先前所提到的，.NET Compact Framework用类别集合的某些部分来整合窗体内的控制、List box内的元素以及ADO.NET

类别内的数据库组件。换句话说，这些类别是设计来让你的工作做的更好。如果你曾经使用.NET Compact Framework的桌上型版本.NET Framework，你将会发现大部分但不是全部的类别被放进.NET Compact Framework里。被忽略的类别包括Queues以及SortedList。而被包含的功能有数组、数组列表(array list)、杂凑表以及堆栈。

.NET Compact Framework在服务数据库这方面经验丰富，它支持原本在桌上型版本的ADO.NET类别的子集合。ADO.NET有个建在内存内的表(DataTable)，而这个表与控制使用者接口有密切的关系。任何表上的改变都会反应在控制上，反之亦然。你也可以与外在的数据库作连结，例如数据提供者(Data Provider)、SQL服务器，或任何Windows CE.NET的原生数据库。这些数据都能被穿插到XML内，因此若要与任何以XML为基础的协议(例如SOAP)互动，.NET Compact Framework会是个很棒的选择。

.NET Compact Framework使与执行在网络服务器的SOAP基础网站服务互动变的容易。网站服务是.NET整合的一部份，它允许你越过HTTP协议对网站服务提供者作函式呼叫。虽然越过网络的呼叫函式并不是什么新鲜事，但这个被.NET 网络服务(Web Services)使用的机制却是。它取代了低阶对低阶的socket 呼叫、特定的低阶RPC程序代码以及DCOM远程接口。当你在呼叫.NET 网站服务时，感觉起来就像你平常在呼叫本地建造的对象一样。

以下是以C# 呼叫网站服务的例子：

paulyao.HelloServer serv = new paulyao.HelloServer(); MessageBox.Show(serv.HelloWorld(), \"Say\");

这个例子中，网站服务被放在一个叫做paulyao的服务器中。而此类别的名字就叫HelloServer。在你在近端建造一个实体后，你就可以呼叫成员函式HelloWorld，它会回传字符串：Hello World。虽然这是一个非常简单的例子，它却说明了呼叫.NET网站服务的函式是多么容易的事。更重要的是，建立网站服务的客户端是由.NET Compact Framework支援的。

.NET Compact Framework的可移植性

.NET Compact Framework的另一个好处就是它的执行档具有可移植性。这与Win32及MFC是非常不同的，因为它们都会因计算机种类不同而有不一样的执行档。这两个API也具有可移植性，但是在原始码阶段。Win32或MFC建立出

的二进制执行文件会包含各种机器的指令(例如x86、进阶精简指令集机器ARM、MIPS、SH3、SH4等等)。

相反的，.NET Compact Framework的执行档却有真正可携的机器指令集，它藉由利用PE档案形式(所有以Win32为基础的系统以及Windows所有版本的共同标准)当作格式来达到目的。这些执行文件使用微软中间语言(MSIL)来取代任何特定的指令。当呈到欧洲计算机制造者协会(European Computer Manufacturers Association ECMA)的标准团体时，它被叫做共通指令语言(Common Instruction Language CIL)。任何为了.NET Compact Framework而以上述这两种语言撰写的执行文件皆可在以Windows CE.NET为基础并装设有执行期间程序的系统下执行。

.NET Compact Framework的短处

跟MFC一样，.NET Compact Framework需要一个执行期间链接库，其实不只一个，是一组。我们预期这些链接库跑过的足迹最多占掉2MB的空间，但是这对某些内存很少的装置来说，还是太贵了。

另外一个.NET Compact Framework需要处理的是潜在的效率问题。将MSIL/CIL转换成原生程序代码需要花上一些时间。这种延迟对需要实时处理的应用程序来讲可能变成一个大问题。在大多数的情况下，需限时的工作会由一个执行Win32程序代码的执行绪来负责，而它会有自己的动态连结函式库。毕竟实时工作是装置驱动程序以及其它低阶程序代码主要的工作范围。.NET Compact Framework在建造使用者接口、应用程序绘图以及连结数据库跟网站服务这些领域上特别有用。如果你正在做一个需要限时的应用程序，用.NET Compact Framework开发使用者接口然后以Win32原生动态数据库处理实时执行绪这种方法会同时使用到两种API的优点。

在.NET开发过程中，COM(Component Object Model)变成类似遗产的技术。COM在桌上型以及部分的Windows CE .NET上还是被大量的支持。然而，.NET还是以它「受管理的程序代码」(managed code)、增加的安全性以及MSIL/CIL指令集可移植性取代了 COM成为微软技术的核心走向。在十年前，COM跟Win32是微软软件技术的中坚份子。随着.NET的到来，COM再也不是核心技术了。桌上型的.NET Framework还是可以利用与「未受管理的程序代码」相互操作的技术支持COM，以便能在分布式内存上节省空间。.NET Compact Framework并不直接支持与COM组成因子的双向操作，但可透过C语言呼叫的Win32动态连结库来互动。

.NET Compact Framework以使用者图形接口为导向，并深深的依赖GWES(图形、窗口以及事件子系统Graphical，Windowing and Event Subsystem)来操作。这意味着.NET Compact Framework需要在一个以屏幕显示为基础(IABASE)的平台上执行，在无头(HLBASE)装置上并不支持。对于平台建造开发者(Platform Builder developer)而言，这也表示了.NET Compact Framework并不支持「媒体家电Media Appliance」, 「居家用匝道器Residential Gateway」或是「小型操作系统的核心程序Tiny Kernel configuration」。这个事实造成最大的影响是任何无头装置必需要用SOAP 2.0来取代.NET Compact Framework建造网站服务客户端。

结语

总结地来说，我们可以参考下列各种不同API间的比较来决定该使用哪种API： Win32 API是最小且最具可移植性的API。若你使用平台开发者(Platform Builder)来建造HLBASE的无头平台，那么Win32是最合理的选择。若你打算以装置驱动程序、使用者接口延伸、软件输入面板或控制面板applet来扩充操作系统，就应该选择Win32。若你正在建造一个需要实时处理的系统，例如一个每次都能在10毫秒内反应的硬件，Win32更是不二的抉择。更重要的是，即是你选择了Win32以外的API，你还是会用到大多数程序设计师都熟悉的Win32，因为MFC以及.NET Compact Framework总有要用到底层Win32来作一些低阶功能的时候。 MFC是建造可以编辑及观看数据的应用程序的一个很好的工具，因为它有内建document/view结构(有时被称作model/view形式)的优势。当你想要一组可以用对象导向方法来驯服底层Win32 API的类别时，MFC也是个很好的伴侣。若你想要更广泛的使用已存在的微软ActiveX®及COM组成因子，MFC是唯一有内建与COM结构整合机制的对象导向式框架。MFC原始程序代码的存在表示当你需要除错时，你可以深入MFC底层的Win32追踪错误。这是个可以帮助你在使用MFC时学习Win32的无价宝贝。

我们还有.NET Compact Framework这个选择，它用更多的容器类别以及更坚固的资源回收器(garbage collector)来提供使用者比MFC更好的对象导向结构。.NET Compact Framework靠着MSIL/CIL可携式指令集建造比Win32及MFC执行档更具可移植性的执行档。.NET Compact Framework在.NET的世界中是个很棒的玩家，它强力的支援.NET网站服务、XML的处理，还能透过ADO.NET取得数据库。它同时也能让使用者在两种程序语言：C#以及Visual Basic .NET(一个能将两个执行文件天衣无缝整合起来的语言)中作一选择。

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文

全部栏目

Windows CE