Object Handlers
As mentioned earlier this specification, object handlers from one perspective are special cases of in-process servers that talk to their local or remote servers as well as a client. From a second perspective, an object handler is really just a fancy proxy for a local or remote server that does a little more than just forward calls through RPC. The latter view is more precise architecturally: a handler is simply the piece of code that runs in the client's space on behalf of a remote object; it can be used synonymously with the term proxy object. The handler may be a trivial one, one that simply forwards all of its calls on to the remote object, or it may implement some amount of non-trivial client side processing. (In practice, the term proxy object is most often reserved for use with trivial handlers, leaving handler for the more general situation.)
The structure of an object handler is exactly the same as a full-in process server: an object handler implements an object, a class factory, and the two functions DllGetClassObject and DllCanUnloadNow exactly as described above.
The key difference between handlers and full .DLL servers (and simple proxy objects, for that matter) is the extent to which they implement their respective objects. Whereas the full .DLL server implements the complete object (using other objects internally, if desired), the handler only implements a partial object depending on a local or remote server to complete the implementation. Again, the reasons for this is that sometimes a certain interface can only be useful when implemented on an in-process object, such as when member functions of that interface contain parameters that cannot be shared between processes. Thus the object in the handler would implement the restricted in-process interface but leave all others for implementation in the local or remote server.