567315 - ISimpleDOMNode support on 64bit platforms

Status: RESOLVED DUPLICATE of bug 568949

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

from http://groups.google.com/group/mozilla.dev.accessibility/browse_thread/thread/822f14690233e58a

Hi,
I successfully do queryservice (IAccessible) to get the ISimpleDomNode
when my OS is 32 bit and Firefox is 32 bit. But with Firefox x64 -
Namoroka. The following queryService call fails :

                IServiceProvider *pServProv = NULL;
                pCAcc->QueryInterface(IID_IServiceProvider, (void**)&pServProv);
                ISimpleDOMNode  *pNode = NULL;
                if (pServProv)
                {
                        const GUID refguid = {0x0c539790, 0x12e4, 0x11cf, 0xb6, 0x61,
                                                                        0x00, 0xaa, 0x00, 0x4c, 0xd6, 0xd8};
                        HRESULT hresult = pServProv->QueryService(refguid,
IID_ISimpleDOMNode,
                                                                                                                   (void**)&pNode);

                        // fails
                       .........
                }
I found that the ISimpleDomNode has entries only in WOW part of
registry. My application is x64 so it could be looking not in WOW part
of registry but in the main section of registry meant for x64 apps.
that could be the reason its is failing. Any alternate suggestions to
fix this? Is ISimpleDomNode interface going to have entries in x64
part of registry in future?

Thanks,
Pradeep

Comment 1

[alexander :surkov (:asurkov)]

We register dll in http://mxr.mozilla.org/mozilla-central/source/accessible/public/msaa/Makefile.in#119.

David, could you cc right people to get an idea what's wrong here?

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #1)
> David, could you cc right people to get an idea what's wrong here?

Yep. Ehsan, do you think this is a dll (com server) registration issue?

Also, what is the "WOW part" of the registry? Is that some windows on windows thing (for running 32 bit on top of 64 bit windows)?

Comment 3

[(no longer active)]

(In reply to comment #2)
> (In reply to comment #1)
> > David, could you cc right people to get an idea what's wrong here?
> 
> Yep. Ehsan, do you think this is a dll (com server) registration issue?

Kind of.  See below.

> Also, what is the "WOW part" of the registry? Is that some windows on windows
> thing (for running 32 bit on top of 64 bit windows)?

It's HKEY_LOCAL_MACHINE\Software\WOW6432Node, which is used as the registry root node for 32-bit apps installed on a 64-bit OS, to avoid conflicts between 32 and 64 bit apps.

This problem is that our interface is registered somewhere under HKEY_LOCAL_MACHINE\Software\WOW6432Node\Classes, because the registration is done by a 32-bit application.  But a 64-bit application tries to find the interface definition in HKEY_LOCAL_MACHINE\Software\Classes, hence the problem.

But the real problem is not where the interface is registered, I think.  We should be acting as an out of process COM server.  If we're an inproc COM server (aka a DLL) then the 64 bit application will fail when it calls LoadLibrary to load our DLL, because of architecture differences, *even if* it can find the correct interface definition.

I'm not sure if we implement an out of process COM server for our a11y COM classes.  If we don't, we need to migrate in that direction as a first step of solving this problem.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

AFAIK we act as an out of process COM server. AT do inject dll's into our space for some operations that require performance; where interactive marshaling is undesirable. I think latter point this is not relevant here though?

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Hard to believe english is my first language I know.

Comment 6

[Makoto Kato [:m_kato]]

RegDLL always fail on 64-bit binary.  So we must to use Library.nsh or regsvr32 /s on installer.

Comment 7

[Makoto Kato [:m_kato]]

Attachment: patch v1

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks Makoto. Is this patch ready for review? If you need help finding the correct reviewers just ask here -- though I'm actually not sure at the moment.

Comment 9

[Robert Strong (they/them - no direct email)]

Comment on attachment 448486 [details] [diff] [review]
patch v1

>diff --git a/toolkit/mozapps/installer/windows/nsis/common.nsh b/toolkit/mozapps/installer/windows/nsis/common.nsh
>--- a/toolkit/mozapps/installer/windows/nsis/common.nsh
>+++ b/toolkit/mozapps/installer/windows/nsis/common.nsh
>@@ -3986,7 +3986,13 @@
>       StrCmp $R0 "\" +2 +1
>       StrCpy $R1 "$R9"
> 
>-      UnRegDLL $R1
>+      !ifdef WIN64
>+        ${DisableX64FSRedirection}
>+        ExecWait '"$SYSDIR\regsvr32.exe" /s /u "$R1"'
>+        ${EnableX64FSRedirection}
>+      !else
>+        UnRegDLL $R1
>+      !endif
> 
>       end:
>       ClearErrors
common.nsh should also include x64.nsh

Since AccessibleMarshal.dll is shared across all installs with the last install winning the registration how does it behave when a 64 bit version is used with a 32 bit app and vice versa?

With that change and the question answered r=me. If the answer to the question is it doesn't then please file a followup Disability Access bug.

Comment 10

[Makoto Kato [:m_kato]]

(In reply to comment #9)
> Since AccessibleMarshal.dll is shared across all installs with the last install
> winning the registration how does it behave when a 64 bit version is used with
> a 32 bit app and vice versa?

32bit COM is registered to WOW6432Node, but 64bit COM is registered to HKCR directly.  On 32bit application can use 32bit COM and cannot use 64bit COM.

(If you use 32bit COM, you have to install 32-bit Firefox.)

RegDLL can only register 32bit COM and cannot register 64bit COM.  So this fix uses regsvt32 of 64bit version to register 64bit COM.

Since installer is same path (PROGRAMFILES vs PROGRAMFILES64) / registry (HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall vs under Wow6432Node\Microsoft...), I have to fix it at fist (I will file new bug).


> With that change and the question answered r=me. If the answer to the question
> is it doesn't then please file a followup Disability Access bug.

Comment 11

[Makoto Kato [:m_kato]]

filed bug 568949 for installer's uninstall registry issue.

Comment 12

[Makoto Kato [:m_kato]]

s/568949/bug 570951

Comment 13

[Robert Strong (they/them - no direct email)]

(In reply to comment #10)
> (In reply to comment #9)
> > Since AccessibleMarshal.dll is shared across all installs with the last install
> > winning the registration how does it behave when a 64 bit version is used with
> > a 32 bit app and vice versa?
> 
> 32bit COM is registered to WOW6432Node, but 64bit COM is registered to HKCR
> directly.  On 32bit application can use 32bit COM and cannot use 64bit COM.
> 
> (If you use 32bit COM, you have to install 32-bit Firefox.)
> 
> RegDLL can only register 32bit COM and cannot register 64bit COM.  So this fix
> uses regsvt32 of 64bit version to register 64bit COM.
> 
> Since installer is same path (PROGRAMFILES vs PROGRAMFILES64) / registry
> (HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall vs under
> Wow6432Node\Microsoft...), I have to fix it at fist (I will file new bug).
> 
> 
> > With that change and the question answered r=me. If the answer to the question
> > is it doesn't then please file a followup Disability Access bug.
I was referring to there being both a 32 bit and a 64 bit Mozilla application being installed on the same system with both of them having AccessibleMarshal.dll registered and whether there are any problems when this is the case.

Most of the installer / uninstaller x64 changes are fairly trivial and I'd prefer if they were taken care of at the same time in bug 568949 instead of a bunch of trivial bugs unless there is a need to get something fixed immediately.

Comment 14

[Robert Strong (they/them - no direct email)]

This should be fixed by the landing of bug 568949.

It would be a good thing IMO if one the owner or one of the peers of accessibility verified that things work properly when there are both an x86 and an x64 build installed on the same system. I am leaving this bug open in case they agree with doing this.

Comment 15

[Makoto Kato [:m_kato]]

verified by bug 568949's fix.  dup of bug 568949

Comment 16

[James Teh [:Jamie]]

I'm not sure if this was eventually figured out, so I'll post this just in case it wasn't.

The COM dll in question here (AccessibleMarshal.dll) is actually a COM proxy dll. It is necessary for cross-process communication when an out-of-process client requires one of the ISimpleDom* interfaces. On a 64 bit system, both 32 bit and 64 bit proxy dlls need to be registered (regardless of whether Firefox is 32 bit or 64 bit), as the proxy dll is loaded into the *client* process. Thus, if you only install a 64 bit dll with 64 bit Firefox, 32 bit clients won't be able to access ISimpleDom*. The reverse applies for 32 bit Firefox.

Comment 17

[Makoto Kato [:m_kato]]

(In reply to comment #16)
> I'm not sure if this was eventually figured out, so I'll post this just in case
> it wasn't.
> 
> The COM dll in question here (AccessibleMarshal.dll) is actually a COM proxy
> dll. It is necessary for cross-process communication when an out-of-process
> client requires one of the ISimpleDom* interfaces. On a 64 bit system, both 32
> bit and 64 bit proxy dlls need to be registered (regardless of whether Firefox
> is 32 bit or 64 bit), as the proxy dll is loaded into the *client* process.
> Thus, if you only install a 64 bit dll with 64 bit Firefox, 32 bit clients
> won't be able to access ISimpleDom*. The reverse applies for 32 bit Firefox.

64-bit firefox only has 64-bit DLL and 32-bit firefox only has 32-bit DLL.  This is current limitation.  If you want it, you should install both.

Comment 18

[Robert Strong (they/them - no direct email)]

Thanks James, I thought that might be the case.

It seems to me that a bug should be opened against Core -> Disability Access APIs to figure out / implement a solution for this.

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

Filed as bug 606468. Thanks.