COM and DCOM in Microsoft Windows CE 3.0
Microsoft Corporation
May 2000
Summary: COM is a platform-independent, object-oriented system for creating binary software components, which can be connected to other COM-based components in different processes on different processes on the same process space or remote machine. COM is based on other Microsoft technologies, such as Active Server Pages (ASP), Automation, ISAPI, and ActiveSync.
This article tells the programming model of COM / DCOM ON Windows CE 3.0 and outlines the differences between COM executed with Windows NT. The basic requirements for reading this article are familiar with COM objects and interfaces, type libraries, understand distributed programming.
Windows CE COM Module
Developers who wish to join the COM runtime can choose COM / DCOM IMPLEMENTATION, which is most in line with their target equipment requirements.
Minimized Implementation Support In-Process Servers (DLLS) process server, Automation Automation, Type Libraries Type Library, Memory Management, Compound Document, and Structure Storage structured storage. Only Free-Threading mode is supported, the application must enhance the means of self-synchronization methods. This Implementation can be effectively used by Windows CE 2.0. Windows CE 2.12 adds support for Microsoft ActiveX® Controls, Idispatch, and Several Automation Data Types.
More rich importation supports in-process and out-of-process servers, remote operation, distributed COM (DCOM), Multi-Threading, and The Apartment Model. Functionally, the same is the same as Microsoft Windows NT® 4.0 WITH Service Pack 5 (SP5). This Implementation can be used by some Windows CE 3.0 OEM-Provided platforms. Unless otherwise stated, "COM" term in this article refers to the original Windows CE Implementation, and "DCOM" refers to the new, more additional functionality. Note that a simple program module overwrites all COM services, regardless of the process, local or remote, the use of the use of the desktop is different from the desktop program.
Finally, application developers should notice that not all Windows CE device platforms include COM runtime support. If you want to check the extent to the COM support for the Windows CE device platform, check out the OEM's SDK documentation.
Automation Automation
Automation (ie Ole Automation) is a technology based on COM-creating ActiveX objects or controls. Limited Automation Support is added to the 2.12 version of Windows CE, which is the same in COM and DCOM IMPLEMENTATIONS.
WINDOWS CE Automation is different from Windows NT Implementation, including the following:
Windows CE Automation only supports In-Process, Free-Threaded Automation objects.
Idispatch interface and many localization Automation types - Variants, Bstrs, SafearRays- is supported. Developers can implement configurations for these types. Because the Windows CE device does not necessarily include a shell, shell interacts (e.g., Drag-and-DROP) is not supported.
How do you write more information about writing an ActiveX control on Windows CE 3.0, see article How to write and use ActiveX Controls for Windows CE 3.0.
OLE Mixed Documentation
COM and DCOM support mixed documents. In addition, since the Windows CE device may not include a shell, there is no support interaction, such as menu menu, or Drag-and-DROP operation.
Security security
When performing a distributed program, there are two security levels.
Network security reference Who can access this computer.
What can I do after the local security references the user to log in.
Different local security controls in Windows CEs, it will access control and emergency system components as a whole, better than a resource based on Windows NT.
On Windows NT, when a user automated is connected to an object, the SECURITY CREDENTIALS running the object is a user count that connects the client, interactive user or clear specified user, which can be programmed or in the registry (for example Through DCMCNFG). The subject is obtained in the process (call "impersonation") to control the access system resources. Because Windows CE does not provide access control mechanisms for individual objects, Impersonation is not supported, and the server can access all system resources (except for Windows CE Trust Level Protection).
On Windows CE, DCOM security checks have two steps: Authentication and access.
Authentication verification
Authentication is done by NTLM when an object is connected to a server. A DCOM object on a Windows CE can be called at any Authentication level, but the incomed call cannot reach a higher authentication level.
"Connect" (RPC_C_AUTHN_LEVEL_NONE
OR RPC_C_AUTHN_LEVEL_CONNECT).
After successful Authentication, the access check relies on an access list being executed. This access list is created by the default registry key value, or programming through DComAccessControl when the server is initialized. If the access check is successful, the user is allowed to access the entire machine.
Access Control Access Control
Windows CE contains an instance of a DComAccessControl object that uses all intrinsic security checks when DCOM runtime. Typically, the DCOMACCESSCONTROL object is initialized by the structure of AccessPermission and the DefaultAccessPermission registry key value. Alternatively, this value can be programmed via CoinitializeSecurity. User Authentication is NTLM-based username / password verification. A user list can be used to determine access to each user, which will be specifically described below. Local activation and access requests are always permitted. No access check is executed.
Note that Windows NT is different, modifying the security settings in the registry must call UpdatedComSettings to update their settings. Note that UpdatedComSettings is not declared in the standard system header file, so you need to declare this function in your own header file, as follows, void updatedcomsettings (void);
And connect OLE32.LIB.
Similarly, all running DCOM components must be reloaded, new settings have an impact on them (for example, if a user changes a component LaunchPermission and AccessPermission values, and this component has been loaded, it will be reloaded to take effect) .
The LOAD method of the DCOMACCESSCONTROL object IPERSIST interface is used to load registry information, which is different on Windows CEs and other Windows platforms. On Windows CE, the LOAD method classification access is not based on the rules of access to the IACcessControl interface method. This allows for more Fine-grained control to be accessed by users and groups.
Structured Storage Structured Storage
Structured Storage is added to Windows CE COM in version 2.12, and there is no change in COM and DCOM 3.0.
Windows CE supports iStorage interface, data format, and desktop execution are consistent. However, no configuration is configured.
Threads and processes threads and processes
In minimizing COM configuration, Windows CE does not support Concurrency management. This means that your application is responsible for the different objects for synchronous access. Multi-threads will not access ActiveX controls, and their close relationships of threads should be attributed to the Thread-Specific resources they use. Because the COM structure does not support the threaded suit, you cannot achieve data synchronization within a separate thread suite. You must call simple Thread-synchronization to protect members and global data. Note that this limit does not apply to the DCOM structure.
In Windows CE, if ThreadingModel's value is not set in the system registry, the thread mode defaults to "free". In COM execution, the COM version on Windows CE does not support other thread modes. However, because DCOM performs supporting all thread modes, uses the same way in the same way in Windows NT COM / DCOM to interact in the suite, and your application sets the registry key value is the key. Special, if you have a proxy object, you have to set ThreadingModel to "Both", meaning SINGLE- and MULTI-Threaded two sets of socket types support. If the creation fails, the agent object accesses the different sockets through a thread property, and the DCOM will try to configure this object and configure failed.
DCOM execution requires all objects to have Thread / Process Affinity. This means that the thread in Protected Server Libraries (PSL) cannot create or access objects or APIs in a DCOM application, which requires an external ConcURRENCY mode (object must call CoinitializeEx to initialize). It should be clear that this restriction applies to any operating system callback to an application, and the DLL initialization or termination function, and any request for the driver.
Transport Protocols Transfer Protocol
DCOM for Windows CE supports TCP / IP and local process communication. If you don't have TCP / IP, DCOM will not support Cross-Machine COM.
As a desktop version, a thread can call CocreateInstance or COGETClassObject to create a new component instance. However, under Windows CE, the DWCLSCONText attributes in these calls must be set to CLSCTX_ Inproc_server. In version 2.12, you can activate the COM object in the process by specifying CLSCTX_ all or ClsctX_Server; Windows CE earlier, if this flag is not specified as CLSCTX_INPROC_SERVER, an E_NOTIMPL error will be returned. In addition, the COSERVERINFO attribute when calling COGETCLASSObject must be NULL because the remote server is not supported by Windows CE COM.
IclassFactory * pfactory = null;
:: CogetherClassObject (CLSID_MYOBJECT,
CLSCTX_INPROC_SERVER, NULL,
IID_ICLASSFAACTORY, (LPVOID *)
& pfactory);
Pfactory-> CreateInstance (NULL, IID_IMYOBJECT,
(LPVOID *) m_pobj);
Before initializing them, DCOM executes you to initialize the object by calling CoinitializeEx.
COM executes not forcing execution object initialization, but this is still recommended.
For more information more information
The background and conceptual knowledge can be obtained by 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.
Other COM Developer Guide, you can view Microsoft Press Web.
View Windows CE Platform Builder Document "Security Support Provider Interface", with information on the full discussion and use and configuration of local and pass-throughs.
