I read this article and find the concept of Virtual Library Interfaces nice for runtime loading of DLLs. However it seems that they aren't available for Win32. Is this true? And if so: Why? I don't see what would tie the idea to .NET.
EDIT: I'm mostly rephrasing here what Rob already wrote. 🙂
I'm not after plugins or similar – it's about plain old Win32 DLLs. What appeals to me is the idea to let the compiler deal with all the details of loading a DLL at runtime – no need to call GetProcAddress for every function in the DLL etc.
Best Answer
It seems to me like the three answers so far have completely missed the point of your question. That, or I have. You're asking why Win32 Delphi doesn't have something like the magical
Supports
function that Hallvard's article talks about, aren't you? Namely, a function that, given the name of a DLL and the type information of an interface, returns an object that implements that interface using the standalone functions exported from the DLL.Hydra seems to be all about calling .Net code from a Win32 program, not about importing functions from a DLL.
TJvPluginManager
requires that the plug-in DLLs export a special self-registration function that the manager will call when it loads the DLL, and the function must return an instance of theTJvPlugin
class, so the plug-in DLL must be written in Delphi or C++ Builder. TheSupports
function, on the other hand, works with any DLL written in any language. You could use it on kernel32, if you wanted.I don't know why Win32 Delphi doesn't have such a thing. Maybe CodeGear didn't see much demand for it since Delphi and Turbo Pascal had already gone for so long without it.
It's certainly possible to write a function that works like that, and I don't expect it would be any harder to write than the .Net version must have been, unless Microsoft's .Net libraries already provide most of the pieces and Delphi just wraps them up into a convenient-to-call function that looks like the several other overloaded versions of
Supports
that Delphi has had for years.There would be a few steps to implementing that function in Win32. (I'm providing only a sketch of what's necessary because I don't have a running copy of Delphi handy right now. Ask nicely, and maybe I'll find more details.) First, you'd need to make sure that type information for an interface held, at a minimum, the undecorated names of its methods. Then,
Supports
would need to generate a function stub for each method in the interface (besides _AddRef, _Release, and QueryInterface). The stub would go something like this, assuming the calling convention isstdcall
:As
Supports
generated each stub, it would fill in the actual function address, gotten from callingGetProcAddress
with the name of the corresponding interface method. Thestdcall
calling convention is easy to wrap like that;cdecl
is a little cumbersome;register
is a pain in the neck.Once it has all the stubs generated, it would need to generate an "object" that looks like it implements the given interface. It doesn't have to be an actual class. At compile time,
Supports
doesn't know the layout of the interface it's going to be asked to implement, so having a class wouldn't accomplish much.The final step is to provide implementations of the
_AddRef
,_Release
, andQueryInterface
._AddRef
would be unremarkable;_Release
is where you'd callFreeLibrary
when the reference count reached zero;QueryInterface
wouldn't do much at all, except claim that it supportsIUnknown
and the interface given toSupports
.Delphi used to come with a sample program that demonstrated implementing an interface without any classes at all. It was all done with records and function pointers (which is all an interface ultimately is, after all). Delphi also came with the corresponding code to do it with classes, in part to show how much easier Delphi can make things. I can't find the name of the demo program now, but I'm sure it's still around somewhere.