When a program is loaded from disk and then begins to run, it usually asks the operating system and other components to perform some work on its behalf, such as reading or writing files, or asking 3rd party software components to do other work on its behalf, such as drawing or rotating 3D objects on the screen.
On a Windows based computer, these external code components that are not part of the primary program running are stored in files with the name “.DLL” appended to the end of the file name. These files have subroutines that other programs can use. Programs that need to use these shared routines load these DLL files from disk at run time (this is the “dynamic” part) and “link” to them, meaning they can then call them after they’re loaded.
A lot of programmers (usually Visual BASIC programmers who don’t have experience outside of Visual BASIC) incorrectly believe that DLL means COM Component. This is because the only type of DLL that can be made with Visual BASIC is a COM component DLL. It’s important to understand that a DLL is simply nothing more than a plain old collection of subroutines packaged together in a single file with “.DLL” appended to the end. There is a standard way to collect the routines in the file though, but a DLL isn’t necessarily a COM component. As a matter of fact, the vast majority of DLLs are NOT COM components. COM components are a special breed of DLL that have much more than just subroutines in them. They also have meta data describing the subroutines, their names, their parameters, etc… and confirm to a very strict specification in order to be a COM component, so that it can be installed, globally, on the machine. Plain old DLLs can’t be installed globally, don’t have the extra meta data, and can simply be copied into a programs folder in order to be used by that program. Plain old DLLs can be copied all over the hard drive and even different versions of them.
This is important to know, because if you’re ever involved with a programmer that only knows the old style Visual BASIC (the one before VB.NET), if you ever say “DLL”, they’re going to think “COM”. And if they ever say “DLL”, they’re going to mean “COM”. Lots of miscommunications can and have happened because of this lack of understanding by VB neophytes. If you hand them a regular DLL, they’re going to try their hardest to “install” it, which can’t be done with regular DLLs. They will likely come to you and tell you there’s something wrong with your DLL. You’ll now understand why they think this and you’ll now be able to educate them.
So, all COM components are DLLs, but not all DLLs are COM components (most DLLs are not COM components).