Native Client

Application Structure

This document describes the general structure of a Native Client application. It assumes you are familiar with the material presented in the Technical Overview.

Application components

A Native Client application typically contains the following components:

  • an HTML file
  • JavaScript code, which can be included in the HTML file or contained in one or more separate .js files
  • CSS styles, which can be included in the HTML file or contained in one or more separate .css files
  • a Native Client manifest file (with a .nmf extension) that specifies how to load a Native Client module for different processors
  • a Native Client module, written in C or C++, and compiled into one or more executable files (with a .nexe extension) for different processors

Applications that are published in the Chrome Web Store also include a Chrome Web Store manifest file (manifest.json) and one or more icon files.

HTML file and the <embed> element

The <embed> element in an HTML file triggers the loading of a Native Client module and specifies the rectangle on the web page that is managed by the module. To load the "Hello, World" SDK example, a web page would include an <embed> element that looks like this:

<embed name="nacl_module"
  id="hello_world"
  width=200 height=200
  src="hello_world.nmf"
  type="application/x-nacl" />

In the <embed> element:

name
is the DOM name attribute for the Native Client module ("nacl_module" is often used as a convention)
id
specifies the DOM ID for the Native Client module
width, height
specify the size in pixels of the rectangle on the web page that is managed by the Native Client module (if the width and height are 0 the module will not have a visible view)
src
refers to the Native Client manifest file that is used to determine which version of a module to load based on the architecture of the user's computer (see the following section for more information)
type
specifies the MIME type of the embedded content; for Native Client modules the type must be "application/x-nacl"

Manifest files

Native Client applications have two types of manifest files: a Chrome Web Store manifest file and a Native Client manifest file.

A Chrome Web Store manifest file is a file with information about a web application that is published in the Chrome Web Store. This file, named manifest.json, is required for applications that are published in the Chrome Web Store. For more information about this file see Distributing Your Application and the Chrome Web Store manifest file format.

A Native Client manifest file is a file that specifies which Native Client module (executable) to load for each of the supported end-user computer architectures (for example, x86-32, x86-64, or ARM). This file is required for all Native Client applications. The extension for this file is .nmf.

The browser uses the Native Client manifest file to determine which compiled Native Client module to load for a given end-user computer architecture. In most cases, you can use the Python script provided with the SDK to create a manifest file for your application as part of the build process (see Building Native Client Modules or the Makefile in any of the SDK examples for an illustration of how to do so). If you're curious about the details, check out the complete manifest file specification on the Chromium website.

Continuing the example above, the manifest file specified in the <embed> element (hello_world.nmf) contains these lines:

{
"program": {
  "x86-32": {"url": "hello_world-32.nexe"},
  "x86-64": {"url": "hello_world-64.nexe"},
  }
}

The simplest manifest file contains a JSON dictionary with a single top-level key/value pair: the "program" key and a value consisting of a nested dictionary. The nested dictionary contains keys corresponding to the names of the supported computer architectures, and values referencing the file to load for a given architecture, specifically, the URL of the .nexe file, given by the "url" key. URLs are specified relative to the location of the manifest file.

The manifest example above represents a Native Client module that is statically linked at build time. All of the module's code is contained in a single executable .nexe file. It is also possible to build a Native Client module that is dynamically linked at runtime. In that case the .nexe file will not contain all of a program's object code, some of the object code will be in shared objects (libraries) that are linked at runtime. If you build a Native Client module that uses dynamic linking the manifest file will be more complicated; it must include entries pointing to all the shared objects the module could load. See Dynamic Linking and Loading with glibc for all the details.

Modules and instances

A Native Client module is C or C++ code compiled into an executable .nexe file.

An instance of a module is a rectangle on a web page that is managed by the module. An instance may have a dimension of width=0 and height=0, meaning that the instance does not have any visible component on the web page. An instance of the module is created by including an <embed> element in a web page, as described above.

A web page can have multiple Native Client <embed> elements, and the same module may appear in more than one element on the page. Native Client runs each instance in its own process. If a page contains multiple <embed> elements Native Client will create one process for each embedded instance, even if the same module is used multiple times.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.