In the Windows world, what is the correct name for a good. old-fashioned C++ DLL with exported functions? Not a COM DLL, not a .NET DLL. The kind of DLL that we used to invoke by calling LoadLibrary() and GetProcAddress()?
I've always called them "flat DLLs" because the caller cannot instantiate objects from the DLL, but what is the correct name?
EDIT
Thanks for the answers.
Just "DLL" may be technically correct, but where I work everyone assumes that "DLL" means COM, or maybe at a push .NET, so I need a term that distinguishes exactly what I mean.
I always just called them DLLs, but I didn't stay in th C++/VB6 world for too long.
It's a "dynamic link library". Sometimes referred to as a "dynalink library". As opposed to a "static link library", where you choose your own poison. Instead you take the poison du jour, as randomly installed by the user somewhere on the execution path.
A .dll? All those other things use the basic functionality provided by a .dll to do their respective thing. Maybe a raw .dll if you want to be pedantic, but .dll should be fine.
There is no "correct" name anymore that there is a "correct" name for "plain car". (I do use "plain DLLs".
COM DLLs, OCXs, .NET DLLs,... they are all DLLs, with additional features on them. Nothing prevents you from, say, having a DLL that can be accessed both via COM or manual LoadLibrary/GetProcAdress. I've seen it. You can even expose the same object via a "plain" non-objectized API.
May be 'A Regular DLL'. This is the term that we use but 'DLL' works as well.
I agree that there is a need for terminology to describe a DLL that cannot be executed as managed code (in other words requires interop for use by managed code) and that cannot be used as a COM object. Many times developers just say DLL and that is ambiguous. Yes, it is totally valid to call a .Net Class library a DLL and to call a COM in-process server a DLL but for the purpose of communicating it is ambiguous to just say DLL.
See my article Native Windows Dynamic Link Libraries (DLLs) for more.