Specifies the main program to be executed in the native client environment. For a statically linked executable or portable native client executable, this is the only executable code used. For a dynamically linked executable, this is currently the dynamic loader used to load the main program and dynamic libraries. For native client applications, the program section is a dictionary of supported instruction set ("ISA") architectures (currently the choices are "x86-32", "x86-64", and "arm") and the URLs where the appropriate native client executable (nexe) for that instruction set may be found.
For portable native client, the dictionary can only contain one entry, reflecting that there is one portable executable (pexe). As this pexe must be translated, the dictionary contains an entry specifying it is the translated form of an URL. Developers can optionally specify an optimization level hint, which is a number (zero and higher). Higher numbers mean more optimization effort (which also takes longer to translate the first time).
Specifies a set of file resources to be used by a native client application. For a dynamically linked executable (not supported under Portable Native Client), this includes the main program and dynamic libraries. For each entry that corresponds to a dynamic library is a dictionary of supported instruction sets (currently the choices are "x86-32", "x86-64", and "arm") and the URLs where the appropriate native client shared object (so) for that instruction set may be found.
For other types of files each entry may be a dictionary containing supported instruction sets or possibly the "portable" architecture, which matches all. If specific versions for instruction sets are required, they may use the dictionary entries for those instruction sets.
For portable native client ordinary files, only the "portable " architecture may be specified.
NaCl newlib (statically linked) executable
NaCl glibc (see NaCl Manifest File Format for GLibC)
Portable Native Client
Manifests are validated before the nexe is started. Schema validation ensures that each manifest
The main nexe for the application is determined by looking up the current ISA in the ISA dictionary specified in the "program" dictionary. Manifest schema validation initially checks that the manifest has a "program" dictionary entry for the ISA of the browser, and failure to provide one is a load error.All URLs contained in a manifest are resolved relative to the URL of the manifest. If the manifest was specified as a data URI, the URLs must all be absolute.
All files (shared objects and other assets, typically) are looked up by a UTF8 string file name, through an interface from the nexe TBD. From this we lookup the "files" dictionary entry corresponding to that file name. Failure to find that name in the "files" section is a run-time error. The matching rule for all files is from most to least specific. That is, if there is an exact match for the current ISA (e.g., “x86-32”) it is used in preference to more general “portable”.