COM and DCOM in Microsoft Windows CE 3.0
Summary: COM is a platform-independent, object-oriented system for creating binary software components that can interact with other COM-based components in the same process space or in other processes on remote machines. COM is the foundation technology for many other Microsoft technologies, such as Active Server Pages (ASP), Automation, ISAPI, and ActiveSync.
This paper describes the programming model for COM/DCOM on Windows CE 3.0, and summarizes the differences between the Windows CE and the Windows NT implementations of COM. Familiarity with the COM objects and interfaces, type libraries, and essential distributed programming concepts is assumed. (6 printed pages)
The Windows CE COM Modules
OLE Compound Documents
Threads and Processes
Using COM Objects in Windows CE
For More Information
Platform developers who wish to add COM runtime support to their Microsoft® Windows® CE 3.0 platforms can chose the COM/DCOM implementation that best meets the demands of their target device:
- A minimal implementation that supports in-process servers (DLLs), Automation, type libraries, memory management, compound documents, and structured storage. Only the free-threading model is supported and the application must enforce its own means of method synchronization. This implementation is available effective with Windows CE 2.0. Windows CE 2.12 added support for Microsoft ActiveX® controls, IDispatch, and several Automation data types.
- A richer implementation that supports in-process and out-of-process servers, remote operation, Distributed COM (DCOM), multi-threading, and the apartment model. Functionality is virtually identical to that provided in Microsoft Windows NT® 4.0 with Service Pack 5 (SP5). This implementation is available on some OEM-provided platforms built on Windows CE 3.0.
Unless otherwise specified, in this paper the term "COM" refers to features available in the original Windows CE implementation, and "DCOM" refers to the features provided only in the newer, more full-featured implementation. Note that this usage varies somewhat from the desktop documentation where a single programming model covers all COM services, whether in-process, local, or remote.
Finally, applications developers should note that not all Windows CE device platforms include COM runtime support. To verify that a particular Windows CE device platform provides the level of COM support your application requires, see the SDK documentation provided by the original equipment manufacturer (OEM).
Automation (formerly OLE Automation) is the COM-based technology for creating ActiveX objects, or controls. Limited Automation support was added to Windows CE in version 2.12 and is identical in both the COM and DCOM implementations.
Specifically, Windows CE Automation differs from the Windows NT implementation in the following areas:
- Windows CE Automation supports only in-process, free-threaded automation objects.
- The IDispatch interface, and most native automation types—Variants, BSTRs, SAFEARRAYs—are supported; however, there is no automatic marshaling support for these, or any Windows data types. The developer can implement marshaling for these types.
- Because Windows CE devices may not include a shell, shell interactions (for example, drag-and-drop) are not supported.
For more information on writing ActiveX Controls for Windows CE 3.0, see the article How to Write and Use ActiveX Controls for Windows CE 3.0.
Both COM and DCOM support compound documents. Again, however, because Windows CE devices may not include a shell, there is no support for shell-based interactions, such as menu merging or drag-and-drop operations.
There are two levels of security to consider when implementing a distributed application.
- Network security refers to who can access a computer.
- Local security refers to what a user is permitted to do on a computer after gaining access.
At the network level, DCOM security on Windows CE 3.0 is equivalent to the Windows NT 4.0, SP5 implementation, which is based on NTLM authentication.
Local security is handled differently on Windows CE, which regulates access to critical system components as a whole, rather than on a resource by resource basis as is done on Windows NT.
On Windows NT, when a user is authenticated and connected to an object, the object runs with security credentials belonging to either a connected client, interactive user, or explicitly specified user account, as specified programmatically or in the registry (via DCOMCNFG, for example). Security credentials that the object acquires in this process (called "impersonation") controls access to system resources. Since Windows CE does not provide access control mechanisms for individual objects, impersonation is not supported, and the server has access to all system resources (except as protected by Windows CE trust level).
On Windows CE, the DCOM security check consists of two steps: authentication and then an access check.
When an object connects to a server, authentication is performed via NTLM. A DCOM object on Windows CE can make calls at any authentication level, but incoming calls will never arrive with a higher authentication level than
"CONNECT" (RPC_C_AUTHN_LEVEL_NONE or RPC_C_AUTHN_LEVEL_CONNECT).
After successful authentication, the access check is performed against an access list. The access list is created from default registry values, or provided programmatically via DCOMAccessControl during server initialization. If the access check is successful, the user is granted access to the machine as a whole.
Windows CE contains an implementation of the DCOMAccessControl object which the DCOM runtime uses for all internal security checking. By default, the DCOMAccessControl object is initialized with the contents of the AccessPermission and DefaultAccessPermission registry values. Alternatively, the values can be supplied programmatically through CoInitializeSecurity. User authentication is based on NTLM verification of username/password. A list of users can be used to determine each user's access privileges, as indicated below. Local activations and access requests are always granted. No access check is performed.
Note that unlike Windows NT, the tool that is modifying security settings in the registry must call UpdateDCOMSettings to have DCOMSS reload its configuration. Note that UpdateDCOMSettings is not declared in the standard system header files, so you will need to declare the function in your own header as shown
void UpdateDCOMSettings (void);
and link to the OLE32.LIB.
Also, all DCOM components that are already running must be reloaded for new settings to take effect on them (for example, if a user were to change the LaunchPermission and AccessPermission values for a particular component, and the component had already been launched, it needs to be reloaded for permissions to take effect).
The Load method, which is part of the IPersist interface of the DCOMAccessControl object and is used to load registry information, is implemented differently on Windows CE than it is on other Windows platforms. On Windows CE, the Load method does not sort access according to rules all methods of IAccessControl interface sort access lists. This allows for more fine-grained control of access for users and groups.
Structured storage was added to Windows CE COM in version 2.12 and remains unchanged in version 3.0 for both COM and DCOM.
Windows CE supports the IStorage interfaces, and the data format is compatible with the desktop implementation. However, there is no marshaling support.
In the minimal COM configuration, Windows CE does not support concurrency management. This means that your application is responsible for synchronizing access to various objects. Multiple threads should not access ActiveX controls, which have thread affinity due to their use of thread-specific resources. Because the COM configuration does not support apartment threading, you cannot implement data synchronization with an apartment-threaded singleton. Instead, you must make explicit calls to thread-synchronization primitives to protect member and global data. Note that this restriction does not apply to the DCOM configuration.
In Windows CE, if the ThreadingModel value in the system registry is not set, the threading model defaults to "Free." In the COM implementation, this is not an issue as COM on Windows CE does not support other threading models. However, because the DCOM implementation supports all threading models and interactions between apartments in the same way as Windows NT COM/DCOM, it is essential that your application sets this registry key. In particular, for proxy objects, you must set the ThreadingModel to "Both," meaning that both single- and multi-threaded apartment types are supported. If you fail to do this, and the proxy object is accessed by a thread belonging to a different apartment, the DCOM runtime will attempt to marshal the object, and will fail in the attempt.
Thread/Process Affinity and Protected Server Libraries
The DCOM implementation requires all objects to have thread/process affinity. This means that threads within Protected Server Libraries (PSL) cannot create or access objects or APIs in a DCOM application that require an explicit concurrency model (objects that must be initialized with a call to CoInitializeEx). Specifically, this restriction applies to every callback that the operating system makes to an application, and DLL initialization or termination functions, and any call to a device driver.
DCOM for Windows CE supports TCP/IP and local process communications. If you do not have TCP/IP installed, DCOM will not be able to support cross-machine COM.
As with the desktop version of COM, a thread may call CoCreateInstance or CoGetClassObject to create a new instance of a component. However, under Windows CE, the dwClsContext parameter in those calls must be set to CLSCTX_ INPROC_SERVER.
Effective with version 2.12, you can activate in-process COM objects by specifying CLSCTX_ ALL or CLSCTX_SERVER; earlier versions of Windows CE will return an E_NOTIMPL error if the flag is not explicitly set to CLSCTX_INPROC_SERVER. Additionally, the COSERVERINFO parameter in the call to CoGetClassObject must be NULL since Windows CE COM (the minimal inproc implementation) does not support remote servers.
IClassFactory* pFactory = NULL; ::CoGetClassObject(CLSID_MyObject, CLSCTX_INPROC_SERVER, NULL, IID_ICLASSFACTORY, (LPVOID*) &pFactory); pFactory->CreateInstance(NULL,IID_IMyObject, (LPVOID*) m_pObj);
The DCOM implementation requires that you initialize objects by calling CoInitializeEx before you can use them.
The COM implementation does not enforce object initialization, but it is still recommended that you do so.
Background and conceptual information are available through the following resources:
- 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.
- For information on other COM developer guides, see the Microsoft Press Web site.
- See the "Security Support Provider Interface" chapter of Windows CE Platform Builder documentation for a full discussion of local and pass-through authentication and information of usage and configuration.