Re: difference between a .dll and .ocx????

"Scott M." <s-mar@xxxxxxxxxxxxx> wrote in message
news:Oozi3AdLHHA.320@xxxxxxxxxxxxxxxxxxxxxxx
All .dll's
and .exe's (prior to .NET) as well as .ocx's comform to this standard

That's not true.

How so? If (prior to .NET), you built an .exe or .dll (that runs on
Windows), then it must be a COM library since, that's the architecture
that Windows is built on.

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.

and so, they are all COM libraries. Whether or not they contain
class definitions or just function libraries is actually besides the
point.

That's not true. if a DLL does not expose any COM classes then it cannot
in any way be called a COM library. It's just a DLL.

If it contains a module that, in turn, contains functions, it surely is a
COM library.

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.

[...]
If a DLL doesn't contain class definitions, then it's not a COM
component, simple as that. Most DLLs do not contain COM compoents.

Well, you are now talking about COM components, where as I am talking
about the .dll or .exe adhering to the COM standard.

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


.

Relevant Pages

  • Re: Side-by-side installation on Windows 98SE and Windows 2000
    ... I was surprised to find that this is also supported on Windows 98 ... VB6 cannot create them. ... DLL Search algorithm explores at runtime. ... program (and it's libraries in the app folder) leaves behind a broken COM ...
    (microsoft.public.vb.general.discussion)
  • Re: Side-by-side installation on Windows 98SE and Windows 2000
    ... I was surprised to find that this is also supported on Windows 98 ... I think what it basically comes down to is that DLL/COM Redirection should only be used with COM component libraries that were designed to use it, and VB6 cannot create them. ... However assuming that is true would imply that by registering with a relative path means linkage will occur by using the paths that the Windows DLL Search algorithm explores at runtime. ...
    (microsoft.public.vb.general.discussion)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (alt.lang.asm)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (comp.lang.asm.x86)
  • Re: VC++ endless task
    ... > for accelerations etc befere outputting them back to the controller. ... Windows can be programmed event driven. ... There is only one form of C++, it is defined by the standard. ... The standard libraries are HUGE! ...
    (alt.comp.lang.learn.c-cpp)