Understanding Objects - How COM objects are built
(Page 3 of 4 )
Now that you understand how to use objects, let’s take a closer look at how COM objects are built. They require a few pieces in order to function properly.
The primary piece is the code base. This is the class itself. Most often these are compiled as either DLL or OCX files depending upon their type. This is the code that defines all of the procedures associated with the class. These are identified using a GUID, or Globally Unique Identifier.
They must also have an interface definition file. This is a sort of manifest file that indicates what the class does and what procedures it exposes. It also identifies the interfaces that can be used to access them. Most often these IDL files are compiled into another type of file known as a Type Library.
Finally, the pieces have to be put into place. In other words, they need to be present on the current system and the operating system needs to know where to find them when needed. This is done through a process known as registering. When a COM object is registered, entries are made in the system registry that define its namespace and the location to the executable files. Some objects can even have their type libraries built at the time they are registered.
A GUID is a long string of hexadecimal characters. While they are human readable, remembering them would be nearly impossible. Due to their length, it’s impractical to even reference them by their GUID outside of registration.
Writing and constructing COM objects is far beyond the scope of this article. I’ve given you a very brief look, but don’t consider this to be totally inclusive. For our purposes, you need to understand that COM objects require installation on the system on which they are being used and that they are identified by a GUID. Most often they will also have a friendlier namespace associated with them as well.
Next: More about objects >>
More Windows Scripting Articles
More By Nilpo
