Component Object Model: Difference between revisions

Content deleted Content added
History: Split up by dates to improve readability
Line 99:
Microsoft's Windows Runtime (or WinRT, not to be confused with [[Windows RT]]) programming and application model is essentially a COM-based API, although it relies on an enhanced COM. Because of its COM-like basis, Windows Runtime allows relatively easy interfacing from multiple languages, just as COM does, but it is essentially an unmanaged, native API. The API definitions are, however, stored in ".winmd" files, which are encoded in ECMA 335 metadata format, the same [[metadata (CLI)|CLI metadata]] format that .NET uses with a few modifications. This common metadata format allows for significantly less overhead than P/Invoke when WinRT is invoked from .NET applications, and its syntax is much simpler.
 
=== Nano-COM (a.k.a XPCOM) ===
 
{{Main article|XPCOM}}
'''Nano-COM''' is an extremely smalla subset of the Component Object Model that isCOM focused exclusively on the [[Applicationapplication binary interface|Application Binary Interface]] (ABI) aspects of COM that enable function and method calls across independently compiled modules/components. Nano-COM can be expressed easily in a singleportable C++ header file that is portable to all C++ compilers. Nano-COM extends the native ABI of the underlying instruction architecture and OS to add support for typed object references (typical{{endash}} ABIswhereas focusa typical ABI onlyfocuses on atomic types, structures, arrays and function calling conventions). The basis of Nano-COM was used by Mozilla to bootstrap Firefox (called [[XPCOM]]), and is currently in use as the base ABI technology for [[DirectX]]/[[Direct3D]]/[[DirectML]].
 
A Nano-COM header file defines or names at least three types:
* GUID to identify interface types - this is effectively a 128 bit number;
*HRESULT to identify error codes from method calls - this is effectively a standardized usage of 32-bit ints to well known values (S_OK, E_FAIL, E_OUTOFMEMORY, etc);
* IUnknown as the base type for all typed object references - this is effectively abstract virtual functions to support <code>dynamic_cast<T></code>-style acquisition of new interface types and ref counting a la <code>shared_ptr<T>.</code>
 
* GUID {{endash}} identifies an interface type
Many uses of Nano-COM also define two functions to address callee-allocated memory buffers as results
 
* <NanoCom>Alloc – called by method implementations to allocate raw buffers (not objects) that are returned to the caller
* HRESULT {{endash}} method result codes such as S_OK, E_FAIL, E_OUTOFMEMORY
* <NanoCom>Free – called by method callers to free callee-allocated buffers once no longer in use
 
* IUnknown as the{{endash}} base type for all typed object references - this is effectively; abstract virtual functions to support <code>dynamic_cast<T></code>-style acquisition of new interface types and ref counting a la <code>shared_ptr<T>.</code>
 
Many uses of Nano-COM also define two functions to address callee-allocated memory buffers as results:
 
* <NanoCom>Alloc {{endash}} called by method implementations to allocate raw buffers (not objects) that are returned to the caller
 
* <NanoCom>Free {{endash}} called by method callers to free callee-allocated buffers oncewhen no longer in use
 
Some implementations of Nano-COM such as Direct3D eschew the allocator functions and restrict themselves to only use caller-allocated buffers.
 
Nano-COM has no notion of classes, apartments, marshaling, registration, etc. Rather, object references are simply passed across function boundaries and allocated via standard language constructs (e.g., C++ <code>new</code> operator).
 
The basis of Nano-COM was used by Mozilla to bootstrap Firefox (called [[XPCOM]]), and is currently in use as the base ABI technology for [[DirectX]]/[[Direct3D]]/[[DirectML]].
 
==Security==