>>>Guess the ultimate answer is that we will never know how the VFPCOM crosses the COM boundries.
>>
>>Hogwash. :-) We just have to ask the right person. I'll corner somebody at the next DevCon.
>
>Perhaps JVP will not or cannot say how it's done, because he's under NDA about the details. It's pretty obvious that he had a hand in either writing or documenting VFPCOM, or maybe both.

Documenting, maybe, but I doubt it, and writing it, no. It was written by the VFP team. Anyway, I don't think this sort of thing is what is usually protected by an NDA.

I have a vague idea-

a COM object lives in a dll. All it is is a set of functions, and properties that are accessible by programs that know how to talk to a library through the COM interface- that is using the IDispatch interface to find the addresses of the named functions.

But a dll can also host other functions that don't have to adhere to the COM spec, and VFP does provide hooks into its environment to allow external libraries to call VFP API functions. This is exactly what an fll does. All an fll is, is a dll that knows the names of available VFP API functions, and how to call them. I strongly suspect that VFPCOM.dll hosts both the VFPCOM.COMUtil object, and a set of functions that work like an fll does, calling VFP API functions.