Expose native, desktop and mobile gesture detection defaults

[chromium-blink-merge.git] / native_client_sdk / doc_generated / faq.html

{{+bindTo:partials.standard_nacl_article}}

<section id="frequently-asked-questions">
<h1 id="frequently-asked-questions">Frequently Asked Questions</h1>
<div class="contents local" id="contents" style="display: none">
<ul class="small-gap">
<li><p class="first"><a class="reference internal" href="#what-is-native-client-good-for" id="id1">What is Native Client Good For?</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#why-did-google-build-native-client" id="id2">Why did Google build Native Client?</a></li>
<li><a class="reference internal" href="#when-should-i-use-portable-native-client-instead-of-native-client" id="id3">When should I use Portable Native Client instead of Native Client?</a></li>
<li><a class="reference internal" href="#when-should-i-use-portable-native-client-native-client" id="id4">When should I use Portable Native Client / Native Client?</a></li>
<li><a class="reference internal" href="#how-fast-does-code-run-in-portable-native-client" id="id5">How fast does code run in Portable Native Client?</a></li>
<li><a class="reference internal" href="#why-use-portable-native-client-instead-of-technology-x" id="id6">Why use Portable Native Client instead of <em>&lt;technology X&gt;</em>?</a></li>
<li><a class="reference internal" href="#if-i-want-direct-access-to-the-os-should-i-use-native-client" id="id7">If I want direct access to the OS, should I use Native Client?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#development-environments-and-tools" id="id8">Development Environments and Tools</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#what-development-environment-and-development-operating-system-do-you-recommend" id="id9">What development environment and development operating system do you recommend?</a></li>
<li><a class="reference internal" href="#i-m-not-familiar-with-native-development-tools-can-i-still-use-the-native-client-sdk" id="id10">I&#8217;m not familiar with native development tools, can I still use the Native Client SDK?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#openness-and-supported-architectures-and-languages" id="id11">Openness, and Supported Architectures and Languages</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#is-native-client-open-is-it-a-standard" id="id12">Is Native Client open? Is it a standard?</a></li>
<li><a class="reference internal" href="#what-are-the-supported-instruction-set-architectures" id="id13">What are the supported instruction set architectures?</a></li>
<li><a class="reference internal" href="#do-i-have-to-use-c-or-c-i-d-really-like-to-use-another-language" id="id14">Do I have to use C or C++? I&#8217;d really like to use another language.</a></li>
<li><a class="reference internal" href="#do-you-only-support-chrome-what-about-other-browsers" id="id15">Do you only support Chrome? What about other browsers?</a></li>
<li><a class="reference internal" href="#what-s-the-difference-between-npapi-and-pepper" id="id16">What&#8217;s the difference between NPAPI and Pepper?</a></li>
<li><a class="reference internal" href="#is-npapi-part-of-the-native-client-sdk" id="id17">Is NPAPI part of the Native Client SDK?</a></li>
<li><a class="reference internal" href="#does-native-client-support-simd-vector-instructions" id="id18">Does Native Client support SIMD vector instructions?</a></li>
<li><a class="reference internal" href="#can-i-use-native-client-for-3d-graphics" id="id19">Can I use Native Client for 3D graphics?</a></li>
<li><a class="reference internal" href="#does-native-client-support-concurrency-parallelism" id="id20">Does Native Client support concurrency/parallelism?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#coming-soon" id="id21">Coming Soon</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#do-native-client-modules-have-access-to-external-devices" id="id22">Do Native Client modules have access to external devices?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#security-and-privacy" id="id23">Security and Privacy</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#what-happens-to-my-data-when-i-use-native-client" id="id24">What happens to my data when I use Native Client?</a></li>
<li><a class="reference internal" href="#how-does-native-client-prevent-sandboxed-code-from-doing-bad-things" id="id25">How does Native Client prevent sandboxed code from doing Bad Things?</a></li>
<li><a class="reference internal" href="#how-does-google-know-that-the-safety-measures-in-native-client-are-sufficient" id="id26">How does Google know that the safety measures in Native Client are sufficient?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#development" id="id27">Development</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#how-do-i-debug" id="id28">How do I debug?</a></li>
<li><a class="reference internal" href="#how-do-i-build-x86-32-x86-64-or-arm-nexes" id="id29">How do I build x86-32, x86-64 or ARM <code>.nexes</code>?</a></li>
<li><a class="reference internal" href="#how-can-my-web-application-determine-which-nexe-to-load" id="id30">How can my web application determine which <code>.nexe</code> to load?</a></li>
<li><a class="reference internal" href="#is-it-possible-to-build-a-native-client-module-with-just-plain-c-not-c" id="id31">Is it possible to build a Native Client module with just plain C (not C++)?</a></li>
<li><a class="reference internal" href="#what-unix-system-calls-can-i-make-through-native-client" id="id32">What UNIX system calls can I make through Native Client?</a></li>
<li><a class="reference internal" href="#is-my-favorite-third-party-library-available-for-native-client" id="id33">Is my favorite third-party library available for Native Client?</a></li>
<li><a class="reference internal" href="#do-all-the-files-in-an-application-need-to-be-served-from-the-same-domain" id="id34">Do all the files in an application need to be served from the same domain?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#portability" id="id35">Portability</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#do-i-have-to-do-anything-special-to-make-my-application-run-on-different-operating-systems" id="id36">Do I have to do anything special to make my application run on different operating systems?</a></li>
<li><a class="reference internal" href="#how-easy-is-it-to-port-my-existing-native-code-to-native-client" id="id37">How easy is it to port my existing native code to Native Client?</a></li>
</ul>
</li>
<li><p class="first"><a class="reference internal" href="#troubleshooting" id="id38">Troubleshooting</a></p>
<ul class="small-gap">
<li><a class="reference internal" href="#my-pexe-isn-t-loading-help" id="id39">My <code>.pexe</code> isn&#8217;t loading, help!</a></li>
<li><a class="reference internal" href="#my-nexe-files-never-finish-loading-what-gives" id="id40">My <code>.nexe</code> files never finish loading. What gives?</a></li>
</ul>
</li>
</ul>

</div><p>This document answers some frequently asked questions about Native
Client (NaCl) and Portable Native Client (PNaCl, pronounced
&#8220;pinnacle&#8221;). For a high-level overview of Native Client, see the
<a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a>.</p>
<p>If you have questions that aren&#8217;t covered in this FAQ:</p>
<ul class="small-gap">
<li>Scan through the <a class="reference internal" href="/native-client/sdk/release-notes.html"><em>Release Notes</em></a>.</li>
<li>Search through or ask on the <a class="reference internal" href="/native-client/help.html"><em>Native Client Forums</em></a>.</li>
</ul>
<h2 id="what-is-native-client-good-for">What is Native Client Good For?</h2>
<h3 id="why-did-google-build-native-client">Why did Google build Native Client?</h3>
<ul class="small-gap">
<li><strong>Performance:</strong> Native Client modules run nearly as fast as native
compiled code.</li>
<li><strong>Security:</strong> Native Client lets users run native compiled code in the
browser with the same level of security and privacy as traditional web
applications.</li>
<li><p class="first"><strong>Convenience:</strong></p>
<ul class="small-gap">
<li>Developers can leverage existing code, written in C/C++ or other
languages, in their applications without forcing users to install a
plugin.</li>
<li>This code can interact with the embedding web page as part of an
HTML and JavaScript web application, or it can be a self-contained
and immersive experience.</li>
</ul>
</li>
<li><p class="first"><strong>Portability:</strong> Native Client and Portable Native Client applications
can execute on:</p>
<ul class="small-gap">
<li>The Windows, Mac, Linux or ChromeOS operating systems.</li>
<li>Processors with the x86-32, x86-64, or ARM instruction set
architectures. Native Client also has experimental support for MIPS.</li>
</ul>
</li>
</ul>
<p>Portable Native client further enhances the above:</p>
<ul class="small-gap">
<li><strong>Performance:</strong> Each PNaCl release brings with it more performance
enhancements. Already-released applications get faster over time,
conserving user&#8217;s battery.</li>
<li><strong>Security:</strong> Users are kept secure with an ever-improving sandbox
model which adapts to novel attacks, without affecting
already-released applications.</li>
<li><strong>Convenience:</strong> Developers only need to ship a single <code>.pexe</code> file,
not one <code>.nexe</code> file per supported architecture.</li>
<li><strong>Portability:</strong> Developers and users don&#8217;t need to worry about
already-released applications not working on new hardware: PNaCl
already supports all architectures NaCl does, and as PNaCl evolves it
gains support for new processors and fully uses their capabilities.</li>
</ul>
<p>For more details, refer to the <a class="reference internal" href="/native-client/nacl-and-pnacl.html"><em>history behind and comparison of
NaCl and PNaCl</em></a>.</p>
<h3 id="when-should-i-use-portable-native-client-instead-of-native-client">When should I use Portable Native Client instead of Native Client?</h3>
<p>See <a class="reference internal" href="/native-client/nacl-and-pnacl.html"><em>NaCl and PNaCl</em></a>. In short: PNaCl works on the Open
Web platform delivered by Chrome whereas NaCl only works on the Chrome Web
Store.</p>
<h3 id="when-should-i-use-portable-native-client-native-client">When should I use Portable Native Client / Native Client?</h3>
<p>The following are some typical use cases. For details, see the
<a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a>.</p>
<ul class="small-gap">
<li>Porting existing applications or software components, written in C/C++ or
virtual machines written in C/C++, for use in a web application.</li>
<li><p class="first">Using compute-intensive applications, including threads and SIMD, such as:</p>
<ul class="small-gap">
<li>Scientific computing.</li>
<li>Handling multimedia for a web application.</li>
<li>Various aspects of web-based games, including physics engines and AI.</li>
</ul>
</li>
<li>Running untrusted code on a server or within an application (such as a plugin
system for a game).</li>
</ul>
<p>Portable Native Client and Native Client are versatile technologies which are
used in many other contexts outside of Chrome.</p>
<h3 id="how-fast-does-code-run-in-portable-native-client">How fast does code run in Portable Native Client?</h3>
<p>Fast! The SPEC2k benchmarks (C, C++ and floating-point benchmarks) give
the following overhead for optimized PNaCl compared to regular optimized
LLVM:</p>
<table border="1" class="docutils">
<colgroup>
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>x86-32</td>
<td>15%</td>
</tr>
<tr class="row-even"><td>x86-64</td>
<td>25%</td>
</tr>
<tr class="row-odd"><td>ARM</td>
<td>10%</td>
</tr>
</tbody>
</table>
<p>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.</p>
<p>Note that PNaCl supports performance features that are often used in
native code such as <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#language-support-threading"><em>threading</em></a> and
<a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#portable-simd-vectors"><em>Portable SIMD Vectors</em></a>.</p>
<p>For details, see:</p>
<ul class="small-gap">
<li><a class="reference external" href="https://www.youtube.com/watch?v=675znN6tntw&amp;list=PLOU2XLYxmsIIwGK7v7jg3gQvIAWJzdat_">PNaCl SIMD: Speed on the Web</a>.</li>
<li><a class="reference external" href="https://nativeclient.googlecode.com/svn/data/site/NaCl_SFI.pdf">Adapting Software Fault Isolation to Contemporary CPU Architectures</a> (PDF).</li>
<li><a class="reference external" href="http://research.google.com/pubs/pub34913.html">Native Client: A Sandbox for Portable, Untrusted x86 Code</a> (PDF).</li>
</ul>
<p>If your code isn&#8217;t performing as close to native speed as you&#8217;d expect,
<a class="reference internal" href="/native-client/help.html"><em>let us know</em></a>!</p>
<h3 id="why-use-portable-native-client-instead-of-technology-x">Why use Portable Native Client instead of <em>&lt;technology X&gt;</em>?</h3>
<p>Many other technologies can be compared to Portable Native Client:
Flash, Java, Silverlight, ActiveX, .NET, asm.js, etc...</p>
<p>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.</p>
<p>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.</p>
<h3 id="if-i-want-direct-access-to-the-os-should-i-use-native-client">If I want direct access to the OS, should I use Native Client?</h3>
<p>No&#8212;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.</p>
<h2 id="development-environments-and-tools">Development Environments and Tools</h2>
<h3 id="what-development-environment-and-development-operating-system-do-you-recommend">What development environment and development operating system do you recommend?</h3>
<p>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
<a class="reference external" href="https://github.com/dnschneid/crouton">Crouton</a> or our <a class="reference external" href="https://www.youtube.com/watch?v=OzNuzBDEWzk&amp;list=PLOU2XLYxmsIIwGK7v7jg3gQvIAWJzdat_">experimental development environment which runs within NaCl</a>,
and we&#8217;re working on self-hosting a full development environment on Portable
Native Client.</p>
<p>Any editor+shell combination should work as well as IDEs like Eclipse,
Visual Studio with the <a class="reference internal" href="/native-client/devguide/devcycle/vs-addin.html"><em>Native Client Add-In</em></a> on Windows, or Xcode on Mac OSX.</p>
<h3 id="i-m-not-familiar-with-native-development-tools-can-i-still-use-the-native-client-sdk">I&#8217;m not familiar with native development tools, can I still use the Native Client SDK?</h3>
<p>You may find our <a class="reference internal" href="/native-client/devguide/tutorial/index.html"><em>Tutorial</em></a> and <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building
instructions</em></a> useful, and you can look at
the code and Makefiles for the SDK examples to understand how the
examples are built and run.</p>
<p>You&#8217;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 <a class="reference external" href="https://www.google.com/search?q=gcc+introduction">introduction to GCC</a>.</p>
<h2 id="openness-and-supported-architectures-and-languages">Openness, and Supported Architectures and Languages</h2>
<h3 id="is-native-client-open-is-it-a-standard">Is Native Client open? Is it a standard?</h3>
<p>Native Client is completely open: the executable format is open and the
<a class="reference external" href="https://code.google.com/p/nativeclient/">source code is open</a>. Right
now the Native Client project is in its early stages, so it&#8217;s premature
to consider Native Client for standardization.</p>
<p>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 <a class="reference internal" href="/native-client/reference/pnacl-bitcode-abi.html"><em>PNaCl bitcode reference manual</em></a>.</p>
<h3 id="what-are-the-supported-instruction-set-architectures">What are the supported instruction set architectures?</h3>
<p>Portable Native Client uses an architecture-independent format (the
<code>.pexe</code>) 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.</p>
<p>Native Client can currently execute on the same architectures as
Portable Native Client but is only supported on the Chrome Web
Store. Native Client&#8217;s <code>.nexe</code> 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.</p>
<p>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&#8217;s platform-independent, and we&#8217;d like it to stay that way.</p>
<h3 id="do-i-have-to-use-c-or-c-i-d-really-like-to-use-another-language"><span id="other-languages"></span>Do I have to use C or C++? I&#8217;d really like to use another language.</h3>
<p>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 <a class="reference external" href="https://github.com/elijahtaylor/mono">Mono port</a> for
Native Client. Moreover, there are several ongoing projects to support
additional language runtimes (e.g. <a class="reference external" href="https://code.google.com/p/naclports/source/browse#svn%2Ftrunk%2Fsrc%2Fexamples%2Ftools">naclports supports Lua, Python and Ruby</a>)
as well as to compile more languages to LLVM&#8217;s intermediate representation
(e.g. support <a class="reference external" href="http://halide-lang.org/">Halide</a>, Haskell with <a class="reference external" href="http://www.haskell.org/ghc/docs/latest/html/users_guide/code-generators.html">GHC</a> or support Fortran with <a class="reference external" href="https://flang-gsoc.blogspot.ie/2013/09/end-of-gsoc-report.html">flang</a>), or
transpile languages to C/C++ (source-to-source compilation).</p>
<p>If you&#8217;re interested in getting other languages working, please contact the
Native Client team by way of the <a class="reference external" href="https://groups.google.com/group/native-client-discuss">native-client-discuss</a> mailing list.</p>
<h3 id="do-you-only-support-chrome-what-about-other-browsers">Do you only support Chrome? What about other browsers?</h3>
<p>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.</p>
<h3 id="what-s-the-difference-between-npapi-and-pepper">What&#8217;s the difference between NPAPI and Pepper?</h3>
<p><a class="reference internal" href="/native-client/pepper_stable/index.html"><em>Pepper</em></a> (also known as PPAPI) is a new API that
lets Native Client modules communicate with the browser. Pepper supports
various features that don&#8217;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.</p>
<h3 id="is-npapi-part-of-the-native-client-sdk">Is NPAPI part of the Native Client SDK?</h3>
<p>NPAPI is not supported by the Native Client SDK, and is <a class="reference external" href="http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html">deprecated in Chrome</a>.</p>
<h3 id="does-native-client-support-simd-vector-instructions">Does Native Client support SIMD vector instructions?</h3>
<p>Native Client currently supports SSE on x86 and NEON on ARM. Support for
AVX on x86 is under way.</p>
<p>Portable Native Client supports portable SIMD vectors, as detailed in
<a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#portable-simd-vectors"><em>Portable SIMD Vectors</em></a>.</p>
<h3 id="can-i-use-native-client-for-3d-graphics">Can I use Native Client for 3D graphics?</h3>
<p>Yes. Native Client supports <a class="reference external" href="https://www.khronos.org/opengles/">OpenGL ES 2.0</a>.</p>
<p>To alert the user regarding their hardware platform&#8217;s 3D feature set
before loading a large NaCl application, see <a class="reference internal" href="/native-client/devguide/coding/3D-graphics.html"><em>Vetting the driver in
Javascript</em></a>.</p>
<p>Some GL extensions are exposed to Native Client applications, see the <a class="reference external" href="https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/lib/gl/gles2/gles2.c">GLES2
file</a>.  This file is part of the GL wrapper supplied by the library
<code>ppapi_gles2</code> which you&#8217;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).</p>
<h3 id="does-native-client-support-concurrency-parallelism">Does Native Client support concurrency/parallelism?</h3>
<p>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 <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#memory-model-and-atomics"><em>memory model and atomics</em></a> and <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#language-support-threading"><em>threading</em></a>.</p>
<p>Native Client doesn&#8217;t support HTML5 Web Workers directly but can
interact with JavaScript code which does.</p>
<h2 id="coming-soon">Coming Soon</h2>
<h3 id="do-native-client-modules-have-access-to-external-devices">Do Native Client modules have access to external devices?</h3>
<p>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&#8217;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.</p>
<p>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.</p>
<h2 id="security-and-privacy">Security and Privacy</h2>
<h3 id="what-happens-to-my-data-when-i-use-native-client">What happens to my data when I use Native Client?</h3>
<p>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&#8217;t otherwise send your
information to Google: Google counts the number of such crashes, but
does so anonymously without sending your application&#8217;s data or its debug
information.</p>
<p>For additional information about privacy and Chrome, see the <a class="reference external" href="https://www.google.com/chrome/intl/en/privacy.html">Google Chrome
privacy policy</a> and the <a class="reference external" href="https://www.google.com/chrome/intl/en/eula_text.html">Google Chrome Terms of Service</a>.</p>
<h3 id="how-does-native-client-prevent-sandboxed-code-from-doing-bad-things">How does Native Client prevent sandboxed code from doing Bad Things?</h3>
<p>Native Client&#8217;s sandbox works by validating the untrusted code (the
compiled Native Client module) before running it. The validator checks
the following:</p>
<ul class="small-gap">
<li><strong>Data integrity:</strong> No loads or stores are permitted outside of the
data sandbox. In particular this means that once loaded into memory,
the binary is not writable. This is enforced by operating system
protection mechanisms. While new instructions can be inserted at
runtime to support things like JIT compilers, such instructions will
be subject to runtime verification according to the following
constraints before they are executed.</li>
<li><strong>No unsafe instructions:</strong> The validator ensures that the Native
Client application does not contain any unsafe instructions. Examples
of unsafe instructions are <code>syscall</code>, <code>int</code>, and <code>lds</code>.</li>
<li><strong>Control flow integrity:</strong> The validator ensures that all direct and
indirect branches target a safe instruction.</li>
</ul>
<p>The beauty of the Native Client sandbox is in reducing &#8220;safe&#8221; code to a
few simple rules that can be verified by a small trusted validator: the
compiler isn&#8217;t trusted. The same applies to Portable Native Client where
even the <code>.pexe</code> to <code>.nexe</code> translator, a simplified compiler
backend, isn&#8217;t trusted: it is validated before executing, and so is its
output.</p>
<p>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 <a class="reference external" href="http://research.google.com/pubs/pub34913.html">Native Client: A Sandbox for Portable, Untrusted x86 Code</a>
(PDF).</p>
<h3 id="how-does-google-know-that-the-safety-measures-in-native-client-are-sufficient">How does Google know that the safety measures in Native Client are sufficient?</h3>
<p>Google has taken several steps to ensure that Native Client&#8217;s security works,
including:</p>
<ul class="small-gap">
<li>Open source, peer-reviewed papers describing the design.</li>
<li>A <a class="reference internal" href="/native-client/community/security-contest/index.html"><em>security contest</em></a>.</li>
<li>Multiple internal and external security reviews.</li>
<li>The ongoing vigilance of our engineering and developer community.</li>
</ul>
<p>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 <a class="reference external" href="https://groups.google.com/group/native-client-discuss">native-client-discuss</a> mailing list.</p>
<h2 id="development">Development</h2>
<h3 id="how-do-i-debug">How do I debug?</h3>
<p>Instructions on <a class="reference internal" href="/native-client/sdk/examples.html#debugging-the-sdk-examples"><em>debugging the SDK examples</em></a> using GDB are available. You can also
debug Native Client modules with some <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html"><em>alternative approaches</em></a>.</p>
<h3 id="how-do-i-build-x86-32-x86-64-or-arm-nexes">How do I build x86-32, x86-64 or ARM <code>.nexes</code>?</h3>
<p>By default, the applications in the <code>/examples</code> folder create
architecture-independent <code>.pexe</code> for Portable Native Client. To
generate a <code>.nexe</code> targetting one specific architecture using the
Native Client or Portable Native Client toolchains, see the
<a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>Building instructions</em></a>.</p>
<h3 id="how-can-my-web-application-determine-which-nexe-to-load">How can my web application determine which <code>.nexe</code> to load?</h3>
<p>Your application does not need to make the decision of loading an
x86-32, x86-64 or ARM <code>.nexe</code> explicitly&#8212;the Native Client runtime
examines a manifest file (<code>.nmf</code>) to pick the right <code>.nexe</code> file for
a given user. You can generate a manifest file using a Python script
that&#8217;s included in the SDK (see the <code>Makefile</code> in any of the SDK
examples for an illustration of how to do so). Your HTML file specifies
the manifest filename in the <code>src</code> attribute of the <code>&lt;embed&gt;</code>
tag. You can see the way the pieces fit together by examining the
examples included in the SDK.</p>
<h3 id="is-it-possible-to-build-a-native-client-module-with-just-plain-c-not-c">Is it possible to build a Native Client module with just plain C (not C++)?</h3>
<p>Yes. See the <code>&quot;Hello, World!&quot;</code> in C example in the SDK under
<code>examples/tutorial/using_ppapi_simple/</code>, or the Game of Life example
under <code>examples/demo/life/life.c</code>.</p>
<h3 id="what-unix-system-calls-can-i-make-through-native-client">What UNIX system calls can I make through Native Client?</h3>
<p>Native Client doesn&#8217;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 <code>mmap()</code> system call that behaves much like
the standard UNIX <code>mmap()</code> system call.</p>
<h3 id="is-my-favorite-third-party-library-available-for-native-client">Is my favorite third-party library available for Native Client?</h3>
<p>Google has ported several third-party libraries to Native Client; such libraries
are available in the <a class="reference external" href="https://code.google.com/p/naclports">naclports</a> project. We encourage you to contribute
libraries to naclports, and/or to host your own ported libraries, and to let the
team know about it on <a class="reference external" href="https://groups.google.com/group/native-client-discuss">native-client-discuss</a> when you do.</p>
<h3 id="do-all-the-files-in-an-application-need-to-be-served-from-the-same-domain">Do all the files in an application need to be served from the same domain?</h3>
<p>The <code>.nmf</code>, and <code>.nexe</code> or <code>.pexe</code> files must either be served from the
same origin as the embedding page or an origin that has been configured
correctly using <a class="reference external" href="http://en.wikipedia.org/wiki/Cross-origin_resource_sharing">CORS</a>.</p>
<p>For applications installed from the Chrome Web Store the Web Store manifest
must include the correct, verified domain of the embedding page.</p>
<h2 id="portability">Portability</h2>
<h3 id="do-i-have-to-do-anything-special-to-make-my-application-run-on-different-operating-systems">Do I have to do anything special to make my application run on different operating systems?</h3>
<p>No. Native Client and Portable Native Client applications run without
modification on all supported operating systems.</p>
<p>However, to run on different instruction set architectures (such as
x86-32, x86-64 or ARM), you currently have to either:</p>
<ul class="small-gap">
<li>Use Portable Native Client.</li>
<li>Build and supply a separate <code>.nexe</code> file for each architecture, and
make them available on the Chrome Web Store. See <a class="reference internal" href="/native-client/devguide/devcycle/building.html"><em>target
architectures</em></a> for details about which
<code>.nexe</code> files will run on which architectures.</li>
</ul>
<h3 id="how-easy-is-it-to-port-my-existing-native-code-to-native-client">How easy is it to port my existing native code to Native Client?</h3>
<p>In most cases you won&#8217;t have to rewrite much, if any, code. The Native
Client-specific tools, such as <code>pnacl-clang++</code> or <code>x86_64-nacl-g++</code>,
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.</p>
<p>The following kinds of code may be more challenging to port:</p>
<ul class="small-gap">
<li>Code that does direct TCP/IP or UDP networking. For security reasons
these APIs are only available to packaged applications, not on the
open web, after asking for the appropriate permissions. Native Client
is otherwise restricted to the networking APIs available in the
browser.</li>
<li>Code that creates processes, including UNIX forks. Creating processes
is not supported for security reasons. However, threads are supported.</li>
<li>Code that needs to do local file I/O. Native Client is restricted to
accessing URLs and to local storage in the browser (the Pepper file I/O API
has access to the same per-application storage that JavaScript has via Local
Storage). HTML5 File System can be used, among others. For POSIX compatabiliy
the Native Client SDK includes a library called nacl_io which allows the
application to interact with all these types of files via standard POSIX I/O
functions (e.g. open/fopen/read/write/...). See <a class="reference internal" href="/native-client/devguide/coding/nacl_io.html"><em>Using NaCl I/O</em></a> for more details.</li>
</ul>
<h2 id="troubleshooting"><span id="faq-troubleshooting"></span>Troubleshooting</h2>
<h3 id="my-pexe-isn-t-loading-help">My <code>.pexe</code> isn&#8217;t loading, help!</h3>
<ul class="small-gap">
<li>You must use Google Chrome version 31 or greater for Portable Native
Client. Please <a class="reference external" href="http://www.google.com/chrome/">upgrade now</a> if you are
not. If you&#8217;re already using a recent version,  open <code>about:components</code> and
&#8220;Check for update&#8221; for PNaCl. Find your version of chrome by openning
<code>about:chrome</code>.</li>
<li>A PNaCl <code>.pexe</code> must be compiled with pepper_31 SDK or higher. <a class="reference internal" href="/native-client/sdk/download.html#updating-bundles"><em>Update
your bundles</em></a> and make sure you&#8217;re using a version of
Chrome that matches the SDK version.</li>
<li>Your application can verify that Portable Native Client is supported
in JavaScript with <code>navigator.mimeTypes['application/x-pnacl'] !==
undefined</code>. This is preferred over checking the Chrome version.</li>
</ul>
<h3 id="my-nexe-files-never-finish-loading-what-gives">My <code>.nexe</code> files never finish loading. What gives?</h3>
<p>Here are ways to resolve some common problems that can prevent loading:</p>
<ul class="small-gap">
<li>You must use Google Chrome version 14 or greater for Native Client.</li>
<li>If you haven&#8217;t already done so, enable the Native Client flag in
Google Chrome. Type <code>about:flags</code> in the Chrome address bar, scroll
down to &#8220;Native Client&#8221;, click the &#8220;Enable&#8221; link, scroll down to the
bottom of the page, and click the &#8220;Relaunch Now&#8221; button (all browser
windows will restart).</li>
<li>Verify that the Native Client plugin is enabled in Google Chrome. Type
<code>about:plugins</code> in the Chrome address bar, scroll down to &#8220;Native
Client&#8221;, and click the &#8220;Enable&#8221; link. (You do not need to relaunch
Chrome after you enable the Native Client plugin).</li>
<li>Make sure that the <code>.nexe</code> 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 <code>file://</code>
protocol. In particular, you can&#8217;t run the examples in the SDK by
simply dragging the HTML files from the desktop into the browser. See
<a class="reference internal" href="/native-client/devguide/devcycle/running.html"><em>Running Native Client Applications</em></a>
for instructions on how to run the httpd.py mini-server included in
the SDK.</li>
<li>The <code>.nexe</code> files must have been compiled using SDK version 0.5 or
greater.</li>
<li>You must load the correct <code>.nexe</code> file for your machine&#8217;s specific
instruction set architecture (x86-32, x86-64 or ARM). You can ensure
you&#8217;re loading the correct <code>.nexe</code> file by building a separate
<code>.nexe</code> for each architecture, and using a <code>.nmf</code> manifest file to
let the browser select the correct <code>.nexe</code> file. Note: the need to
select a processor-specific <code>.nexe</code> goes away with Portable Native
Client.</li>
<li>If things still aren&#8217;t working, <a class="reference internal" href="/native-client/help.html"><em>ask for help</em></a>!</li>
</ul>
</section>

{{/partials.standard_nacl_article}}