In one respect, COM+ is yet another "marketecture" term to describe COM. Based on the current version of the Platform SDK, you would think that COM+ is simply a euphemism for MTS 3.0. However, with the dissolution of MTS as a distinct technology, it is difficult to determine where COM ends and COM+ begins (which explains why some recent Microsoft talks have started to use COM+ to refer to any COM-related technology in Windows 2000). As an old-time COM person, I simply look at it all as COM and try to ignore the annual renaming rituals practiced by marketing types indigenous to the Northwest.     You may be reading this article and wondering why the COM+ that is planned to be shipped with Windows 2000 is so different from the COM+ described in Mary Kirtland's articles in the November and December 1997 issues of MSJ. Mary's articles were based on a much broader change to COM than has happened so far. In particular, Windows 2000 isn't slated to include a new virtual machine-like runtime that will replace the need for IUnknown, IDispatch, reference counting, class factories, IDL, BSTRs, vptrs, and vtables. At the time of this writing, Microsoft has made no public statements regarding the release of that aspect of COM. MTS Anachronisms     With the planned unification of COM and MTS under Windows 2000, several details of MTS development have either become deprecated or renamed. What used to be called an MTS Package is now a COM+ Application. Additionally, exporting a COM+ Application allows better control over what gets generated. In particular, you can now generate a Microsoft Installer-com---- patible set of files to ease deployment in Windows 2000-based networks.     Now that interception is built into the core remoting architecture of COM, the context wrapper (the MTS interceptor) is now gone. You no longer need to use SafeRef to ensure that your object always receives interception services. Also, since CoCreateInstance now sets up your object in a properly configured context, you no longer need to use IObjectContext::CreateInstance.     In general, the familiar IObjectContext is being replaced by new interfaces that are better factored to reflect their roles. The exact method names and interface hierarchy are not yet final, but the new object model is likely to be a much closer reflection of what's going on with your context. To facilitate getting these new interfaces, Windows 2000 will likely add the API function CoGetObjectContext that allows the IID of the expected interface to be explicitly specified. For backwards compatibility, IObjectContext and GetObjectContext are still supported.     Finally, the current build of Windows 2000 doesn't support ISecurityProperty::GetOriginalCreatorSID or GetDirectCreatorSID. If you need this functionality, you must now record the SID of the creator explicitly in your object.