Game Development Reference
Microsoft .NET is a powerful platform to develop on, but unfortunately, it is not
yet a native part of Windows. Most applications are still unmanaged, and while
interaction between managed and unmanaged application is possible, managed
and unmanaged applications remain in their own independent worlds.
Windows Explorer is an unmanaged application that cannot differentiate between
a managed application and an unmanaged application. Explorer only understands
how to load COM interfaces, so there is no special base class we can inherit from;
we have to do things the messy way. Shell extensions can be written in a managed
language like C#, but the component must be visible as a COM object and employ
a proxy that the shell can understand. Supposedly, Windows Vista (Longhorn)
provides a variety of managed mechanisms, but our current operating systems do
not work like that.
In this chapter, you will learn how to create a shell extension, and register it with
the Windows shell as a standalone assembly, or integrated within an application.
The first step is to import the native structures, interfaces, types, and methods that
we require in order to build our shell extension.
Every COM interface is associated with a unique GUID (Globally Unique Identifier),
and is a required attribute to specify when importing a COM interface in a .NET
application. When importing a COM interface, you must specify the correct GUID
for the interface as defined in the Win32 registry. Additionally, you must also spec-
ify the interface type to determine how the interface is exposed to COM callers.
The different interface types available are described in Table 41.1.
Table 41.1 Enumerated Types for ComInterfaceType
COM Interface Type
Exposes an interface as a dual interface, supporting both
early and late binding.
Exposes an interface that is derived from IUnknown ,
supporting only early binding.
Exposes an interface that is a dispinterface , supporting
only late binding.