Several observations so I can finish the Win32 code that's sat on my machines for the last four months...
1. Win32 allows both anon mapping (keyed into the swap file itself) and file based mapping. We have no concept of key based mapping, since handles to shmem are very process specific and the handles themselves can't be shared. I suppose a key-based mapping could be the name of a swap-file anon segment with the "apr_" prefixed to the numeric value, but that might be rather silly. 2. Win32 further supports naming file maps. That is, once a mapping to a file or into the swap file is created, other processes simply open that named map. This isn't the file name, this is the name given by the creator to the file mapping. 3. Even on unix, the concept of getting the 'named' key and setting it once again based on an abstract type strikes me as entirely bogus, here would be my recommendation: if apr doesn't support named mapping at all, APR_ENOTIMPL instead of APR_ANONYMOUS (it's obvious) from apr_get_shm_name. Otherwise, always return a string, even if it's the ascii representation of the key_t value. Conversly, on apr_set_shm_name, convert that numeric ascii string back to a key_t. This becomes an internal instead of external abstraction. The other anon option is to return an empty string, and setting the name to the empty string yields APR_SUCCESS. In general, I don't really believe the apr_shmem implementation is abstract enough for general, everyday use. We are under the silly impression that users want only -one- kind of shmem at a time, which is obviously absurd. If we are just looking to kick around a 64kb segment, anon memory (implemented on win32 as swap file mem) is just fine, thanks. If we are going to pass around the passphrases to a bunch of secrets, we probably want file based shmem and store it in the secure temp directory with a randomly generated name (coming back to the mkstemp issue :-) I'd like comments on this before I proceed further. Bill