I was exploring use of the COM type library marshaller as an alternative to a MIDL-generated marshaller a while back (as mentioned on the bottom of my earlier COM post). The type library marshaller, like the rest of COM, is usually inclined towards registration (you specify the TypeLib for an interface in the registry to let COM know how to marshal it and specify the marshaller’s GUID as the ProxyStubClsid32 instead of some MIDL generated class in your custom DLL) – but can actually be used quite comfortably without it. In my search for a solution I stumbled upon Don Box’s old MSJ article that provides a rather exhaustive description of the whole deal. Evidently, the TypeLib entry in the registry is just an accessory and the interesting part is actually the rpcrt4.dll function duo, CreateProxyFromTypeInfo and CreateStubFromTypeInfo.
These APIs receive an ITypeLib reference and use the binary type information to synthesize an /Oicf style marshaller, dynamically. It is quite a feat. Consider the possibilities. An application could marshal arbitrary interface references and not be bound just to a known subset for which it has proxy/stub implementations statically linked. Microsoft recognized how messy linking a MIDL generated proxy/stub factory to a non-C++ project can be and included the Marshaler sample in the .NET 1.1 SDK. This is a C# sample that uses P/Invoke to the type library marshaller and thus avoids MIDL integration. When I looked over the sample, I was amazed to see it use the undocumented, underground CreateProxyFromTypeInfo and CreateStubFromTypeInfo APIs with not even a sign of apology.
As I later found out, I was simply fortunate to happen to be on a machine with the old .NET 1.1 SDK installed. The sample, along with others, has simply disappeared from the .NET 2.0 SDK and its successor, the Windows SDK. Unlike what one may expect, it hasn’t been replaced by anything similar that illustrates what it meant to.
Unfortunately, this is merely one case in a series of disappearing acts by Microsoft SDK samples. As I was exploring the use of RPC as an alternative to the more heavyweight COM, I looked for an SDK sample on the memory allocation and free semantics of [in, out] parameters in MIDL-generated RPC stubs. I found a list of the RPC samples in this MSDN page and figured the listed DYNOUT sample was exactly what I needed. Unfortunately, this time I was on a machine with only the latest Windows SDK installed. A search through Samples\NetDs\rpc quickly resulted in disappointment as the sample was obviously gone forever. This time, unlike the Marshaler sample case, there didn’t seem to be an obvious reason for the sample’s demise. I was able to scramble the answer for what I was looking for through a combination of trial-and-error and examination of those samples that did remain. It remains unclear why the now-defunct sample remains listed in MSDN.
Another trigger for filing a Missing Sample’s Report with the authorities was given to me the other day when a friend asked me about a WMI client sample. This one was a part of the Windows Server 2oo3 DDK but was, again, mysteriously absent from the new Windows Driver Kit. Considering the WDK and its huge DVD contains just about anything (so much that Microsoft decided to trim it down back to ~700MB by refactoring out the Windows Logo testing stuff, etc.) it seems bizarre that this sample of all things would be cut out.
If the motivation for the removal of these and other samples is some sort of quality bar (like the highly unwelcome removal of the trusty Dependency Walker from the Windows SDK because it doesn’t meet some sort of “quality” guideline) then it seems to me the cure is far worse than the disease. A poor sample is better than no sample at all, except perhaps when it comes to security, which doesn’t seem to be the case here. The disappearance of samples is a great disservice to users of the various SDKs.