MMC and the Component Object Model

[This is preliminary documentation and subject to change.]

MMC is built using interfaces that conform to the Component Object Model (COM) specification snap-ins are always implemented as a COM in-process (in-proc) server DLL. In case you are unfamiliar with that term, every COM object is implemented inside a server. Your snap-in executes in the same process as MMC so it is implemented as a dynamic-link library (DLL).

A server makes a COM object available by implementing one or more interfaces. These interfaces are based on a binary standard and enable your snap-in to integrate with the console. MMC gains access to your snap-in by obtaining a pointer to one of its interfaces. With this pointer, MMC can use your snap-in without understanding its implementation and can depend on it to behave in a consistent manner all the time.

COM interfaces also provide a way to extend the functionality of the MMC user interface without dictating how each snap-in performs its particular tasks. Implementation is entirely up to the snap-in. In other words, MMC interfaces allow snap-ins to share a common hosting environment and provide cross-application integration, as indicated below:

By using this approach, both Microsoft and ISVs can write administrative applications that are hosted by MMC. This is also true when it comes to developing management tools to run in MMC and writing applications to be managed by MMC administrative tools. The design of MMC allows developers to spend less time building and rebuilding windowing frameworks for tools and more time on the tasks associated with building real management functionality. Once the prerelease phase is complete, MMC will be part of the Microsoft Platform Software Developers Kit (SDK) and available for general use.