How Components Are Made Available

OK, we’ve had an example of using a component from ASP, and we’ve talked about some of the ways we can think about categorizing the components we’re going to build. Despite that, what we’ve yet to do is establish exactly how components are made available to our client code. You know that components are stored in DLL and EXE files, but there have been no references to those in the code you’ve seen so far. There must be another mechanism in operation.

The first questions to ask are: How do we know how to reference the component that we want? Where do applications get the information about components? The answer to both these questions lies in the system registry (often known simply as “the registry”). The registry currently plays a lead role in the world of COM. It’s a hierarchical data store that’s used to hold COM-related information and lots more.

The role of the registry with COM+ in Windows 2000 has changed slightly; the general concept of having a ‘central repository’ for component information is the same, but the registry is no longer that repository, except for legacy components.

Generally, applications don’t access the registry directly for the COM information they need. Instead, they use some Application Programming Interface (API) functions provided by COM that encapsulate its usage. To take a closer look at the registry, run the registry editor program Regedit.exe (just choose Run… from the Start menu and type Regedit). When it starts, you’ll see a number of keys:

       (Page 2)

COM information is stored under the HKEY_CLASSES_ROOT key. We won’t discuss the registry editor or the various keys in detail here, but feel free to have a look around it when you have a spare moment.

Looking around is fine, but never change anything in the registry unless you know exactly what you’re doing. The registry holds a lot of information that’s used by the Windows operating system. If you accidentally change something important, it’s possible to render your computer unusable.

If you expand the HKEY_CLASSES_ROOT key, you’ll find a number of interesting sub-keys. Those of interest are shown here:

       (Page 2)

Most of the COM components installed on your machine will be listed under the key HKEY_CLASSES_ROOTCLSID, where you’ll find a large number of sub-keys whose names are all CLSIDs of the form you saw earlier. There will a sub-key for every component registered on your machine. As we’ve explained, these identifiers are the actual names of your components, and each sub-key stores information about the component whose name it bears. One of these pieces of information is the location of the server that contains the component, and it’s by this means that components are found and subsequently instantiated on request.

When your client is compiled (if, for example, it’s a Visual Basic or a Visual C++ application), the CLSIDs of the components it uses are generally “hard-wired” into the code. This means that if the CLSID of the component it uses should change, the client will no longer work.

However, in our Brick Calculator example, when we created the component instance within the ASP page, we did not use the CLSID to reference the component. Instead, we used the programmatic identifier, or ProgID.

Programmatic Identifiers

In our first example of using a component in an ASP page, we created an instance of the component like this:

Dim objBrickCalc
Set objBrickCalc = Server.CreateObject("BrickCalc.wsc")

When you create a class module in Visual Basic, it generates a ProgID for you, in the form:


At the end of this chapter, we’ll build the Windows Script Component using the Wizard provided by Microsoft. There, you’ll see that WSCs store the ProgID in the same file as the rest of the component’s implementation:


As the next screenshot shows, ProgIDs are also sub-keys under HKEY_CLASSES_ROOT. They provide a way of looking up a CLSID at runtime from a “friendly” string identifier. Using the Brick Calculator component as an example, we can see that the ProgID key has a sub-key called CLSID. This has a Default string value that contains the GUID in string format:

       (Page 2)

Whether you use ProgIDs or CLSIDs to call your component from ASP is up to you. While CLSIDs are less easy to write and less logical to read than ProgIDs, they do ensure that (in the unlikely event that there is a component with the same name and method as the one you are calling) you get the correct method of the correct component.

The COM Runtime

An important part of the COM is the COM runtime, which provides the API functions that enable applications use to create and manipulate COM objects. As ASP programmers, we don’t really see the COM runtime, but functions like the Server object’s CreateObject() method are layers upon it. If you asked ten C++ programmers to name a COM runtime API, you’d probably find 99% of them would say CoCreateInstance() or CoCreateInstanceEx(). These APIs are responsible for the creation of COM objects – they are the equivalent of CreateObject() in ASP. The COM runtime is a large topic, and we will not be covering it in depth here.

There is a lot more to learn about COM in general, but both ASP and Visual Basic make COM very easy to work with. While we could introduce all manner of topics to help you understand what is going on under the hood, the ASP and Visual Basic environments are designed to hide much of the complexity from you until you’re at a stage when you really need to dig into the inner workings. We will be looking into COM more deeply in the section on C++, starting in Chapter 10, but what you have seen so far is enough to get you used to building components and using them in your ASP pages.

Will Microsoft Replace COM?

Unlike a lot of Microsoft technologies, COM has a fairly stable history that can be tracked back long before the official release in 1993. Since its release, COM has slowly evolved, but this has largely involved additional features such as security and the ability to call up components on different computers. There have been no major architecture changes.

COM has a solid future. These days, almost every new technology that Microsoft introduces is based to some extent – and in some cases entirely – on COM. This is true for all the technologies we will be examining in this book – ADO, MTS, MSMQ ADSI, and OLE DB. All the Microsoft Office components expose COM interfaces, as does Internet Explorer. The next version of COM, known as COM+, already has a pivotal role in Windows 2000, so you can rest assured it is here to stay. There are some big changes between COM and COM+, but nothing that invalidates or outdates the code that we will be writing in this book.