Yes, you're right, Chrome's multi-process architecture would let you host the plug-in in a 32-bit process even if the rest of Chrome is 64- bit. However, if the extension author wants to provide both 32-bit and 64-bit versions of the plug-in you'd need to have a way to provide at least the filenames of both.
The "content sniffing" approach is interesting, maybe it could be applied generically to check all the executable files listed by the author, and determine the right one for the current platform? :) Cheers, Jói On Sep 4, 12:29 pm, Amanda Walker <[email protected]> wrote: > On Fri, Sep 4, 2009 at 10:55 AM, Jói<[email protected]> wrote: > > At least on Windows, the NPAPI plug-in would be loaded into the Chrome > > process, so there would need to be a flag to select between 32-bit and > > 64-bit versions of the plug-in if Chrome starts being available as a > > native 64-bit process on Windows. Today the situation is that you run > > 32-bit Chrome on 64-bit Windows, so it needs 32-bit DLLs. > > Couldn't we have 64-bit browser & render processes with a 32-bit > plugin process? It seems simpler to examine the DLL and launch the > appropriate type of host process rather than hard-coding that into the > manifest (this is what we hope to do for Mac OS X once we have a > 64-bit build, for example). > > --Amanda --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
