22

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?

  • 10
    COM never required that classes be registered. You could always implement your own method of creating COM objects, for example by loading a DLL and calling a certain function in it. That's how DirectX normally works. – Ross Ridge May 4 at 17:23
  • 3
    A DLL without exported symbols is pretty useless, so the certain function would be exported just like any function that's meant to be called from outside the DLL. A game using DirectDraw would normally link with DDRAW.DLL and call the exported function DirectDrawCreate to create a DirectDraw COM object. docs.microsoft.com/en-us/windows/win32/api/ddraw/… – Ross Ridge May 4 at 17:42
  • 12
    COM wasn't only about using code packaged in a DLL, it could also be used to call code that was part of an already-running process (i.e. an EXE). Since you can't link your process to another, because they must necessarily have distinct address spaces, you need some kind of directory that allows those calls to be resolved by the marshaler. The registry worked fine for this. Used this way, COM was a dramatic improvement over DDE, allowing you to issue remote procedure calls to other running processes. dynamic linking of a DLL is just the 'easy' case of a larger more general mechanism. – Ken Gober May 4 at 20:43
  • 3
    COM precedes the Windows Registry by several years. – user207421 May 5 at 6:05
  • 1
    I vaguely recall that it was actually sufficient to export a DllGetClassObject function from your DLL to enable any COM-aware client to load your DLL and instantiate the COM objects within. The role of the registry was rather "grand central service locator" for any COM objects their authors wanted to make publicly available (e.g. for automation / scripting purposes). It's rather many development tools of the time as well as tutorials for beginners both were kind of making registering COM objects in the registry "the norm". – DmytroL May 5 at 7:25

10 Answers 10

33

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.

| improve this answer | |
  • 7
    Sounds to me like the registry is used in a similar way like symlinks are used on *NIX-systems with dynamic libraries, right? (On *nix, you often have something like libfoo.so.1.2.3 and then symlinks libfoo.so.1 and libfoo.so.1.2 pointing to it; app links to libfoo.so.1 and the library can then be updated without breaking the app.) – DarkDust May 4 at 16:09
  • 2
    @DarkDust Well, yes, as long as it's only about finding a component direct by replacement of a path, it's quite like symlinks. But the registry also allowed to add other meta information as well, allowing the linkage component to pick the right replacement at runtime, as well as management of components (COM DLL were meant as reusable components), privileges and so on. In this degree it's like the catalog system on some mainframes, which held metadata beyond what the file headers on a device provided. – Raffzahn May 4 at 19:49
  • 5
    The classic case that COM and the registry fixed was a VB DLL known as threed.dll (pronounced 3-d). It originally shipped with VB, then Office developed a version or three, and then there were others. There was no rhyme or reason to the the versioning. Each version was neither backwards nor forwards compatible with any other version. You'd have a wonderfully functional PC and your kid would install a game and suddenly Excel and Word would crash. It was fun. OLE (COM's predecessor) and the registry went a long way towards fixing that issue. – Flydog57 May 5 at 3:51
  • 5
    You only have to look at the history of Windows Applications before introduction of the registry .. every application brought along its "own" set of DLL - and still it was mostly the same set with slight variances .. worse some applications relied on a specific version of dll where the manufacturer of said dll often removed functions or repurposed them - which created incompatible environments - which led the devs to give the applications a "working set" along. Thus artificially inflating the installed application. And diskspace was easily more expensive than nowadays – eagle275 May 5 at 10:15
  • 6
    "unlike today, there were dozens of different Visual C++ runtime libraries are installed on each machine" - I can't tell from the mixed tenses here whether you are saying there were dozens (in the past) or there are dozens (today). I suggest rewording slightly. – JBentley May 5 at 12:36
15

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 unfathomly 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.

| improve this answer | |
  • OLE was preceded by DDE; DCOM was preceded by NetDDE. – MSalters May 5 at 11:41
  • 1
    The original registry was a single 64 kiB file. Exactly like you said, it was made for COM, not used by COM. Heck, that's why it is called "registry" - it was a registry of COM objects, nothing more. Over time, everyone started using the registry as a kitchen sink for various configuration and such, for better and worse. – Luaan May 7 at 11:00
  • 2
    The registry was NOT made for COM. It was not even made for OLE1. It was made for File Manager (and a handful of third party shells), as a means of tracking file extensions to their host applications. Then repurposed for OLE 1 (before COM). Then repurposed for COM (which was the base for OLE 2). – Seva Alekseyev May 7 at 19:21
  • Followup: see the screenshot in my answer below. – Seva Alekseyev May 11 at 0:14
10

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.

| improve this answer | |
  • 8
    COM really didn't address "Object Storage" at all (and I'm speaking as a guy who wrote COM enabled systems that used Object oriented databases in the 90s). By the early 90s, the advantages of object-oriented programming were becoming apparent. There was an urge to expand "object-oriented" into more realms. Both COM and CORBA provide a way to create distributed object systems. They seemed like a good idea a the time. The problem was that they encouraged deep coupling between independent things. That was obvious eventually, but not when they were designed. Life's like that sometimes. – Flydog57 May 5 at 4:15
  • 2
    @Flydog57 Coupling also wasn't considered so bad when releases were few and far between, and you could have multiple (out-of-process) COM object versions running at the same time. Not to mention there was less coupling than with DLL linking anyway (and "modern" interops are usually more coupled, rather than less, too). But regardless, COM is great. It allowed ridiculous levels of interoperation between wildly different systems, it opened cross-language interop at a far higher level than C functions. Heck, .NET was originally called COM 2.0, because that's what it was supposed to do. – Luaan May 5 at 7:57
  • 6
    COM didnt have anything to do with object storage. It was about the desirability of plugin architectures in desktop applications, being able to dynamically bind at runtime to something like OOP objects, like how you can cut-and-paste a kitchen sink into a Microsoft Word document and turn the faucets and it will run water. – jwezorek May 6 at 15:45
  • @Flydog57 Re-reading the question, I see it is still about how COM object metadata is stored, and not about COM as a programming framework. – Brian H May 6 at 16:23
  • 2
    @BrianH It's not about the metadata, it's only about the registry. That's why the registry is called "registry" - it was designed by the COM team specifically to register all the COM components available in the system and allow lookup. Even later extensions that added e.g. file extension mapping are still just a mapping to the COM object you want to invoke, nothing more. – Luaan May 7 at 10:57
9

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 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 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:

Windows 3.11 registry editor

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:

OLE 1 Insert Object dialog in Write on Windows 3.11

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.

| improve this answer | |
  • Thanks for going all the way to demonstrate. – Raffzahn May 19 at 11:35
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.

| improve this answer | |
  • MTS appeared around 1999 IIRC, about 6 years after COM proper came along. – Seva Alekseyev May 8 at 2:30
5

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."

| improve this answer | |
  • The registry doesn't "exist for COM". It was around long before COM. Read up on OLE 1. – Seva Alekseyev May 8 at 17:16
  • @SevaAlekseyev my words were Win 3.11 already had a small OLE registry. Not sure of your point. – cat May 9 at 7:50
  • Your second sentence, "The registry exists for COM", is misleading. The 16-bit flavor of registry existed before COM and was later repurposed for COM. – Seva Alekseyev May 9 at 14:21
  • Followup: see the screenshot in my answer. – Seva Alekseyev May 11 at 0:57
3

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.
| improve this answer | |
  • Which of course forfeits all benefits. Cool to see how many still remember the details of early Windows programming. – Raffzahn May 19 at 11:37
  • Someone's comment also mentioned that the registry was not strictly required, thanks for adding more detail. But why do you say that using the registry is easier? Part of the question's premise was contrasting the COM approach to traditional linking (static or dynamic) which was vastly simpler & easier to work with, an approach that registry-based COM thoroughly did away with. I get that for certain use cases this was necessary, but not why it is absolutely better in general. – UuDdLrLrSs May 19 at 12:55
2

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.

| improve this answer | |
2

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).

| improve this answer | |
  • 2
    To quote an engineer I knew a decade or so ago: "COM is not exclusively designed to force you to structure your code is a strange way that makes it really hard to port it to any platform other than Windows. It does that job quite well, but it also has positive uses." – John Dallman May 20 at 20:11
  • 3
    @JohnDallman -- If I knew how to do an "up vote" on a comment, I definitely would on that one. :) Part of my professional background was systems for the Shuttle and the Space Station via various major aerospace contractors. One of the key things was that you had to know how your code was going to run each and every time and given the same exact inputs at the same exact time, it better run exactly the same. As you can probably guess, the idea of any sort of shared library that might get updated and your code not tested with it would be a QA nightmare. – Grumpy OldMan May 20 at 21:50
  • @GrumpyOldMan: You'll gain the privilege to upvote comments with a couple more rep points. – hippietrail May 20 at 22:31
-1

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.

| improve this answer | |
  • 5
    Not entirely true in Windows NT systems. Drive letters are not a first-class thing in the kernel or file systems. A "drive letter" is merely a symbolic link in the object manager namespace which points to the "true name" of the disk volume. Drive-letters are glommed on for userland apps. – another-dave May 5 at 18:41
  • 1
    @another-dave -- interesting, but remember that COM originates from the 16-bit Windows world, not from NT, so the problems of those systems drove its design more than the needs of NT did. – occipita May 6 at 12:57
  • 2
    And yet somehow, nobody ever had a problem finding the Windows root directory, even back in the days when you were running out of a floppy disk. Why? Because Windows doesn't rely on the file system the way Unix does (not that there's anything wrong with that, mind). Only poorly written applications (which were aplenty, of course) relied on stuff being somewhere in the file system on Windows. Even MS-DOS used config.sys and such for interop. Registry was made specifically for COM, and wasn't supposed to be used by user applications at all. It was abused beyond belief over the years :) – Luaan May 7 at 11:07
  • 1
    @DanielRandall - still, drive letters are a Windows subsystem thing, implemented through object manager symbolic links, rather than being fundamental to the kernel and exec. – another-dave May 7 at 11:59
  • 1
    @Luaan -- Misuse by poorly written applications was my bread and butter when I made my living creating auto-configuration software for DesktopStandard (before we were acquired by MSFT). The biggest offender was Office 2000, which enforced the difference between two Outlook installation modes (Exchange vs. Internet Mail Only) with a slew of registry entries and COM registrations; there was a completely different product id for each option. – Daniel Randall May 7 at 17:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.