Microsoft Windows CE 3.0中的COM和DCOM

Microsoft Windows CE 3.0中的COM和DCOM

Microsoft Corporation

May 2000

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

摘要：COM是一个用来创建二进制软件组件的、平台无关的、面向对象的系统，它可以和其他基于COM的组件在同一个进程空间或远程机器上不同的进程中相连接。COM对其他Microsoft技术来说是项基础技术，比如Active Server Pages (ASP), Automation, ISAPI, 和 ActiveSync.

这篇文章讲述COM/DCOM on Windows CE 3.0的编程模型，并概述其与Windows NT执行的COM的不同之处。阅读本文的基本要求是熟悉COM对象和接口、类型库、了解分布式程序设计。

Windows CE COM模块

希望将COM runtime 支持加入到Microsoft® Windows® CE 3.0 平台的开发者们可以选择COM/DCOM implementation，这是最符合他们目标设备要求的。

最小化的implementation支持in-process servers (DLLs)进程内服务器, Automation自动化, type libraries类型库, memory management内存管理, compound documents混合文档, 和 structured storage结构化存储。只有free-threading模式被支持，应用程序必须加强自身同步方法的手段。 这个implementation可以被Windows CE 2.0有效使用。Windows CE 2.12添加了对Microsoft ActiveX® controls, IDispatch, 和几个 Automation 数据类型的支持。

更丰富的implementation支持in-process and out-of-process servers, remote operation, Distributed COM (DCOM), multi-threading, 和 the apartment model。功能上实际上和Microsoft Windows NT® 4.0 with Service Pack 5 (SP5)所支持的是相同的。这个implementation可以被一些基于Windows CE 3.0的OEM-provided平台使用。除非另有说明，在本篇文章中"COM"术语是指原始的Windows CE implementation，而"DCOM"指新近出现的，更多附加功能的implementation。注意，一个简单的程序模块覆盖所有COM服务，无论进程内、本地或者远程，这里的使用方法与桌面程序有些不同。

最后，应用程序开发者应该注意到不是所有的Windows CE设备平台都包括COM运行时支持。如果想核对Windows CE设备平台对COM支持的程度，请查看OEM的SDK文档。

Automation自动化

Automation（即OLE Automation）是一项基于COM的创建ActiveX对象或控件的技术。 有限的Automation支持被添加入2.12版本的Windows CE，在COM和DCOM implementations中是相同的。

Windows CE Automation 不同于Windows NT implementation 的地方包括下面几点：

Windows CE Automation只支持in-process, free-threaded automation对象。

IDispatch 接口和许多本地化 automation 类型—Variants, BSTRs, SAFEARRAYs—被支持。开发者可以实现对这些类型的配置。

因为Windows CE设备不一定包括一个shell,shell interactions（例如drag-and-drop）不被支持。

如何在Windows CE 3.0上写ActiveX控件的更多信息，请看文章How to Write and Use ActiveX Controls for Windows CE 3.0。

OLE 混合文档

COM和DCOM都支持混合文档。此外，因为Windows CE设备可能不包括一个shell，所以这里不支持shell-based的交互，例如菜单合并或者drag-and-drop操作。

Security安全性

当执行分布式程序时，有两种安全性级别。

网络安全性引用谁可以访问这台计算机。

本地安全性引用用户登陆后可以做些什么。

在Windows CE中本地安全性的控制有所不同，它将访问控制和紧急系统组件作为一个整体，胜于Windows NT上一个资源以资源为基础。

在Windows NT上，当一个用户authenticated（鉴别）并连接到一个对象时，该对象运行的security credentials属于连接客户端，交互式用户或者清晰指定的用户计数，可以编程指定或者在注册表中（例如，通过DCOMCNFG）。对象在进程中获得的Security credentials（调用"impersonation"）控制访问系统资源。 因为Windows CE不提供对单独对象的访问控制机制，impersonation也不被支持，服务器可以访问所有的系统资源（被Windows CE信任级别保护的除外）。

在Windows CE上，DCOM安全检查有两步组成：authentication 和访问时检查。

Authentication验证

当一个对象连接到一个服务器，authentication通过NTLM完成。一个Windows CE上的DCOM对象可以在任何authentication级别被调用，但是被引入的调用不能到达一个更高的authentication级别。

"CONNECT" (RPC_C_AUTHN_LEVEL_NONE

or RPC_C_AUTHN_LEVEL_CONNECT).

在成功authentication之后，访问检查依靠一个访问列表被执行。这个访问列表通过默认的注册表键值被创建，或者在服务器初始化时通过DCOMAccessControl来编程实现。如果访问检查成功，用户被准许访问整台机器。

Access Control访问控制

Windows CE 包含一个DCOMAccessControl对象的实例，当DCOM运行时使用所有的内在安全检查。通常， DCOMAccessControl对象被AccessPermission的结构和DefaultAccessPermission注册表键值初始化。作为选择，该值可以通过CoInitializeSecurity来编程提供。用户authentication是基于NTLM 的用户名/密码验证。一个用户列表可以被用来确定每一个用户的访问权限，下面将具体说明。本地激活和访问请求总是被准许。没有访问检查被执行。

注意和Windows NT不同的是，在注册表中修改安全设置的工具必须调用UpdateDCOMSettings使DCOMSS更新他们的设置。注意UpdateDCOMSettings在标准系统头文件中没有被声明，因此你需要在你自己的头文件中声明这个函数，如下，

void UpdateDCOMSettings (void);

并连接OLE32.LIB。

同样，所有已经运行的DCOM组件必须被重新加载，新设置对他们有影响（例如，如果一个用户改变了一个组件LaunchPermission和AccessPermission的值，并且这个组件已经加载，它将被重新加载使许可生效）。

DCOMAccessControl对象IPersist接口的Load方法，被用来装载注册表信息，它在Windows CE上的实现和其他windows平台上是不同的。在Windows CE上，Load方法分类访问不依照IAccessControl接口方法分类访问的规则。这允许更多的fine-grained控制被用户和groups访问。

Structured Storage结构化存储

结构化存储在2.12版本被添加到Windows CE COM中，而且在COM和DCOM 3.0版本中没有变化。

Windows CE支持IStorage接口，数据格式和桌面执行是一致的。然而，没有配置支持。

Threads and Processes线程和进程

在最小化COM构造中，Windows CE不支持concurrency管理。这意味着你的应用程序要为同步访问不同的对象负责。多线程将不能访问ActiveX控件，它们和线程的密切关系应归于它们使用的thread-specific资源。因为COM结构不支持线程套间，你不能在一个单独的线程套间内实现数据同步。你必须直接调用简单的thread-synchronization来保护成员和全局数据。注意这个限制不适用于DCOM结构。

在Windows CE中，如果ThreadingModel的值在系统注册表中没有被设置，线程模式默认为“Free”。在COM执行中，Windows CE 上的COM版本不支持其他的线程模式。然而，因为DCOM执行支持所有的线程模式，采用和Windows NT COM/DCOM相同的方式在套间间进行交互，你的应用程序设置注册表键值是关键。特别的，如代理对象，你必须设置ThreadingModel为“Both”，意为single-和multi-threaded两种套间类型都支持。如果创建失败，代理对象通过一个线程属性访问不同的套间，DCOM运行时将尝试配置这个对象，并且会配置失败。

DCOM执行要求所有对象拥有thread/process affinity。这意味着在Protected Server Libraries (PSL)中的线程不能创建或者访问在一个DCOM应用程序中的对象或者API，这需要一个外在的concurrency模式（对象必须调用CoInitializeEx来进行初始化）。需要明确的，这个限制适用于任何操作系统对一个应用程序的回调，和DLL初始化或者终止函数，和驱动程序的任何请求。

Transport Protocols传输协议

DCOM for Windows CE支持TCP/IP和本地进程通信。如果你没有安装TCP/IP，DCOM将不能支持cross-machine COM。

作为桌面版本的COM，一个线程可以调用CoCreateInstance或者CoGetClassObject来创建一个新的组件实例。然而，在Windows CE下，这些调用中的dwClsContext属性必须被设置为CLSCTX_ INPROC_SERVER。

在2.12版本中，你可以通过指定CLSCTX_ ALL或者CLSCTX_SERVER激活进程内COM对象；Windows CE更早的版本，如果这个标志没有被明确的指定为CLSCTX_INPROC_SERVER，则将返回一个E_NOTIMPL的错误。加之，调用CoGetClassObject时的COSERVERINFO属性必须为NULL，因为Windows CE COM（最小化进程内执行）不支持远程服务器。

IClassFactory* pFactory = NULL;

::CoGetClassObject(CLSID_MyObject,

CLSCTX_INPROC_SERVER, NULL,

IID_ICLASSFACTORY, (LPVOID*)

&pFactory);

pFactory->CreateInstance(NULL,IID_IMyObject,

(LPVOID*) m_pObj);

在初始化他们之前，DCOM执行需要你通过调用CoInitializeEx来初始化对象。

COM执行不强迫执行对象初始化，但是这仍是被推荐的。

For More Information更多信息

背景和概念方面的知识可以通过下列资源获得：

On MSDN, see Platform SDK, Component Services, COM section.

The Pocket PC Web site.

The Windows-Powered Mobile Devices Web site.

Rogerson, Dale. Inside COM. Redmond, WA: Microsoft Press, 1996.

其他的COM开发者指南，可以查看Microsoft Press Web。

查看Windows CE Platform Builder的文档“Security Support Provider Interface”，里面有对本地和pass-through 证明的完整讨论和使用及配置的信息。