There couldn’t be a less misleading post title than the one I chose for this entry. The function SHAllocShared is documented, may not be very well known, but we may see it more in the future. It is exported by shlwapi.dll and its description has a nice vibe to it:

Allocates a handle in a specified process to a copy of a specified memory block in the calling process.

Hmm… I remember that 15+ years ago or so I was looking at the AppBar functionality. At that time many applications were taking advantage of this desktop feature, so I was really curious how it works. Eventually I created a simple POC that relied on SHAppBarMessage function to add my own app bar, but then got bored and forgot about it.

A few months back I suddenly remembered that POC. I realized that I have never looked at the internals of the SHAppBarMessage function, and with my experiments around code injection via GUI primitives this of course triggered my interest.

Under the hood, the SHAppBarMessage relies on SHAllocShared/SHLockShared and SHUnlockShared/SHFreeShared APIs to create&lock/unlock&free block of memory allocated within program’s address space, and then WM_COPYDATA message is used to send info about the appbar message to ‘Shell_TrayWnd’ window (tray window). Internally, SHAllocShared relies on CreateFileMapping/MapViewOfFile/DuplicateHandle API set to duplicate a handle to existing memory block inside a target process.

This is it. It’s not a lot, but having a set of atomic functions residing inside the shlwapi.dll is probably not a bad thing. This is not as robust as accessibility functions that do a lot of reading and writing of memory blocks between different processes, but it’s always good to have some extra feature at hand.