Post by David MichaelPost by Reed RileyThere's some complexity in mapping operating system and browser to NaCl
bitness that I'd rather avoid maintaining.
I agree, it's not ideal. I'm not aware of any better way in JS (maybe
others are). In general, the web platform (outside NaCl, at least) tries to
insulate you from platform differences.
Post by Reed RileyIn particular, the default Chrome for 64-bit OS X uses 32-bit NaCl
We don't ship 64-bit Chrome to OS X, so I think you can safely assume Mac
implies 32-bit NaCl.
, and some other operating systems (e.g., Linux) allow you to install
Post by Reed Riley32-bit packages on 64-bit operating systems.
I'm fairly sure the 32-bit Chrome will report 32-bit (i686), since it's
determined at compile-time. I also think it will use the 32-bit x86
sandbox. So that should also work fine But maybe somebody can confirm that
a 32-bit build of Chrome on Linux NaCl.
Windows is weird; we ship only 32-bit Chrome for Windows, but if run on a
64-bit version of Windows, we load a 64-bit nexe. But it appears that
platform is actually determined dynamically on Windows, so I actually think
https://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/win/SystemInfo.cpp&exact_package=chromium&q=windowsVersionForUAString&type=cs&l=176
Right. And this is the only reliable datapoint in the whole story. On
Windows bitness of your NaCl application must match bitness of OS
for technical reasons (you can not run 64bit NaCl applications on 32bit
Windows and you *also* can not run 32bit NaCl application on 64bit
Windows), on Linux and MacOS arbitrary mix of everything is theoretically
possible and we've just implemented what was easier.
Note: initially the plan was to use 32bit NaCl on all platforms except
Windows x64, but eventually we've just implemented what was easier to
implement: you need to provide both 32bit and 64bit binaries because of
Windows so what's the point of trying, e.g. to avoid 64bit NaCl on Linux?
This means that while current map is pretty stable (we certainly have no
incentive to make code more complex for no good reason so "bitness of NaCl
matches bitness of browser" looks like a good approach for Linux and MacOS)
but there are no guarantee that we'll not decide to change mappings in the
future for one reason or another.
Post by David MichaelCaveat: I haven't tried this. Even if it works, I agree that it's icky and
brittle.
Post by Reed RileyIf necessary, I'll write a small 'bitness detection' NaCl executable and
use that to figure out which binaries the user is going to need - but I'd
prefer to avoid that if there's some easy way to ask the NaCl runtime this
sort of question from Javascript.
We don't even have a way for JavaScript to talk to NaCl if you don't have
an nmf file embedded. This could be a handy new feature, but I wouldn't
expect anything to be implemented any time soon. You'll probably have to
use the ugly navigator.platform stuff or make a tiny nexe to solve your
problem.
Post by Reed RileyPost by David MichaelTry reading navigator.platform.
http://stackoverflow.com/**questions/7044944/jquery-**
javascript-to-detect-os-**without-a-plugin<http://stackoverflow.com/questions/7044944/jquery-javascript-to-detect-os-without-a-plugin>
https://code.google.com/**searchframe#OAMlx_jo-ck/src/**
third_party/WebKit/Source/**WebCore/platform/qt/**
UserAgentQt.cpp&exact_package=**chromium&q=%22Linux%20x86_64%**
22&type=cs&l=102<https://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/qt/UserAgentQt.cpp&exact_package=chromium&q=%22Linux%20x86_64%22&type=cs&l=102>
E.g., I get "Linux x86_64" locally.
Post by Bennet Yee (ä½ä»æ)presumably you are thinking of packaged apps and not hosted apps. one
way would be to include a set of tiny nexes that return their own arch in
response to a postmessage from javascript. :-) but i suspect you want
something even lighter weight. unfortunately i don't know of any
javascript magic that'll do that; maybe somebody else has more clue?
-bsy
Post by Reed RileyIs there any way to detect the NaCl architecture (32/64/ARM) that a
client is going to use from within JavaScript?
Specifically, I don't care at all what the actual architecture is, I
just want to know which objects NaCl's going to load from the manifest.
The application being downloaded is pretty large, so I'm caching it
explicitly using the HTML5 Filesystem API - but I don't want to download
content for unnecessary architectures.
Thanks,
Reed
--
bennet s yee
i usually don't capitalize due to mild tendonitis
--
You received this message because you are subscribed to the Google Groups
"Native-Client-Discuss" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/native-client-discuss?hl=en.
--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-client-***@googlegroups.com.
To unsubscribe from this group, send email to native-client-discuss+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.