595053 - [OOPP] add support for using i386 plugins from an x86_64 host (Windows Version)

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Robert Johnston]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre
Build Identifier: 

Deliberately duping Bug 559142 as per the comments therein.

x64 Windows builds of Firefox cannot use i386 plugins, despite the plugins operating OOP, and despite the OS having a built-in compatibility layer. This is being investigated for Mac (Bug 559142) and Linux (Bug 588749).

Reproducible: Always

Comment 1

[Josh Aas]

In case someone is working on this, best to wait until the patch for bug 590057 lands. That will provide fixes for Windows as well, including a foundation for architecture preference.

Comment 2

[Makoto Kato [:m_kato]]

Attachment: WIP v1

Comment 3

[Masatoshi Kimura [:emk]]

At present, we can't get 32-bit browser's path from registry key reliably if the browser is per-user installed. See bug 633804 for details.

Comment 4

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

You actually can't get the browsers path reliably from the registry since multiple installations of the same version will also overwrite other installations, a zip build doesn't add the registry keys, and I highly suspect that portable Firefox doesn't add the registry keys.

We have never relied on registry keys in the past for Firefox to operate properly and the only reason the registry keys were added in the new installer is for backwards compatibility with the old xpinstall installer in case there were 3rd party applications that relied on the registry entries.

I can't gaurantee that the registry entries you are trying to use are accurate for the reasons stated above and I think a more reliable method needs to be created instead of trying to repurpose these registry keys to accomplish what you want to in this bug.

Comment 5

[Masatoshi Kimura [:emk]]

Perhaps 64-bit browsers should be shipped with their 32-bit counterparts. Depending on other installation is inherently unreliable.

Comment 6

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

I think they would be the best path to take. 

btw: there is also bug 606468 to provide both 32 and 64 bit support for AccessibleMarshal.dll.

Comment 7

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

Removing dependency on bug 633804 since that isn't a reliable solution to this bug.

Comment 8

[Masatoshi Kimura [:emk]]

Attachment: WIP: Build both x86 and x64 binaries

I have no time to complete the work. Feel free to take this.

Comment 9

[Masatoshi Kimura [:emk]]

Attachment: MozillaBuild startup batch

Comment 10

[Makoto Kato [:m_kato]]

(In reply to comment #9)
> Created attachment 513239 [details]
> MozillaBuild startup batch

Kimura-san, I think that customizing mozilla-build isn't good way.  We should use something like WinCE toolchain hack (arm-wince-gcc.exe) if we build universal package for Win64.

Also, about mozconfig, it is better if we can use the following.  (just idea)

ac_add_options --target=x86_64-pc-mingw32
HOST_CC=cl
HOST_CXX=cl
CC=cl64.py
HOST_CXX=cl64.py
CROSS_COMPILE=1

Comment 11

[Masatoshi Kimura [:emk]]

Attachment: WIP: rebased, customized start-msvc10-x64.bat is no longer required

Cross compile is not supported yet.

Comment 12

[(not currently active) Ted Mielczarek]

So your plan is to effectively build and ship two sets of binaries on Windows? I can see that working, but it means our build times would probably be >5 hours each.

Comment 13

[Makoto Kato [:m_kato]]

(In reply to comment #12)
> So your plan is to effectively build and ship two sets of binaries on
> Windows? I can see that working, but it means our build times would probably
> be >5 hours each.

Now, Win64 PGO uses about 4 hours on Tinderbox, If we create combined package, it spends 6-7 hours at least.

My idea is that 32bit plugin on 64bit firefox uses 32bit plugin-container of 32bit firefox of same version.  IPC ABI is compatible (I need fix some bugs for shared memory), so It will work.

But I have to discuss with Josh about 32-bit plugin support on 64-bit Firefox (Linux and Windows).  Although Mac version can use Universal package of Mach-O, other platforms cannot.

Comment 14

[Makoto Kato [:m_kato]]

Attachment: WIP v2

Comment 15

[Makoto Kato [:m_kato]]

Comment on attachment 539459 [details] [diff] [review]
WIP v2

If building universal build for this, it spends 7 hours (3 hours for Win32 and 4 hours for Win64) at least.  I think that this isn't good.

This fix uses 32-bit installation from registry and use plugin-container of it.
If nothing, we can use from prefs for 32-bit plugin-container path.

If this idea is OK, I will make a reviewable fix.

If bad, please suggest me about right idea.

Comment 16

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

My objections have already been noted in comment #4 and my comments following that comment

Comment 17

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

btw: there are at least a couple of other reasons using this method will break that I didn't previously note. There are likely other reasons as well since these are just off the top.
1. if the user doesn't also install the same 32 bit version of Firefox.
2. if the user updates one of the Firefox installs and not the other.

Comment 18

[Josh Aas]

Comment on attachment 539459 [details] [diff] [review]
WIP v2

I agree with Rob that this approach isn't robust enough.

Comment 19

[Makoto Kato [:m_kato]]

(In reply to comment #18)
> Comment on attachment 539459 [details] [diff] [review] [review]
> WIP v2
> 
> I agree with Rob that this approach isn't robust enough.

Josh, should I add new key like comment #5?

Although I don't test yet, I am thinking another way.
Firefox win64 extract 32-bit xulrunner into <installation path>/plugin-wrapper, firefox win64 uses 32-bit plugin-container of that xulrunner.  How about this approach?

Comment 20

[[e-mail]]

(In reply to Ted Mielczarek from comment #12)
> So your plan is to effectively build and ship two sets of binaries on
> Windows? I can see that working, but it means our build times would probably
> be >5 hours each.
Can't you build the two binaries in parallel? PGO is single-threaded anyway, so we're currently wasting CPU time waiting for it to finish. Or at least just build the parts of the 32-bit libxul needed by plugin-container.exe?

Comment 21

[Masatoshi Kimura [:emk]]

Now all of Flash, Java, Silverlight plug-in support 64-bit browsers.
Is this bug still so important?

Comment 22

[Danial Horton]

there is no 64bit
shockwave
ietab
quicktime plugin
divx plugins
windows genuine and  activation technology plugins (not that the 32bit versions actually work since Fx3.6 .....)
realplayer
Pando web booster (used in the downloading of some MMO's)
Microsoft WMP Plugin
MS Office 2010 (without installing the x64 version of office, which is not advised at this point)
Comrade (GameSpy game browser)
Canon Image Gateway Album plugin utility.

The plugins you listed are barely a handful of whats available, and of them, Silverlight and Flash 64bit are still buggy as heck.

Comment 23

[SpeciesX]

(In reply to Danial Horton from comment #22)
> there is no 64bit
> shockwave
> ietab
> quicktime plugin
> divx plugins
> windows genuine and  activation technology plugins (not that the 32bit
> versions actually work since Fx3.6 .....)
> realplayer
> Pando web booster (used in the downloading of some MMO's)
> Microsoft WMP Plugin
> MS Office 2010 (without installing the x64 version of office, which is not
> advised at this point)
> Comrade (GameSpy game browser)
> Canon Image Gateway Album plugin utility.

WMP Plugin is outdated (last update was 2007). 

> The plugins you listed are barely a handful of whats available, and of them,
> Silverlight and Flash 64bit are still buggy as heck.

I'm using flash 64bit over one year without bigger problems.

Comment 24

[[Baboo]]

(In reply to speciesx from comment #23)
>
> WMP Plugin is outdated (last update was 2007). 
> 

But still necessary sometimes. AFAIK, there is no full-fledged alternative.

Comment 25

[SpeciesX]

Opera released today Opera 64bit build and this build can also use 32bit plugins.

http://dev.opera.com/articles/view/64-bit-opera-and-out-of-process-plug-ins/

Comment 26

[s793016]

Sorry, my English is very very poor.

Maybe we can build one x64 version which can use both x64/x32 plugins at the same time.  

Maybe more simple, make a boolen switch inside about:config to choose only x64 or x32 plugins to run.

The simplest way is to build two version: one for x32 plugins, and the other for x64 plugins. Finally you need spent double time to build it.

Comment 27

[xunxun]

(In reply to s793016 from comment #26)
> Sorry, my English is very very poor.
> 
> Maybe we can build one x64 version which can use both x64/x32 plugins at the
> same time.  
> 
> Maybe more simple, make a boolen switch inside about:config to choose only
> x64 or x32 plugins to run.
> 
> The simplest way is to build two version: one for x32 plugins, and the other
> for x64 plugins. Finally you need spent double time to build it.

This is because plugin-container depends on many modules, if we can make it depend on very few small module, the bug will be fixed easily.

But bug 711386 has no progress now.

Comment 28

[Willy_ Foo_Foo]

This bug needs to be cross platform as Linux will Integrate support for cross-architecture installation of binary packages (particularly i386<->amd64, but also other combinations)

Comment 29

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

(In reply to magnumarchonbasileus from comment #28)
> This bug needs to be cross platform as Linux will Integrate support for
> cross-architecture installation of binary packages (particularly
> i386<->amd64, but also other combinations)
We typically handle each platform in a separate bug for these types of bugs so please file a new bug for Linux.

Comment 30

[Masatoshi Kimura [:emk]]

That's already present (bug 588749).

Comment 33

[xunxun]

Off the bug, I want to ask is there any methods to make x64 Fx support x86 extensions( using some dlls to complete some functions )?

Comment 34

[Danial Horton]

(In reply to SpeciesX from comment #23)
> (In reply to Danial Horton from comment #22)
> > there is no 64bit
> > shockwave
> > ietab
> > quicktime plugin
> > divx plugins
> > windows genuine and  activation technology plugins (not that the 32bit
> > versions actually work since Fx3.6 .....)
> > realplayer
> > Pando web booster (used in the downloading of some MMO's)
> > Microsoft WMP Plugin
> > MS Office 2010 (without installing the x64 version of office, which is not
> > advised at this point)
> > Comrade (GameSpy game browser)
> > Canon Image Gateway Album plugin utility.
> 
> WMP Plugin is outdated (last update was 2007). 
> 
> > The plugins you listed are barely a handful of whats available, and of them,
> > Silverlight and Flash 64bit are still buggy as heck.
> 
> I'm using flash 64bit over one year without bigger problems.

i only noticed this nonsense just now.

WMP plugin is not outdated, its required for the html5 video extension to work for crying out loud.

Comment 35

[Alex]

I think the "HTML5 Extension for Windows Media Player Firefox Plug-in" is outdated as well, the whole point of it is to allow Firefox to play H.264 videos by making it load WMP instead (Why it requires the other plugin), but Firefox can play H.264 video anyway.

As for Silverlight and Flash, they seem to be installing the 64bit versions alongside the 32bit versions. At least on my system I never attempted to install them, yet I have the latest versions available.

Comment 36

[Keloran]

I've been trying to port this into Firefox v32,

the plugins get listed as available, but the instant you go to use one (e.g. Unity Web Player) it insta crashes the plugin

the code has changed alot since the patch was originally made, is there a new version that I could take a look at, that might make this process abit easier

Thanks

Comment 37

[xunxun]

(In reply to Keloran from comment #36)
> I've been trying to port this into Firefox v32,
> 
> the plugins get listed as available, but the instant you go to use one (e.g.
> Unity Web Player) it insta crashes the plugin
> 
> the code has changed alot since the patch was originally made, is there a
> new version that I could take a look at, that might make this process abit
> easier
> 
> Thanks

I created 20.0 patch many months ago : https://github.com/xunxun1982/pcxfirefox/blob/master/patches/test/x64withx86plugin.patch

When I have time, I will creat it based on new edition again.

IPC code always changes, so maintaining the patch is very hard.

Comment 38

[(not currently active) Ted Mielczarek]

I don't think this is worth the effort. Adobe provides a 64-bit Flash plugin and we're actively trying to get rid of plugin usage in general.

Comment 39

[Josh Aas]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #38)
> I don't think this is worth the effort. Adobe provides a 64-bit Flash plugin
> and we're actively trying to get rid of plugin usage in general.

Agreed.