Follow-up to thread - Re: Can I use MAPIOBJECT without MAPILogin?

[Eric]

At the end of this thread it was mentioned that calling
"LoadLibrary("mapi32.dll")" shouldn't be a problem from within an
add-in because Outlook always had it loaded by that time.

Now I'm running into a problem with this stupid "Internet Email Only"
mode. In this mode Outlook doesn't load mapi32.dll, or msmapi32.dll
(which isn't even installed in this mode), or anything MAPI related.
So in this case it seems that I'll have to load the DLL myself, from
my add-in, and take care of initialization and log-in. I haven't
tested this yet, that is my next step, but I'm guessing I wouln't be
able to access the MAPIOBJECT properties anymore without doing
MAPIInitilize(), etc, if they even exist at all in this mode.

Since Outlook doesn't appear to use MAPI at all in this mode, I could
no longer go under the theory that my COM add-in should always be able
to work with MAPI. In the other mode everything seemed robust because
I was only using the same function calls that Outlook itself was
using, but now my add-in might be the first thing to touch the MAPI
sub-system, and therefor be the first thing to break-down.

Has anyone had any experience with this issue? I don't want to
require users to switch to workgroup mode because that requires the
Outlook CD (among other reasons) and most users can never locate the
CD.

 

[Dmitry Streblechenko]

MAPIOBJECT is perfectly accessible in IMO and you do not have to call
MAPIInitialize if your code runs as an Outlook COM addin unless you create
your own thread.
Are you sure msmapi32.dll is not loaded in the IMO mode? Did you check with
the Process Explorer from
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml ?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

 

[Eric]

Yes, that is the process explorer I use, very handy. In workgroup
mode Outlook 2000 loads MSMAPI32.DLL, but in IMO mode Outlook 2000
doesn't. I even noticed that when I switched to IMO mode the process
removed the MSMAPI32.DLL file from my hard drive even. When I switch
back to workgroup mode it is reinstalled.

I'm working on another project and haven't looked at this stuff again
yet (but I do need to come back to it soon), but I'm pretty sure
Outlook 2000 doesn't load ANY MAPI DLLs in IMO mode. I don't think I
even saw MAPI32.DLL or MAPI32X.DLL, or any of those in the process
explorer list.

Since a lot of my target users have Outlook 2000 still, and still
installed in the default IMO mode which doesn't use MAPI very much (if
at all). I find that if I use MAPI in my app, or add-in DLL, I end up
getting lots of calls from users who have mixmatched MAPI DLLs, or
just experience other MAPI issues. They don't care that Outlook even
says that IMO mode will break some add-ins, and 3rd party apps, (and
most have never seen this warning since you only get it when switching
BACK to IMO mode), they just know that Outlook works, and my
add-in/app doesn't.

 

[Dmitry Streblechenko]

msmapi.32dll is not loaded in IMO, but mapi32.dll is (check using "Find|Find
Dll" in the Process Explorer).
I know that all of my Exchange Client Extensions work just fine in the IMO
mode, and they explicitly load mapi32.dll is msmapi32.dll is missing.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

 

[Eric]

Thanks, I'll give it a try. I've had problems with mapi32.dll being a
version from Eudora, or other client which replaces it, and then my
calls go to them instead of Outlook. Usually when this is the case my
first call to MAPIInitialize() would fail because most of the
replacement MAPI*.dll files only support simple MAPI, and even if they
do support extended MAPI I don't want to talk with them anyway.
However, even with the MAPI dlls in such poor shape, Outlook still
runs fine. Maybe in IMO mode Outlook wouln't be able to run in this
state, since it doesn't have its own msmapi32.dll to use, which would
be great.

 

[Eric]

Actually I just checked this on my system and I can't find
"mapi32.dll" or any DLLs with "mapi" in the name under the Outlook.exe
process. I don't have a "Find|Find Dll" option in my version of
Process Explorer (About screen says 5.25v by Sysinternals). I do have
a "Search->Find" option though, which must be the same thing. When I
look for "mapi" it finds a few hits under Outlook.exe, but just
because "mapi" is in the path of a few DLLs it loads, like
....\mapi\...\outex.dll.

Maybe your copy of Outlook loads mapi32.dll because you have an
extension installed which is loading it? I notice when I enable the
Outlook Spy extension it loads mapi32.dll, as well as the CDO DLLs,
etc...

Interesting that when I enable Outlook Spy it loads mapi32.dll from a
path like:
c:\program files\common files\system\mapi\1033\95\mapi32.dll

Instead of the "c:\windows\system\mapi32.dll" that I usually end up
loading whenever I just use LoadLibrary("mapi32.dll"). Must have
something to do with those registry settings which make certain apps
load the MS MAPI dlls, I bet Outlook.exe is in there.

If this other mapi32.dll is usually the correct DLL, instead of the
one in the system directory, maybe that will solve all my problems if
I load it instead. And it sounds like loading from an Outlook add-in,
instead of my seperate EXE I used to use, will end up loading that
other copy of the DLL like Outlook Spy does.

Any idea why there are so many MAPI32.DLL files all with the same
name, but with different versions, and in different directories? I've
searched MSDN but have yet to find any guidelines for which copy
should be used for various types of applications. All of the code
samples just use LoadLibrary("mapi32.dll"), which seems to get the
copy from the system directory, which always seems to be replaced by
so many programs, and that old "fixmapi.exe" rarely works.

 

[Eric]

Sorry for so many posts in a row, but I've finally had some time to
work on this again.

Now I'm using MSVC debugger to watch what DLLs are being loaded. When
I run Outlook.exe, with no extensions installed, no copies of
mapi32.dll are loaded. If I then enable Outlook Spy, mapi32.dll is
loaded from the "program files\...\1033\95\" directory. If I run
Outlook again, but this time load my extension which just calls
"LoadLibrary("mapi32.dll")", I end up seeing
c:\windows\system\mapi32.dll loading...

Can you tell me how you made Outlook Spy load that other copy of the
DLL? I'm thinking that version will be less likely to be replaced by
other apps...

Thank you

 

[Dmitry Streblechenko]

1. OutlookSpy load the same copy of mapi32.dll or msmapi32.dll as Outlook
itself - since OutlookSpy runs in the same address space as Outlook.exe, it
ends up using the same dll. OutlookSpy calls LoadLibrary("mapi32.dll")
without specifying a path; if a dll with the same name is already loaded in
the same process space, LoadLibrary will return a handle to that loaded dll,
so OutlookSpy is different from a separate exe that runs in an address space
other outlook.exe/
2. You need to tell MAPI that your app needs to use Outlook's version of
mapi32.dll - from MSDN:

Explicitly Mapping MAPI Calls to MAPI DLLs
In some cases, MAPI calls made from a particular DLL or executable file need
to be routed to the system MAPI DLL (called Mapi32x.dll) or another custom
MAPI DLL even though the default mail client supports the call. Such DLLs or
executables files can be listed as string registry values in the
HKLM\Software\Microsoft\Windows Messaging Subsystem\MSMapiApps key. The
registry value for these keys can be empty or identify a mail client key
that resides under HKLM\Software\Clients\Mail.

When the stub library resolves a MAPI call, it first enumerates the DLL and
executable files listed under the HKLM\Software\Microsoft\Windows Messaging
Subsystem\MSMapiApps key checking to see if the DLL or executable file is
currently in process. If there is a match, the stub library gets the string
value. If the value is the empty string, the stub library routes the call to
the system MAPI DLL, Mapi32x.dll. If the string is not empty, the stub uses
the string value to find the key below HKLM\Software\Clients\Mail where it
can find the appropriate registry value to dispatch the call, one of
DLLPath, DLLPathEx, or MSIComponentID values. For example:

HKLM\Software\Microsoft\Windows Messaging Subsystem\MSMapiApps::exchng32.exe
= ""
(route call directly to Mapi32x.dll)

HKLM\Software\Microsoft\Windows Messaging Subsystem\MSMapiApps::msspc32.dll
= "Microsoft Outlook"
(route call using Microsoft Outlook key under HKLM\Software\Clients\Mail)
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

 

[Eric]

Thanks again for the help. I'm going to go ahead and load mso9.dll
directly, if msmapi32.dll wasn't loaded, in testing this seems to work
best so far.

I have no idea why my add-in loads c:\windows\system\mapi32.dll, and
Outlook Spy loads the other one, but I imagine it must be something
minor. Like the working directory at the time Outlook loads it vs. a
COM add-in, or maybe that a function inside msoutex.dll (which is
located in the directory with the private mapi32.dll) might be loading
the Exchange Extensions, and COM add-ins may be loaded from code in
Outlook.exe.

Luckily I never really wanted to load mapi32.dll anyway, and by
loading mso9.dll it seems like I have a better chance of being able to
run even if some app has replaced the mapi32.dll with their own
version, or any of the other silly things our tech. support center has
had calls about.

Thanks again!