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:
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_MACHINE\SOFTWARE\Clients\Mail\ExchangeMAPI::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.
I've tried the first way. It does not work... After MAPILogonEx() call, current directory has changed.
Any solution for John smith problem ? because i have same problem.
John's claim was that the workaround to the problem I discussed did not work. I claim that it did work. He just found a new problem with MAPILogonEx. I haven't looked in to that problem, but I don't see why trying the same workaround wouldn't work there.
Thanks for your reply. I tried second way(directly loading MAPI procedure from MAPI32.DLL). Unfortunately, for that way, working directory has been changed after MAPILogonEx().
"One is to realize the directory might be changed on you and change it back:" <- did you try this?