COM and DCOM in Microsoft Windows CE 3.0

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

  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 IDispatchinterface, 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.

    OLE Compound Documents

    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.

    Security

    There are two levels of security to consider when implementing a distributed application.

    • Network securityrefers to who can access a computer.
    • Local securityrefers 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.

      Authentication

      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 DCOMAccessControlduring server initialization. If the access check is successful, the user is granted access to the machine as a whole.

      Access Control

      Windows CE contains an implementation of the DCOMAccessControlobject which the DCOM runtime uses for all internal security checking. By default, the DCOMAccessControlobject is initialized with the contents of the AccessPermissionand DefaultAccessPermissionregistry 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 UpdateDCOMSettingsto have DCOMSS reload its configuration. Note that UpdateDCOMSettingsis 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 LaunchPermissionand AccessPermissionvalues for a particular component, and the component had already been launched, it needs to be reloaded for permissions to take effect).

      The Loadmethod, which is part of the IPersistinterface of the DCOMAccessControlobject and is used to load registry information, is implemented differently on Windows CE than it is on other Windows platforms. On Windows CE, the Loadmethod does not sort access according to rules all methods of IAccessControlinterface sort access lists. This allows for more fine-grained control of access for users and groups.

      Structured Storage

      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 IStorageinterfaces, and the data format is compatible with the desktop implementation. However, there is no marshaling support.

      Threads and Processes

      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 ThreadingModelvalue 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 ThreadingModelto "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.

      Transport Protocols

      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.

      Using COM Objects in Windows CE

      As with the desktop version of COM, a thread may call CoCreateInstanceor CoGetClassObjectto create a new instance of a component. However, under Windows CE, the dwClsContextparameter 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 CoGetClassObjectmust 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);

      Initializing Objects

      The DCOM implementation requires that you initialize objects by calling CoInitializeExbefore you can use them.

      The COM implementation does not enforce object initialization, but it is still recommended that you do so.

      For More Information

      Background and conceptual information are available through the following resources:

      • On MSDN, see Platform SDK, Component Services, COM section.
      • The Pocket PCWeb site.
      • The Windows-Powered Mobile DevicesWeb site.
      • Rogerson, Dale. Inside COM.Redmond, WA: Microsoft Press, 1996.
      • For information on other COM developer guides, see the Microsoft PressWeb 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.
        
        

        ---

        © 2004 Microsoft Corporation. All rights reserved.