{{+bindTo:partials.standard_nacl_article}}
NOTE:
Deprecation of the technologies described here has been announced
for platforms other than ChromeOS.
Please visit our
migration guide
for details.
This document answers some frequently asked questions about Native Client (NaCl) and Portable Native Client (PNaCl, pronounced “pinnacle”). For a high-level overview of Native Client, see the Technical Overview.
If you have questions that aren’t covered in this FAQ:
Convenience:
Portability: Native Client and Portable Native Client applications can execute on:
Portable Native client further enhances the above:
.pexe
file,
not one .nexe
file per supported architecture.For more details, refer to the history behind and comparison of NaCl and PNaCl.
See NaCl and PNaCl. In short: PNaCl works on the Open Web platform delivered by Chrome whereas NaCl only works on the Chrome Web Store.
The following are some typical use cases. For details, see the Technical Overview.
Using compute-intensive applications, including threads and SIMD, such as:
Portable Native Client and Native Client are versatile technologies which are used in many other contexts outside of Chrome.
Fast! The SPEC2k benchmarks (C, C++ and floating-point benchmarks) give the following overhead for optimized PNaCl compared to regular optimized LLVM:
x86-32 | 15% |
x86-64 | 25% |
ARM | 10% |
Note that benchmark performance is sometimes bimodal, so different use cases are likely to achieve better or worse performance than the above averages. For example floating-point heavy code usually exhibits much lower overheads whereas very branch-heavy code often performs worse.
Note that PNaCl supports performance features that are often used in native code such as threading and Portable SIMD Vectors.
For details, see:
If your code isn’t performing as close to native speed as you’d expect, let us know!
Many other technologies can be compared to Portable Native Client: Flash, Java, Silverlight, ActiveX, .NET, asm.js, etc...
Different technologies have different strengths and weaknesses. In appropriate contexts, Portable Native Client can be faster, more secure, and/or more compatible across operating systems and architectures than other technologies.
Portable Native Client complement other technologies by giving web developers a new capability: the ability to run fast, secure native code from a web browser in an architecture-independent way.
No—Native Client does not provide direct access to the OS or devices, or otherwise bypass the JavaScript security model. For more information, see later sections of this FAQ.
You can develop on Windows, Mac, or Linux, and the resulting Native Client or Portable Native Client application will run inside the Google Chrome browser on all those platforms as well as ChromeOS. You can also develop on ChromeOS with Crouton or our experimental development environment which runs within NaCl, and we’re working on self-hosting a full development environment on Portable Native Client.
Any editor+shell combination should work as well as IDEs like Eclipse, Visual Studio with the Native Client Add-In on Windows, or Xcode on Mac OSX.
You may find our Tutorial and Building instructions useful, and you can look at the code and Makefiles for the SDK examples to understand how the examples are built and run.
You’ll need to learn how to use some tools (like GCC, LLVM, make, Eclipse, Visual Studio, or Xcode) before you can get very far with the SDK. Try seaching for an introduction to GCC.
Native Client is completely open: the executable format is open and the source code is open. Right now the Native Client project is in its early stages, so it’s premature to consider Native Client for standardization.
We consistenly try to document our design and implementation and hope to standardize Portable Native Client when it gains more traction. A good example is our PNaCl bitcode reference manual.
Read about contributor ideas.
Portable Native Client uses an architecture-independent format (the
.pexe
) which can currently be translated to execute on processors
with the x86-32, x86-64, and ARM instruction set architectures, as well
as experimental support for MIPS. As new architectures come along and
become popular we expect Portable Native Client to support them without
developers having to recompile their code.
Native Client can currently execute on the same architectures as
Portable Native Client but is only supported on the Chrome Web
Store. Native Client’s .nexe
files are architecture-dependent and
cannot adapt to new architectures without recompilation, we therefore
deem them better suited to a web store than to the open web.
With Portable Native Client we deliver a system that has comparable portability to JavaScript and can adapt to new instruction set architectures without requiring recompilation. The web is better when it’s platform-independent, and we’d like it to stay that way.
Right now only C and C++ are supported directly by the toolchain in the SDK. C# and other languages in the .NET family are supported via the Mono port for Native Client. Moreover, there are several ongoing projects to support additional language runtimes (e.g. webports includes Lua, Python and Ruby) as well as to compile more languages to LLVM’s intermediate representation (e.g. support Halide, Haskell with GHC or support Fortran with flang), or transpile languages to C/C++ (source-to-source compilation). Even JavaScript is supported by compiling V8 to target PNaCl.
The PNaCl toolchain is built on LLVM and can therefore generate code from languages such as Rust, Go, or Objective-C, but there may still be a few rough edges.
If you’re interested in getting other languages working, please contact the Native Client team by way of the native-client-discuss mailing list, and read through contributor ideas.
We aim to support multiple browsers. However, a number of features that we consider requirements for a production-quality system that keeps the user safe are difficult to implement without help from the browser. Specific examples are an out-of-process plugin architecture and appropriate interfaces for integrated 3D graphics. We have worked closely with Chromium developers to deliver these features and we are eager to collaborate with developers from other browsers.
Pepper (also known as PPAPI) is a new API that lets Native Client modules communicate with the browser. Pepper supports various features that don’t have robust support in NPAPI, such as event handling, out-of-process plugins, and asynchronous interfaces. Native Client has transitioned from using NPAPI to using Pepper.
NPAPI is not supported by the Native Client SDK, and is deprecated in Chrome.
Portable Native Client supports portable SIMD vectors, as detailed in Portable SIMD Vectors.
Native Client supports SSE, AVX1, FMA3 and AVX2 (except for VGATHER) on x86 and NEON on ARM.
Yes. Native Client supports OpenGL ES 2.0.
To alert the user regarding their hardware platform’s 3D feature set before loading a large NaCl application, see Vetting the driver in Javascript.
Some GL extensions are exposed to Native Client applications, see the GLES2
file. This file is part of the GL wrapper supplied by the library
ppapi_gles2
which you’ll want to include in your project. In most cases
extensions map to extensions available on other platforms, or differ very
slightly (if they differ, the extension is usually CHROMIUM or ANGLE instead of
EXT).
Native Client and Portable Native Client both support pthreads, C11/C++11 threads, and low-level synchronization primitives (mutex, barriers, atomic read/modify/write, compare-and-exchange, etc...), thus allowing your Native Client application to utilize several CPU cores. Note that this allows you to modify datastructures concurrently without needing to copy them, which is often a limitation of shared-nothing systems. For more information see memory model and atomics and threading.
Native Client doesn’t support HTML5 Web Workers directly but can interact with JavaScript code which does.
At this time Native Client modules do not have access to serial ports, camera devices, or microphones: Native Client can only use native resources that today’s browsers can access. However, we intend to recommend such features to the standards bodies and piggyback on their efforts to make these resources available inside the browser.
You can generally think of Pepper as the C/C++ bindings to the capabilities of HTML5. The goal is for Pepper and JavaScript to evolve together and stay on par with each other with respect to features and capabilities.
Users can opt-in to sending usage statistics and crash information in Chrome, which includes usage statistics and crash information about Native Client. Crashes in your code won’t otherwise send your information to Google: Google counts the number of such crashes, but does so anonymously without sending your application’s data or its debug information.
For additional information about privacy and Chrome, see the Google Chrome privacy policy and the Google Chrome Terms of Service.
Native Client’s sandbox works by validating the untrusted code (the compiled Native Client module) before running it. The validator checks the following:
syscall
, int
, and lds
.The beauty of the Native Client sandbox is in reducing “safe” code to a
few simple rules that can be verified by a small trusted validator: the
compiler isn’t trusted. The same applies to Portable Native Client where
even the .pexe
to .nexe
translator, a simplified compiler
backend, isn’t trusted: it is validated before executing, and so is its
output.
In addition to static analysis of untrusted code, the Native Client runtime also includes an outer sandbox that mediates system calls. For more details about both sandboxes, see Native Client: A Sandbox for Portable, Untrusted x86 Code (PDF).
Google has taken several steps to ensure that Native Client’s security works, including:
Google is committed to making Native Client safer than JavaScript and other popular browser technologies. If you have suggestions for security improvements, let the team know, by way of the native-client-discuss mailing list.
Instructions on debugging the SDK examples using GDB are available. You can also debug Native Client modules with some alternative approaches.
.nexes
?By default, the applications in the /examples
folder create
architecture-independent .pexe
for Portable Native Client. To
generate a .nexe
targeting one specific architecture using the
Native Client or Portable Native Client toolchains, see the
Building instructions.
.nexe
to load?Your application does not need to make the decision of loading an
x86-32, x86-64 or ARM .nexe
explicitly—the Native Client runtime
examines a manifest file (.nmf
) to pick the right .nexe
file for
a given user. You can generate a manifest file using a Python script
that’s included in the SDK (see the Makefile
in any of the SDK
examples for an illustration of how to do so). Your HTML file specifies
the manifest filename in the src
attribute of the <embed>
tag. You can see the way the pieces fit together by examining the
examples included in the SDK.
Yes. See the "Hello, World!"
in C example in the SDK under
examples/tutorial/using_ppapi_simple/
, or the Game of Life example
under examples/demo/life/life.c
.
Native Client doesn’t directly expose any system calls from the host OS
because of the inherent security risks and because the resulting
application would not be portable across operating systems. Instead,
Native Client provides portable cross-OS abstractions wrapping or
proxying OS functionality or emulating UNIX system calls. For example,
Native Client provides an mmap()
system call that behaves much like
the standard UNIX mmap()
system call.
Google has ported several third-party libraries to Native Client; such libraries are available in the webports project. We encourage you to contribute libraries to webports, and/or to host your own ported libraries, and to let the team know about it on native-client-discuss when you do. You can also read through contributor ideas to find ideas of new projects to port.
The .nmf
, and .nexe
or .pexe
files must either be served from the
same origin as the embedding page or an origin that has been configured
correctly using CORS.
For applications installed from the Chrome Web Store the Web Store manifest must include the correct, verified domain of the embedding page.
No. Native Client and Portable Native Client applications run without modification on all supported operating systems.
However, to run on different instruction set architectures (such as x86-32, x86-64 or ARM), you currently have to either:
.nexe
file for each architecture, and
make them available on the Chrome Web Store. See target
architectures for details about which
.nexe
files will run on which architectures.In most cases you won’t have to rewrite much, if any, code. The Native
Client-specific tools, such as pnacl-clang++
or x86_64-nacl-g++
,
take care of most of the necessary changes. You may need to make some
changes to your operating system calls and interactions with external
devices to work with the web. Porting existing Linux libraries is
generally straightforward, with large libraries often requiring no
source change.
The following kinds of code may be more challenging to port:
fork
, won’t function
as-is. However, threads are supported. You can nonetheless create new
<embed>
tags in your HTML page to launch new PNaCl processes. You can even
use new .pexe
files that your existing .pexe
saved in a local
filesystem. This is somewhat akin to execve
, but the process management
has to go through postMessage
to JavaScript in order to create the new
<embed>
.open
/ fopen
/ read
/
write
/ ...). See Using NaCl I/O for more
details..pexe
isn’t loading, help!about:chrome
, and update
Chrome if you are on an older version. If
you’re already using a recent version, open about:components
and “Check
for update” for PNaCl. Note that on ChromeOS PNaCl is always up to date,
whereas on other operating systems it updates shortly after Chrome updates..pexe
must be compiled with pepper_31 SDK or higher. Update
your bundles and make sure you’re using a version of
Chrome that matches the SDK version.navigator.mimeTypes['application/x-pnacl'] !==
undefined
. This is preferred over checking the Chrome version..nexe
files never finish loading. What gives?Here are ways to resolve some common problems that can prevent loading:
about:flags
in the Chrome address bar, scroll
down to “Native Client”, click the “Enable” link, scroll down to the
bottom of the page, and click the “Relaunch Now” button (all browser
windows will restart).about:plugins
in the Chrome address bar, scroll down to “Native
Client”, and click the “Enable” link. (You do not need to relaunch
Chrome after you enable the Native Client plugin)..nexe
files are being served from a web
server. Native Client uses the same-origin security policy, which
means that modules will not load in pages opened with the file://
protocol. In particular, you can’t run the examples in the SDK by
simply dragging the HTML files from the desktop into the browser. See
Running Native Client Applications
for instructions on how to run the httpd.py mini-server included in
the SDK..nexe
files must have been compiled using SDK version 0.5 or
greater..nexe
file for your machine’s specific
instruction set architecture (x86-32, x86-64 or ARM). You can ensure
you’re loading the correct .nexe
file by building a separate
.nexe
for each architecture, and using a .nmf
manifest file to
let the browser select the correct .nexe
file. Note: the need to
select a processor-specific .nexe
goes away with Portable Native
Client.