For example, the earliest occurence of this in the series was with Audio, where we called GetProcAddress to get DirectSoundCreate but we didn't call it to get SetFormat. Is this a weird COM idiosyncrasy, where it maps member functions to the correct addresses in the DLL for you...

COM objects are structs with a built in virtual function table which is filled in by the library. This means that the getProcAddress bits are done for you.

so to instantiate all the COM methods we only need to call its create function, and it'll fill out the vtable itself? so we only ever have to GetProcAddress one function?

exactly.

It's a common pattern with COM, a single stand along function to create the first COM object and everything else is through the vtables of the COM objects

Another common pattern with COM objects is CoCreateInstance function. COM objects are registered in system special registry. And they can be created if you know their class ID.

Here's example code for WASAPI: https://docs.microsoft.com/en-us/...ktop/coreaudio/rendering-a-stream
See how IMMDeviceEnumerator object (pEnumerator) is created by calling CoCreateInstance and passing its class id value - CLSID_MMDeviceEnumerator. No need for GetProcAddress or linking to dll file at all.

this is a really interesting post; never thought about this. so does it essentially search the registry for the dll with the code, and what functions it contains, then uses that information to populate the object's vtable with pointers into the right places within the dll?

Yes, something like that.