and it's simpler than having to manage the pointer lifetime separately which would require every user to munmap the pointer when they're done.
Managing the pointer for every use as you've described sounds more explicit and straightforward to me than implicit lifetime relationship. IMHO explicitness wins when we're dealing with delicate and potentially complex machinery like memory management.
Besides, multiple writable pointer aliases to a shared memory sounds like a bug waiting to happen. Multiple readable aliases can be replaced by using accessor methods of the container object (e.g., desktop object states).
you could keep using the mapped pointer with the mapping reference released, which imho would be incorrect.
On the other hand, the user might want to keep the shared memory even if the mapping object is no longer used. For example, an unliked desktop object or a zombie process is never supposed to be used by clients, but the kernel may still be interested in its state.
At the end of the day, we're just holding a reference to some Unix temporary file, and its existence doesn't need to be tied to whatever abstraction that Wine brings over.
But again, this might just be a matter of taste so I wouldn't object to this MR on the grounds of `shared_ptr` usage.