In a comment on my post about the MAPI download working with Vista, JP pointed out that something in the updated DLLs is changing the current working directory. I got a chance to look at this today and here is what I found: this is the MAPI Stub‘s doing. In order to support some wonky old MAPI implementations, the stub library will change the current working directory to the directory of the MAPI implementation it’s loading. As far as I can tell, the stub has always done this. It’s only being noticed with Exchange’s MAPI now because now Exchange’s MAPI can be loaded through the stub library.
There’s two ways to work around this if it’s causing problems in your apps. One is to realize the directory might be changed on you and change it back:
- Call GetCurrentDirectory to get the current working directory
- Call MAPIInitialize to load MAPI (this is when the Stub changes the directory)
- Call SetCurrentDirectory to change the working directory back
The other way to work around the issue is to load Exchange’s MAPI directly. You can pull the path from the same key the stub library uses (HKEY_LOCAL_MACHINESOFTWAREClientsMailExchangeMAPI::DLLPathEx) and load the DLL yourself. If you’re already dynamically loading MAPI this wouldn’t be a major change. If you’re statically linking mapi32.lib, then you’ll need to use the first workaround.