Inside Google Native Client for x86 binaries

Last week, Google announced a new version of its SDK for Native Client (aka NaCl, in a riff on the chemical formula for salt). For those who don't recall, NaCl is the technology I once called "Google's craziest idea yet." In a nutshell, it allows developers to deliver code modules for Web applications in the form of native x86 binaries that execute on the user's bare CPU -- no interpreter, no virtual machine, no nothing.

I called the idea crazy, but it's really crazy clever. As Native Client continues to evolve, I thought it was high time I checked under the hood to see how this nutball idea actually worked in practice. To that end, I downloaded the new SDK, fired up my toolkit, and put a few of Google's demo NaCl applications through their paces.

[ Peter Wayner explains how to develop HTML-based mobile apps and escape the app store. | Stay up to date on the key programming news and issues with InfoWorld's Developer World newsletter. Sign up today! ]

Old tools for a new kind of Web app
NaCl may support a variety of languages in the future, but for now, NaCl modules are written in C or C++ and compiled using a tool chain based on the Gnu C Compiler (GCC). The process will be familiar to Java or .Net developers, but Web developers who are used to interpreted languages such as PHP, Python, and JavaScript may experience a learning curve. (Even Java and C# programmers may be confounded by C's header files -- welcome to the good old days!)

I was a little dismayed by the complexity of the modules themselves. One of Google's examples was a trivial module that could return a number to the browser and reverse a string of text. That simple demo comprised 306 lines of C source code and 101 lines of JavaScript and HTML. Admittedly, a lot of that was explanatory comments -- still, "Hello, world" it ain't.

Once compiled, NaCl modules are not ordinary executables. They carry a .nexe extension, and they won't run on the server itself or anywhere outside the NaCl environment. The upshot is that it doesn't matter what platform you develop them on; I built the SDK's examples on a Linux workstation and served them to a Windows 7 client with no hiccups.

Hosting modules is relatively straightforward, if a little cumbersome. Each module must include a manifest written in JSON that identifies the various files associated with it. The module must be invoked using an tag in an HTML file, and then JavaScript handles the job of communicating between the NaCl module and the application running in the browser. All of the necessary files are hosted on an ordinary Web server, just like any other Web application. The server itself needs no special configuration; the MIME type of the .nexe files is specified in the tag.

Off and stumbling with NaCl
To see NaCl apps in action, you need a browser that supports Native Client. For now, that means Chrome 10 or later, and you need to explicitly enable NaCl, either with a command-line option or through Chrome's experimental features panel. Once NaCl is enabled, Chrome warns you that security and stability will suffer -- don't try this at home, kids.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.