Registries

A record of all the MTM components installed on a machine is held in a dedicated file managed by the Message Server called the MTM Registry. Registry classes use this registration data to allow MTM components to be identified and instantiated. For example, the CClientMtmRegistry class has a member function to create a Client-side MTM object.

• a message client application calls this function, passing in the UID of the MTM component that it wants

• CClientMtmRegistry searches the registry for a record for the required MTM component, and obtains from it the library name, and ordinal of the library's exported factory function that can create an MTM object

• CClientMtmRegistry loads the DLL and calls the factory function, passing the new object back to the caller

A similar process is used for User Interface and UI Data MTMs. Such MTM objects are owned by the clients that create them. Clients are also responsible for deleting these objects.

Server-side MTM objects are created by a server-side registry class in response to calls from the Message Server. When the Message Server has no more requests queued for that MTM, it deletes the object. For efficiency, an MTM object can stop itself being deleted when more commands are expected shortly: see CBaseServerMtm::CommandExpected().

Registry classes monitor the use of MTM component DLLs and maintain a reference count of the objects instantiated from each. This allows a registry class to unload a DLL when it is no longer required. However, message client applications can often require a particular MTM component a number of times in any particular session. The registry classes do not therefore immediately unload a component DLL when the reference count is zero. Instead, a timer is started. When the timer completes, the DLL is unloaded if its reference count has remained at zero for the duration.