You are basing your conclusion on false assumptions.  Windows is NOT built
solely on COM, nor would the architecture on which Windows is built
necessarily define what some .exe or .dll not part of Windows (even if it
runs on Windows) is or is not.

The main difference between a .exe and a .dll is that the .exe is entirely
self-contained with a well-defined entry point where a program can start
executing.  There have been .exe files since long before Windows.  A .dll
also has a well-defined entry point, but it doesn't define where execution
of a program begins...instead, it's a function that is called when the DLL
is loaded (there are also special functions called when the DLL is unloaded
and for other events).

Other than these few special functions (which have nothing to do with COM),
a DLL is not required to implement anything else.  It always does, of
course, since otherwise it wouldn't be useful.  But what it does implement
is up to the person authoring the DLL.  Most DLLs are simply a collection of
useful functions.  For example, the Visual Studio C runtime library, which
is very much like a statically-linked CRT except that it can be shared by
all the various executables that use it.  It has nothing to do with COM, and
it is not a COM library.

There is no requirement for a DLL to support the specification required by a
COM object, and a great many DLLs do NOT implement COM objects.
Furthermore, just as EXE files have been around for much longer than Windows
has, Windows itself has been around much longer than COM has been.  There is
still a lot in Windows that has absolutely nothing to do with COM, even the
parts of Windows implemented in DLLs.

It is not.  A DLL that does not contain the requisite "factory" API and
which does not implement the other necessary elements of COM is NOT a COM
library.  How could it be?

If the definition of "COM library" was "a module that contains functions",
you'd be right.  But that's not what a COM library is, and so your
conclusion is simply wrong.

Frankly, I find it a bit confusing that you could understand the concept of
a DLL adhering to the COM standard, without understand that a DLL need not
adhere to the COM standard.  If there is a standard that a DLL may adhere
to, rather than simply being a DLL, doesn't it also logically follow that
there may be DLLs that do not adhere to that standard, and thus are not in
the category of components that DO adhere to that standard?

Pete

It's nearly true.  MSFT re-defined exactly what an Active-X control a few
times with the final defintion being basically "any self-registering
in-process COM server".

-cd