How to declare that my Simple MAPI provider DLL is Unicode and supports MapiSendMailW?

Question

I have written a simple MAPI provider DLL that implements the following functions:

MapiLogOn        
MapiLogOff       
MapiSendMail     
MapiSendDocuments
MapiFindNext     
MapiReadMail     
MapiSaveMail     
MapiDeleteMail   
MapiFreeBuffer   
MapiAddress      
MapiDetails      
MapiResolveName  

I have registered my DLL in Registry HKLM\SOFTWARE\Clients\Mail\ and can select it via "Default programs".

It works perfectly (but with ANSI characters only)!

Now, I'm trying to add Unicode support for it.

I have implemented MapiSendMailW and have declared it into the "export" section of the DLL, so that MAPI DLL stub could see that it exports MapiSendMailW and is thus Unicode.

However, this Unicode MapiSendMailW function of my DLL is never called. The ANSI version, MapiSendMail, is called instead.

When I use applications that calls MAPI, e.g. Microsoft Internet Explorer (to send links by email) or Adobe Reader (to send files by email), national characters come to my DLL in MapiSendMail replaced by question marks. If I switch the default mail client to Outlook, Microsoft Internet Explorer sends national characters properly.

In the meanwhile, Outlook advertises its MAPI DLL as Unicode. I have found this registry value "SupportUTF8" under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Clients\Mail\Microsoft Outlook

When I have deleted this registry key, Microsoft Internet Explorer did also begun to replace national characters to question marks when calling Outlook when I chose File/Send/Link by email.

So, it seems that "SupportUTF8" under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun..... had sense.

My client is registered under HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\.....

Adding SupportUTF8 to my client made no sense (still question marks, and no MapiSendMailW called but MapiSendMail from MSIE (File|Send|Link by email). Even adding SupportUTF8 to HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Microsoft Outlook didn't make MSIE not replace national characters to question marks when calls Outlook.

Regardless of the SupportUTF8 registry value, when my client is called from MS Word, it gets MapiSendMail, but in ulReserved it gets UTF8 codepage number, so my client is able to display national characters. But it doesn't happen from MSIE (File|Send|Link by email) which always replaces national characters to question marks with my client.

What should I add to my DLL so that Windows Stub sees it as Unicode and call MapiSendMailW? Should I register implement other functions to the DLL to show to the Stub that it is Unicode?

I've done two tests:

1. On Windows 10 64-bit. The MAPI DLL is 32-bit. The Process Monitor (from Sysinternals) shows that MSIE runs a process fixmapi.exe which in its turn makes the MAPI calls.

2. On Windows 7 32-bit. No fixmapi.exe is used: MSIE calls my DLL directly, but still doesn't call MapiSendMailW.

However, my test MAPI application calls my DLL with MapiSendMailW.

Answer 1

I have found a solution to this problem. My Simple MAPI provider was OK and has declared MapiSendMailW properly. A simple application that just uses LoadLibrary to load the MAPI DLL from Windows system folder (C:\Windows\System32\mapi32.dll) and then call MapiSendMailW will work properly. I was just testing Microsoft Internet Explorer and Adobe Reader when I came to the conclusion that the “Unicode MapiSendMailW function of my DLL is never called”. But I have later found out that these applications do not work properly with MAPI when it comes to Unicode, the problem was with these applications. You don’t have to do anything about it. The other programs work properly with the Unicode MapiSendMailW function of my DLL.

Besides that, I have also managed to compile and register the 64-bit version of the MAPI DLL handler. Care just have to be taken with structure sizes – 64 bit Windows have different rules of alignment then 32-bit. All fields have to be aligned by 8 bytes. Pointers have to be 64-bit, while integers (ULONG) have to be 32-bit. The size of TMapiMessageW structure under 64-bit is 96 bytes, while under Win32 it is 48 bytes.