Why did the original design of COM on Windows rely on the Registry?

Question

In the early 1990s Microsoft introduced COM (Component Object Model) which was widely used in various programming environments including Visual Basic 5 & 6. Also known as ActiveX (or at least if COM & ActiveX are not the same thing they are often conflated).

COM generally required adding information in the Windows Registry so that a program would be able to find & use code packaged into a DLL. e.g., you write a class and compile it into a DLL. But your program wouldn't link directly with that DLL (as was typical beforehand), instead the DLL would be registered on the computer which meant: references to the DLL would be stored in the Windows Registry with a unique ID. Later when a program wanted to use something from that DLL it would look in the Registry for the ID and hopefully find the required DLL from there.

I can certainly imagine that there are scenarios where such referential distancing was useful. However for everyday plain vanilla programs this additional complexity (IMO) turned out to be problematic because the registration information was so easily broken in various circumstances. It also introduced an additional arcane layer which impeded debugging. This motivates my question, because I feel that this would have been an obvious drawback at the time. And yet the designers opted for imposing extra complexity, presumably for a good reason.

Note -- later on, in Windows XP IIRC Microsoft provided an additional file-based mechanism to tie together a program and its COM DLL references that did not require the Registry at all. So it apparently was not strictly necessary to use the Registry-based approach.

Is there any record of the design decisions to make COM work only through the Registry? Of why the more standard simpler approaches of direct linking (static or dynamic) were not used?

Answer 1

At that time, developers at Microsoft were still dreaming the dream of version independent management of libraries, so newer, more powerful libraries could replace older, less powerful or buggy libraries - and best of all, deduplication of code. Think how bad it is today, there were dozens of different Visual C++ runtime libraries are installed on each machine - and now imagine each and every application would bring their own copy of the same library and store it somewhere.

To allow systemwide management of libraries, one needs a unique directory to find linkage information—which can be searched to find relationships to be updated and, in turn, can be changed to integrate replacements on a live system. Application-specific management can't provide this. It would not only limit reuse of DLLs (the primary reason to have them at all), but create masses of duplicates. The prior use of proprietary .INI files (which are how applications stored settings before the Registry) to store such information did create much duplication and undefined behaviour.

It's always important to keep in mind, that your application is neither the only one on the system nor the most important one. It's just that developers acted like it was. Much like back in the early, home computer days, when 'the' application was the single ruler of everything, including the file system. Whoever had the 'chance' of managing office PCs in a corporate setting with quite diverging jobs will still curl up and whimper for the rest of the day when remembering.

While the introduction of the Registry was already a great step forward for Windows in general, it was crucial for COM. COM was intended as the great game changer, allowing reuse of components as often as possible. In this respect, the Registry can be seen as the database of an object broker, needed for runtime linking (late-binding) of services. COM was designed to be quite dynamic; this is something that static linking can't provide. Private management is the absolute opposite of reusability.

In addition, the Registry allowed far more flexible management than throwing these libraries into some DLL path, as was previously done during times of private, application-specific management. From an application point of view, a unique path where the library was 'located' could be used, while the physical location within the file system could just as easily be aliases (which could be handled independently and seamlessly).

Bottom line: It's about reusability and management.

Answer 2

It's great to look back at a technology developed nearly 30 years ago and say "whoa, those are poor design decisions". OLE, and then COM answered questions that were apparent in early Windows. In particular the first thing it attacked was the problem of "DLL Hell" and how to package components from multiple vendors that could be consumed by multiple consumers. VB was a driving force behind these use cases

Then came the OLE (Object Linking and Embedding) scenarios - how to embed an Excel spreadsheet within a Word document.

COM grew from those use cases. In the *Nix world, everyone was jumping on the CORBA bandwagon (the Common Object Request Broker Architecture). Microsoft developed DCOM (distributed COM) as a way to get a much lighter Object-based instantiation and communication mechanism (based on DCE/RPC). If you think COM and the registry are complicated, dig into CORBA.

It's not that COM leveraged the registry. My guess is that if you look back, the registry was invented as a way to provide a central store for OLE (COM's precursor).

Also remember that all this (well, maybe not DCOM) was developed for 16-bit Windows running on Intel 386 PCs. Basing everything on a simple centralized registry and on v-table layouts made for a very lightweight architecture.

That said, Microsoft being Microsoft, the registry became overused and bloated. COM's threading and apartment models became unfathomably complicated. But, it was still very useful.

I was an active Windows programmer in those days. COM answered many vexing questions and really was a great thing back in the late 90s.

Get yourself an old copy of Brockschmidt's book Inside OLE. He explains the innards of COM and a lot of the rationale. Some of Don Box's COM books also provide clear explanations of how it works, but also why things were designed that way.

Answer 3

Short answer: to ensure smooth transition from COM-less OLE 1 to COM-based OLE 2.

---

Slightly longer answer: the foundational use case for COM was OLE2. OLE2, as well as OLE1 before that, was based upon the idea that server applications register themselves in a common repository so that OLE client applications can find them without foreknowledge about the exact nature of the server apps. In other words, OLE was all about dynamic discovery of servers by clients, as opposed to working with a known server. Ergo, the need for a common repository of servers.

---

Now, the long answer.

COM was introduced together with OLE 2. OLE stands for Object Linking and Embedding, and like others said, it was an interprocess communication protocol for embedding pieces of content from one app (the server) in another app's document (the client). It was supported as early as 16-bit Windows 3.1.

Before OLE 2, there was OLE 1. Same business case, different UI paradigm, different underlying mechanism. In OLE 2, the server app would present its UI (e. g. the menu commands) inside the client app's window when the embedded content ("the embedded object") was activated, whereas in OLE 1, upon object activation, the server would have to create and display its own window, and implement a "save and return to the client" functionality to pass the altered piece of content back to the client app.

Anyways. To let users embed an object, the OLE client would usually have an "Insert Object" dialog with a list of available object types (Word document, Excel table, equation, graph, etc.). In order to present said list, OLE had to store them somewhere. Incidentally, those object types would roughly correspond to document types. If there's MS Word on the system, the "Insert Object" dialog presents "Word Document" as one of the choices, etc. Now, here's the crucial bit: even before OLE was around, Windows used the proto-registry (then called "the registration database") to store a list of supported document types. When you double-click, say, on a Word document in File Manager, the logic would take a look at the registry to find out that the .doc extension corresponds to a Word document (the key Word.Document), then figure out that the Word document supports an Open verb and the executable for that is winword.exe, and invoke the latter, passing the file name.

When OLE 1 was introduced, rather than create another tally, they would extend the registration tree for a document type (AKA ProgID) to support indicating the fact that it's embeddable. Some ProgIDs didn't have corresponding file extensions but were embeddable all the same.

OLE 1 was not a general purpose object framework (if there was one, it was well hidden and not documented). In OLE 1, there were only three predefined interfaces, rather than a couple dozen and an infrastructure for defining your own, like in COM/OLE 2. When OLE 2 came, along with a general purpose object framework (i. e. COM), they would extend the registration format even further. That's when the CLSID key first appeared under ProgID. This enabled, among other things, server applications supporting both OLE 1 and OLE 2 side by side.

So applications like Word went from advertising their support for DOC files via the registry, to advertising their support for embedding (via OLE) its documents, to advertising their COM objects. All within the same datastore. In the same key tree, even.

OBTW, the original purpose of the registry - a means to track a document file extension to the EXE path of the host application - still stands to this day.

---

EDIT, to refresh our collective memories. I've downloaded a fresh copy of Windows for Workgroups 3.11 from MSDN, and installed it under DOSBox.

It comes with OLE1 and the registry out of the box. Olecli.dll and olesvr.dll are both present under \Windows\System. Both reg.dat and regedit.exe are present under \Windows. Running regedit /v brings up the tree:

Notably, the Write text editor (a predecessor to WordPad) has an Insert Object command/dialog in it, with three options - Sound, Paintbrush picture, and Package:

There isn't a trace of COM in the system. See how there's no CLSID under SoundRec, even though it's an embeddable object. Instead, there's protocol\StdFileEditing\server, which was the OLE1 way of registering a server. None of the COM libraries (combase.dll, etc.) are under windows\system. CLSID isn't under the registry root.

Same story in Windows 3.1. Unfortunately, MSDN doesn't offer an English version for download. I've got a Russian one to check, it's all the same - OLE1 is present, COM isn't. Windows 3.0 isn't available on MSDN.

Answer 4

Microsoft's COM library storage was a poor use-case, and an even poorer implementation, of what was all the rage in academic computing research around that time - Object Storage. As you have noted, it sounds good in principle, but creates a host of new problems in real-world usage. This resulted in it being somewhat grotesque, in that it provided a "cure" that was worse than the disease.

It should be noted that all the major players experimented with adding object-oriented database features to their filesystems, and it continues until this day. As the volume of data increases, the need for a workable system of metadata to help manage it all also rises. The most successful use-cases are the ones that have developed recently in the Cloud Computing domain, such as AWS S3.

COM was simply an academic experiment turned too early into a shipping product. Naturally, that helped shape the future since it provided a "learning opportunity". Unfortunately much at the expense of hapless users who didn't know they were investing in an experiment.

Answer 5

I worked on some of that stuff at the time.

Microsoft Transaction Server was a big deal and we used it in some major apps. By registering a DLLs interface in the registry, you did not need the physical file on your machine and could call into a library running on another machine. COM/DCOM was basically Microsoft's version of CORBA.

Answer 6

There is no other way to find it. The registry exists for COM. Other things use since Win 95.

A COM server may be already running or on a different computer. There needs to be a way to tell programs where the files are and on what computer.

ActiveX uses COM and is a type of COM server. It was also the marketing name for COM more generally but no longer.

This lists the problems COM solves

Challenges Facing The Software Industry

Constant innovation in computing hardware and software have brought a multitude of powerful and sophisticated applications to users' desktops and across their networks. Yet with such sophistication have come commensurate problems for application developers, software vendors, and users:

• Today's applications are large and complex—they are time-consuming to develop, difficult and costly to maintain, and risky to extend with additional functionality.

• Applications are monolithic—they come prepackaged with a wide range of features but most features cannot be removed, upgraded independently, or replaced with alternatives.

• Applications are not easily integrated—data and functionality of one application are not readily available to other applications, even if the applications are written in the same programming language and running on the same computer.

• Operating systems have a related set of problems. They are not sufficiently modular, and it is difficult to override, upgrade, or replace OS-provided services in a clean and flexible fashion.

• Programming models are inconsistent for no good reason. Even when applications have a facility for cooperating, their services are provided to other applications in a different fashion from the services provided by the operating system or the network. Moreover, programming models vary widely depending on whether the service is coming from a provider in the same address space as the client program (via dynamic linking), from a separate process on the same computer, from the operating system, or from a provider running on a separate computer (or set of cooperating computers) across the network.

In addition, a result of the trends of hardware down-sizing and increasing software complexity is the need for a new style of distributed, client/server, modular and "componentized" computing. This style calls for:

• A generic set of facilities for finding and using service providers (whether provided by the operating system or by applications, or a combination of both), for negotiating capabilities with service providers, and for extending and evolving service providers in a fashion that does not inadvertently break the consumers' earlier versions of those services.

• Use of object-oriented concepts in system and application service architectures to better match the new generation of object-oriented development tools, to manage increasing software complexity through increased modularity, to re-use existing solutions, and to facilitate new designs of more self-sufficient software components.

• Client/server computing to take advantage of, and communicate between, increasingly powerful desktop devices, network servers, and legacy systems.

• Distributed computing to provide a single system image to users and applications and to permit use of services in a networked environment regardless of location, computer architecture, or implementation environment.

Note this is no longer available online and has been replaced by https://docs.microsoft.com/en-us/windows/win32/com/the-component-object-model.

This is the introduction of the draft standards for COM (ver 0.9 October 24, 1995). Copied from MSDN Library October 2001.

Also from Windows 95 Resource Kit introducing the Win95 Registry (Win 3.11 already had a small OLE registry).

Windows 95 Registry

The central information database for Windows 95 is called the Registry. This hierarchical database both simplifies the operating system and makes it more adaptable. The Registry simplifies the operating system by eliminating the need for AUTOEXEC.BAT, CONFIG.SYS, and INI files (except when legacy applications require them). It makes the operating system more adaptable by storing user-specific and configuration-specific information so you can share one computer among multiple users and you can have more than one configuration (such as in-the-office and on-the-road configurations) for each computer.

A primary role of the Registry in Windows 95 is to serve as a central repository for hardware-specific information for use by the hardware detection and Plug and Play system components. Windows 95 maintains information about hardware components and devices that have been identified through an enumeration process in the hierarchical structure of the Registry. (This process is "Configuration Manager" later in this chapter.) When new devices are installed, the system checks the existing configuration in the Registry to determine the hardware resources (for example, IRQs, I/O addresses, DMA channels, and so on) that are not being used, so the new device can be properly configured without conflicting with a device already installed in the system.

Windows 3.1 used initialization (INI) files to store system-specific or application-specific information on the state or configuration of the system. For example, the WIN.INI file stored information about the appearance of the Windows environment, the SYSTEM.INI file stored system-specific information on the hardware and device driver configuration of the system, and various INI files (such as MSMAIL.INI and WINWORD6.INI) stored application-specific information.

The Registry remedies this situation by providing a single location for a computer's configuration information. The following table shows other difficulties or limitations caused by using INI files that are overcome by using the Registry.

Problems using INI files Solutions using the Registry

INI files are text-based, and are limited to 64K in total size. The Registry has no size restriction and can include binary and text values.

Information stored in INI files is non-hierarchical and supports only two levels of information (specifically, section headings with a list of key names under each). The Registry is hierarchically arranged.

Many INI files contain a myriad of switches and entries that are complicated to configure or are used only by operating system components. The Registry contains more standardized values. For more information, see Chapter 6, "Setup Technical Discussion."

INI files provide no mechanism for storing user-specific information, thus making it difficult for multiple users to share a single computer or for users who move around on the network to have access to their user-specific settings. The Hkey_Users key stores user-specific information.

Configuration information in INI files is local to each system, and no API mechanisms are available for remotely managing configuration, thus making it difficult to manage multiple computers. The Registry can be remotely administered and system policies (which are stored as Registry values) can be downloaded from a central server each time a new user logs on. For more information, see Chapter 15, "User Profiles and System Policies," and Chapter 16, "Remote Administration."

When you upgrade from Windows 3.1 to Windows 95, system-specific information such as the static reference to loading virtual device drivers is moved, as appropriate, from the SYSTEM.INI file to the Registry.

For backward compatibility, Windows 95 does not ignore AUTOEXEC.BAT, CONFIG.SYS, and INI files, because many Win16-based applications still use them. For example, Windows 95 allows Win16-based applications to use INI files for the parameters, device drivers, and so on, that the applications need to run. In addition, Windows 95 continues to examine the [386Enh] section of SYSTEM.INI at startup to check for virtual device drivers.

One advantage of the Registry for Win32-based applications is that many of the Win32-based Registry APIs can be used remotely through the remote procedure call (RPC) mechanism in Windows 95 to provide access to Registry information across a network. This means that network administrators can use system management tools to access the contents of the Registry for any computer on the network. (Of course, the remote computer must be configured to allow remote administration, and must have user-level security.)

With Windows 95 remote administration, industry management mechanisms such as Simple Network Management Protocol (SNMP) can easily be integrated into Windows 95, simplifying the management and support burden of the network administrator. For more information, see Chapter 16, "Remote Administration."

Answer 7

To contradict the premise of your question, it was is not always necessary to use the registry in order to use COM.

In-process COM objects are created by loading the DLL which implements them, calling DllGetClassObject (passing the GUID for the object) to obtain a factory object, and calling that factory object's CreateInstance method. If you know the location of the DLL, you can do this yourself without involving the COM registry. But it's easier with the registry.

COM consists of multiple parts:

• An in-process ABI specified in MIDL (derived from DCE RPC). The first released use of this ABI was in the Exchange client, and pre-dated the COM registry services.
• A cross-thread and out-of-process object-oriented remote procedure call system (also derived from DCE RPC). This was first used only for cross-process communication on the same PC, even though MSRPC - based on DCE again - was and is used throughout Windows NT.
• A set of system services to make discovering and loading components easier to use. Some (but not all) of these services involve the registry.
• And of course OLE linking and embedding - this necessarily uses the registry, as it is necessarily to locate servers using symbolic names.

The additional services include:

• Functions for managing "Automation" (BASIC-compatible) types such as BSTR for strings, VARIANT, or SAFEARRAY.
• Convenience functions for instantiating objects without necessarily knowing where or how they are implemented. This uses the registry.
• Conveniences for implementing complex and difficult services for remoting such as proxies and stubs, and the IMarshal interface. These can be hand rolled but more typically these days they are generated dynamically based on type libraries.

Answer 8

COM provides an abstraction layer where you access "components" through "interfaces", and the calling program doesn't need to know whether it is talking to a DLL loaded into its own process, a program, a system service or a remote server.

This allows you to implement components that run at a different permission level than the calling program, a common example is the network configuration widget in the notification area, which runs with the user's privileges but also talks to the network configuration system service, which has the ability to change network stack parameters.

Since the interface only exposes a subset of the privileges the service has, this serves as a simple way to create fine-granular permissions, the same way Unix uses setuid-root programs that can be called by unprivileged users to perform specific actions.

The registry is a list of components that can be "activated" on behalf of programs, so not all components need to be loaded all the time. Some components are rather heavyweight (for example, excel.exe provides an embeddable spreadsheet component).

Conceptually, the registry is not much different from a mailer program providing a /usr/bin/sendmail symlink to be used by programs that want to send mail through a sendmail compatible interface.

The design difference towards other systems is that the Windows world prefers to use components whenever possible, which allows for fairly tight integration of otherwise unrelated programs, but the number of component interfaces made it necessary to organize them.

On Linux, the dbus system provides a similar communications system for components (e.g. network-manager provides an interface to configure network cards, nm-applet uses that interface), and there is a process called "dbus activation" that starts components on-demand by looking up the providing program in a list and invoking it. That components cannot be loaded from DLLs there is an implementation detail, but the registry is no longer a Windows specific phenomenon.

Answer 9

One of the things that I discovered fairly quickly when coming to the Windows environment from a formal UNIX environment was that using the registry was not a good idea for most things. They might have had good intentions with COM, but it created more problems that it solved as far as I was concerned. For any sort of critical software, I would always compile it into a static executable so that I would know that it would run the same each time that I ran it. I did not want to use the runtime DLLs since that might result in the program running differently if there had been an update to them. Sometimes, updates fix bugs, sometimes they add bugs, sometimes they just change the bugs that you have found ways to work around. Having the code compiled statically meant that it would run the same whenever executed. Unfortunately, that was not always possible since sometimes I needed to develop libraries for developers in other languages (e.g. Visual BASIC). For these times, I would create DLLs and they would put the DLL in either their execution path or in the directory that they ran the program from. Sometimes you need to run multiple versions of a program at the same time (e.g. a production version and a new test version).

Answer 10

It is as simple as the problem of drive letters, which Windows has and the other UNIX-like Operating Systems do not: There is no '/' root directory (without specifying a drive-letter prefix, like "C:"), so storing important object information in the same relative location on all machines is not possible. The part of the UNIX '/' directory is played by the Registry in Windows.

COM is dependent on the registry because a specific version of an object needs to be registered in a reliable location that is not as flexible as one prefixed by an old DOS drive letter (remember, Windows was originally a DOS application and it still suffers with what it inherited from DOS to this day).

COM was developed to solve the problem of "DLL Hell," which is quite the ubiquitous topic in forums like this. Short story is: Microsoft solved their own problem with an even bigger problem.