Microsoft Windows CE 3.0中的COM和DCOM
Microsoft Corporation
May 2000
摘要: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 证明的完整讨论和使用及配置的信息。