Detecting platform architecture (32/64/ARM) from JavaScript?

4,041 views
Skip to first unread message

Reed Riley

unread,
Dec 18, 2012, 1:11:52 PM12/18/12
to native-cli...@googlegroups.com
Is 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 Yee (余仕斌)

unread,
Dec 18, 2012, 2:17:56 PM12/18/12
to Native Client Discuss
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


--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/PJKpRqkpS1kJ.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.



--
bennet s yee
i usually don't capitalize due to mild tendonitis

David Michael

unread,
Dec 18, 2012, 5:26:33 PM12/18/12
to native-cli...@googlegroups.com

Reed Riley

unread,
Dec 19, 2012, 2:29:37 PM12/19/12
to native-cli...@googlegroups.com, dmic...@chromium.org
There's some complexity in mapping operating system and browser to NaCl bitness that I'd rather avoid maintaining.

In particular, the default Chrome for 64-bit OS X uses 32-bit NaCl, and some other operating systems (e.g., Linux) allow you to install 32-bit packages on 64-bit operating systems.

If 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.

On Tuesday, December 18, 2012 2:26:33 PM UTC-8, David Michael wrote:
On Tue, Dec 18, 2012 at 12:17 PM, Bennet Yee (余仕斌) <b...@google.com> wrote:
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


On Tue, Dec 18, 2012 at 10:11 AM, Reed Riley <john.re...@gmail.com> wrote:
Is 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



--

David Michael

unread,
Dec 19, 2012, 3:48:47 PM12/19/12
to Reed Riley, native-cli...@googlegroups.com
On Wed, Dec 19, 2012 at 12:29 PM, Reed Riley <john.re...@gmail.com> wrote:
There'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.

In 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 32-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 it would work:

Caveat: I haven't tried this. Even if it works, I agree that it's icky and brittle.


If 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.

Victor Khimenko

unread,
Dec 19, 2012, 4:06:34 PM12/19/12
to Native Client Discuss, Reed Riley
On Thu, Dec 20, 2012 at 12:48 AM, David Michael <dmic...@chromium.org> wrote:
On Wed, Dec 19, 2012 at 12:29 PM, Reed Riley <john.re...@gmail.com> wrote:
There'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.

In 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 32-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 it would work:

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.
 
Caveat: I haven't tried this. Even if it works, I agree that it's icky and brittle.


If 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.
 

On Tuesday, December 18, 2012 2:26:33 PM UTC-8, David Michael wrote:

On Tue, Dec 18, 2012 at 12:17 PM, Bennet Yee (余仕斌) <b...@google.com> wrote:
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


On Tue, Dec 18, 2012 at 10:11 AM, Reed Riley <john.re...@gmail.com> wrote:
Is 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

Reply all
Reply to author
Forward
0 new messages