1879717 - TB 64bit installer fails to install/register 32bit MAPI

Status: ASSIGNED

(Thunderbird :: Build Config, defect, P2)

Description

[Jeremy Jackson]

Steps to reproduce:

Using WIndows 10 22H2 - 64bit OS - install TB 64bit.
Attempt to send email from QuickBooks 2021 (32bit application) which uses 32bit MAPI, which works when 32bit TB is installed.

Actual results:

Quickbooks 32bit doesn't find any installed MAPI provider.

Expected results:

If I copy the DLL from 32bit install on another machine, and set MAPI registry entries manually, QuickBooks can send emails using 32bit MAPI
The installer should do this automatically.

Comment 1

[Jeremy Jackson]

Attachment: tb-mapi-clsid-32bit.reg

Used to demonstrate working 32bit MAPI on 64bit Windows 10 + 64bit Thunderbird

Comment 2

[Jeremy Jackson]

Attachment: tb-mapi-interface-32bit.reg

Used to demonstrate working 32bit MAPI on 64bit Windows 10 + 64bit Thunderbird

Comment 3

[Jeremy Jackson]

Attachment: tb-need-maybe.reg

Used to demonstrate working 32bit MAPI on 64bit Windows 10 + 64bit Thunderbird

Comment 4

[Jeremy Jackson]

after installing 64bit TB in C:\Program Files\Thunderbird, create a subfolder called "32bit" and copy the following files from a 32bit TB install into it, then use the 3 .reg files to register the 32bit MAPI interface:
MapiProxy.dll
MapiProxy_InUse.dll
mozMapi32.dll
mozMapi32_InUse.dll
Tested with QuickBooks 2021 (32bit)

Comment 5

[Jeremy Jackson]

Considering the number of posts in both Thunderbird, Quickbooks, and other support forums, and the fact that the coding has already been done, this would seem like an easy win to make TB more useful, and reduce help requests.

Comment 6

[Rob Lemley [:rjl]]

Thank you for the thorough report. This is very helpful.

Currently, the 64-bit build only builds the 64-bit DLLs, but there is no reason why it couldn't build 32-bit ones as well.

MSIX and NSIS installers will need updating.

Comment 7

[Rob Lemley [:rjl]]

(In reply to Rob Lemley [:rjl] from comment #6)

Currently, the 64-bit build only builds the 64-bit DLLs, but there is no reason why it couldn't build 32-bit ones as well.

It turns out that mozbuild does not support building 32-bit and 64-bit DLL/executables in the same build.

However, since these DLLs are relatively simple with sources in a single directory, it may be possible to "hack something horrible" up. For now though, this is stalled.

Comment 8

[Rob Lemley [:rjl]]

Attachment: Bug 1879717 - Build 32-bit mozMapi DLLs for 64-bit build. r=#thunderbuild

Comment 9

[Rob Lemley [:rjl]]

Attachment: Bug 1879717 - Package 32-bit MAPI DLLs with win64 build. r=#thunderbuild

This just includes the DLLs. It does not register them with Windows/MAPI.

Comment 10

[Rob Lemley [:rjl]]

I think this will work. I have a test build running now. I will post download links tomorrow so the DLLs can be tested.

Comment 11

[Rob Lemley [:rjl]]

Minor snag that I had to work around. New test build in progress.

Comment 12

[Rob Lemley [:rjl]]

Problem...

IIUC, Windows allows having both a 32-bit and 64-bit MAPI provider installed. The way the above patches are written, both builds would use the same GUIDs for the MapiProxy (6EDCD38E) and mozMapi (29f458be) pieces. I'm not sure that's right? Should one or both be different to avoid conflicts?

Also, Win-Arm64 is coming and it looks like it will be able to support Thunderbird MAPI as well. However, I highly doubt that these applications mentioned by the OP will have a native Arm64 build any time soon if they haven't made an x64 version yet.

I should be able to finish this if someone can answer that question...

Comment 14

[Wayne Mery (:wsmwk)]

Mike, Robert, do you have any insight to comment 12?

Comment 15

[Mike Kaganski]

(In reply to Wayne Mery (:wsmwk) from comment #14)

Sorry for late answer.

(In reply to Rob Lemley [:rjl] from comment #12)

IIUC, Windows allows having both a 32-bit and 64-bit MAPI provider installed. The way the above patches are written, both builds would use the same GUIDs for the MapiProxy (6EDCD38E) and mozMapi (29f458be) pieces. I'm not sure that's right? Should one or both be different to avoid conflicts?

AFAICT, this is a common situation, and IIUC, the requirement. E.g., look at HKEY_CLASSES_ROOT\CLSID{0b6d74fe-ad29-4c92-ac06-f06bc2f238a7}, which is "Microsoft Feeds Request". Searching through registry for 0b6d74fe-ad29-4c92-ac06-f06bc2f238a7 would give you matches in both HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID, and in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID. And there are no different constants that you use with e.g. CoCreateInstance, for 32 vs. 64 bits (like CLSID_PersistentZoneIdentifier, which is 0968e258-16c7-4dba-aa86-462dd61e31a3).

Hope this helps!

Comment 16

[Corey Bryant]

Removing my needinfo since there are more knowledgeable folks looped in. Thanks for taking a look Mike.

Comment 17

[applesolvent]

I am really sorry that I am interrupting you guys with my text but I just wanted to lay off a problem from my mind. As mentioned here bug 1902912 I have installed Thunderbird from MS Store and I can send files as attachment through Thunderbird (MS Store) as a mail. I got the error "error message : not possible because there is no standard mail program.". I only had thunderbird from ms store installed as an e-mail-program. no outlook no nothing. i think edge and firefox (ms store) aren't MAPI-compatible either.

so I deinstalled thunderbird from ms store (which also had been updated much later than he MSI or EXE from thunderbirds official site) and installed the MSI. i didn't had to connect the profile-folder, it got found (on extra partition) instantly.

the MSI was quite interesting because it installed itself without an install wizard.