Marshaling Support (Windows Embedded CE 6.0)
1/6/2010
A Component Object Model (COM) interface can be marshaled using standard marshaling or custom marshaling:
- In standard marshaling, proxy and stub code marshals and unmarshals the parameters and return values of an interface method call between processes. The Microsoft Interface Definition Language (MIDL) compiler can be used to generate proxy and stub codes for standard marshaling a COM interface.
- In custom marshaling, the object implements the IMarshal interface to marshal the object to another process space. For more information about custom marshaling, see the COM specification in the Microsoft MSDN® Library under Specifications and Chapter 6 of Kraig Brockschmidt's Inside OLE, Second Edition in the MSDN Library under Books.
Automation marshaler is also known as type library marshaler or universal marshaler. This marshaler allows marshaling based on an interface's type library, which means the interface does not need to have a proxy and a stub.
Note
Automation marshaler is not supported.
Interfaces require a proxy and a stub for marshaling.
Windows Embedded CE provides an implementation of IDispatchProxy when the DCOM Catalog item is included.
Note
Distributed COM (DCOM), sometimes also referred to as "COM Remoting", is not included in Windows Embedded CE. Please see Remote DCOM Support for more information.
For applications, IDispatchProxy automatically and transparently marshals variants across interfaces.
The marshaler provided by Windows Embedded CE provides only one level of redirection, that is, references to references of variants are not allowed.
Support for IDispatchProxy allows applications written in Visual Basic on the desktop to call remote COM servers running on a Windows Embedded CE device.
IDispatchProxy is not the same as Automation marshaler.