INTEROPERATING WITH C AND COM in VB.NET

Printing Data Matrix 2d barcode in VB.NET INTEROPERATING WITH C AND COM

Reflection: The component description available at runtime allows programs to deal with unknown components. This is especially important for programs featuring scripting environments, as witnessed by the widespread use of IDispatch and type libraries in COM.

COM components are compiled modules that conform to well-defined protocols designed to allow binary interoperability among different languages. An essential trait of component architectures is the ability to dynamically create components at runtime. It s necessary for an infrastructure to locate and inspect components in order to find and load them. The Windows registry holds this information, which is why it s such an important structure in the operating system. The HKEY_CLASSES_ROOT registry key holds the definition of all the components installed on the local computer. It s helpful to understand the basic layout of the registry in this respect when you re dealing with COM components. The following is a simple script in JScript, executed2 by the Windows Scripting Host, which is an interpreter used to execute Visual Basic and JScript scripts on Windows:

w = WScript.CreateObject("Word.Application"); w.Visible = true; WScript.Echo("Press OK to close Word"); w.Quit();

This simple script creates an instance of a Microsoft Word application and shows its window programmatically by setting the Visible property to true. Assuming that the script is executed using the wscript command (the default), its execution is stopped until the message box displayed by the Echo method is closed, and then Word is closed. How can the COM infrastructure dynamically locate the Word component and load it without prior knowledge about it The COM infrastructure is accessed through the ubiquitous CreateObject method, which accepts as input a string containing the program ID of the COM component to be loaded. This is the human-readable name of the component; but the COM infrastructure was conceived as a foundation of a potentially large number of components and therefore adopted globally unique identifier (GUID) strings to define components. GUIDs are often displayed during software installation and are familiar for their mysterious syntax of a sequence of hexadecimal digits enclosed in curly braces. GUIDs are also used to identify COM classes; these IDs are known as CLSIDs and are stored in the Windows registry as subkeys containing further metadata about the COM object. When CreateObject is invoked, the code infrastructure looks for the key:

The default value for the key in this example (on one of our computers) is as follows:

{000209FF-0000-0000-C000-000000000046}

Now, you can access the registry key defining the COM component and find all the information relative to the component. The following screenshot shows the content of the LocalServer32 subkey, which says

2 To execute the script, save the text in a file with .js extension (for instance, StartWord.js) and then double-click the Windows Explorer icon.

that winword.exe is the container of the Word.Application component. If a COM component should be executed in a process different from that of the creator, LocalServer32 contains the location of the executable. Components are often loaded in-process in the form of a DLL; in this case, the InprocServer32 key indicates the location of the library.

To get a feel for the number of COM components installed on a Windows system, you can use a few lines of F# using fsi.exe as a shell:

> open Microsoft.Win32;; > let k = Registry.ClassesRoot.OpenSubKey("CLSID");; val k : RegistryKey > k.GetSubKeyNames().Length;; val it : int = 9237 > k.Close();; val it : unit = ()

The registry is also responsible for storing information (that is, the metadata associated with COM components that describes their interfaces) about type libraries. Type libraries are also described using registry entries and identified by GUIDs available under the registry key: