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.
The distinction between winxp and winvista (and maybe win7) could be helpful in some edge cases, mainly if you have an existing DLL that's tested and working for XP and want to treat it as legacy code and develop something new for Vista and up. However, you could make an argument for skipping this distinction since the executable format for all versions of Windows derived from Windows NT is the same, so plug- in authors should be able to provide a single DLL that either knows about the different versions of Windows, or turns around and does LoadLibrary to load different DLLs (also bundled with the extension) depending on the version of Windows it detects. An alternative to ever-increasing complexity in the manifest file (bitness, OS, version of OS, common libraries available in different Linux distributions, etc.) might be to keep the manifest pretty simple (perhaps just windows/linux/osx as suggested) but have an escape hatch where you can provide a JavaScript file with a function "determinePlugin()" that would get the OS name, OS version, and other environmental information and would return the plug-in file to load. Cheers, Jói On Sep 4, 5:07 am, Simon Stewart <[email protected]> wrote: > What about different "bitness"? Most OS versions come in 32 and 64 bit > flavours, and this specification doesn't seem to allow this > differentiation. > > Simon > > > > On Fri, Sep 4, 2009 at 1:51 AM, Matt Perry <[email protected]> wrote: > > Right now we have this manifest key for plugins: "plugins": [ > > {"path": "path/to/file", "public": true} > > ] > > This won't work well for cross platform extensions. Here's a simple addition > > to address that: > > "plugins": [ > > { > > "platform_paths": [ > > {"winxp": "plug_xp.dll"}, {"winvista": "plug_vista.dll"}, {"linux": > > "libplug_linux.so"}, {"osx": "libplug_osx.so"} > > ], > > "public": false, > > "path": "fallback/path/here" > > } > > ] > > Note: the idea of keeping support for the "path" key is mostly for backwards > > compatibility. If the plugin is loaded on an OS that isn't present in the > > "platform_paths" key, we can fall back to the plugin in "path". Obviously > > it'll fail to load on the wrong platform (hopefully gracefully). > > Question: What platforms will we need to specify for different plugin > > versions? Do we need to distinguish between XP/Vista/7? > > Any other feedback? --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
