The Case of the Missing Function Pointer

So a couple of entries ago I mentioned I was in the midst of some work on a project when I needed to ensure that a legacy 3rd party COM component would be available for my .NET 2.0 application while retaining an XCOPY style deployment!

How so you say?

Recall from the murky, oh-so-glad-it's-over past that COM components are creatable by CoCreateInstance via a unique identifier (GUID) that has been previously installed into the registry. Many developers who've worked with COM have probably hand-registered a COM component by running regsvr32.exe from the command line shell. It runs and in a couple of seconds displays a friendly message that (if all went well) the component is now registered.

Fewer have actually taken the time to ponder just exactly what regsvr32.exe does. Does it have mystical knowledge of every COM component to know what COM objects it contains and how to properly register them? Fortunately, no, it doesn't. The process to register a COM component is amazingly simple. So simple in fact, we can do the same thing ourselves without resorting to regsvr32.exe.

Every COM component is required to export a standard 'C' function entry point named DllRegisterServer that takes zero parameters. This function is expected to perform any and all registrations that the COM component in question requires. Typically, the vendor writes this function as part of creating the COM objects in the component and many support libraries such as Microsoft ATL automate a great deal of the steps.

Now, if we were writing this as native code in something like C++ or 'C', we'd need to do the following:

1. Call LoadLibrary on the COM component (typically a DLL)
2. Call GetProcAddress(HandleToDll,"DllRegisterServer")
3. Call the function pointer we get back from GetProcAddress

Since languages such as 'C' and C++ support function pointers, this is trivial to implement and works like a charm.

So we advance to the .NET world and find ourselves using the latest evolution of the 'C' dialect family namely C#. C# is one awesome, totally cool and very productive language. But it was designed for the managed world, not the unmanaged/native one that came before. And one of the "features" of the 'C' family that was dropped was the notion of function pointers. 99% of the time, you'd never notice as you happily use a managed variant called delegates. But when working with Native Interop in .NET (like when calling ancient 'C' functions), the lack of function pointers really shows up. And boy does it hurt.

Try as we might, there's no way to force a function pointer out of C#. And no, it's not on Anders' crib sheet for C# 3.0. Now, some might say, "No problem-o, I'll just spike a 'C' DLL that does the call and DllImport that 'C' function into my C# code. Let that 'C' function call the other 'C' function". Hmmm. Works yes, Cool not very.

Hanging on the edge?

Have to wait until next post to find out the finale on this one. Show some code too.

Posted by Mark M. Baker at 11:22 PM  Permalink