[Previous] [Contents] [Next]

Foreword

Well, it's been over a decade since I started writing applications for Microsoft Windows. Back then, it was easy for someone to say that they really understood Windows and all of its subsystems. Each of these subsystems exposed only a few hundred functions: in Windows 2.11, Kernel had 283, User had 141, and GDI had 213, for a grand total of 637 functions. How hard could it be to understand what these few functions did?

Over the past 10 years, Microsoft has greatly extended these modules and has added numerous subsystems to Windows: telephony, remote access, print spoolers, 3-D graphics, Internet access, security, registry, services, multimedia, networking, and so on. It is now impossible for any individual to fully understand the entire operating system. For this reason, I've advised developers to pick certain components of the system, study them, learn them, and become specialists in them. This is not to say that you should ignore other parts of the system—I've specialized in Kernel and User, but I've also dabbled in GDI, networking, and lots of other areas.

At Microsoft, different teams develop each of these subsystems and each team develops its own "philosophy." For example, I know that the registry functions all start with a Reg prefix and return an error code. But I also know that most Kernel functions have no special prefix and return FALSE if they fail; in these cases, I have to call GetLastError to see the reason for the failure. This inconsistent behavior among subsystems is one of the reasons that Windows programming has had a reputation for being difficult to learn.

By now, it is obvious to everyone that Microsoft is firmly committed to Windows for the present and for the foreseeable future. To achieve this end, it has needed a plan that allows new subsystems to be added without steepening the developer's learning curve too much. In other words, there must be consistency in using the various subsystems (or components). The technology to address this need is COM+.

Microsoft exposes new technologies by implementing each new subsystem as a COM+ object. You can easily see this design when you use directory services (Active Directory), transaction services (Microsoft Distributed Transaction Coordinator), graphics (DirectX), shell extensions, controls (ActiveX controls), data (OLE DB), scripting (ActiveX scripting), and on and on. COM+ is now the way to interact with these subsystems. In fact, in an effort to reduce the Windows learning curve for new developers, Microsoft is going back to older subsystems and exposing those systems as COM+ objects.

It is now imperative that Windows developers understand the core infrastructure of COM+. With this understanding, you can easily take advantage of these new subsystems as well as more easily expose your own subsystems. Distributed computing is a massive undertaking that requires addressing many difficult problems, such as data transfer, incompatible computer architectures, disparate network architectures, timing issues, and so on. Fortunately, Microsoft has teams of developers working to solve these problems and to make things easier for the rest of us. Windows 2000 offers the first enterprise-level release of COM+.

With Microsoft firmly behind it, COM+ will undoubtedly be the best way to interact with subsystems, not only on a single machine but also on any computer anywhere in the world (and possibly beyond). Inside COM+ Base Services is our guidebook. Let's keep our fingers crossed and hope that it is translated into Martian.

Jeffrey Richter