|
FAQ
Frequently asked questions
This page answers the most commonly asked questions about Native Client. If you don't find the answer to your question here, please try the discussion group. Also sign up for the announcement group. ContentsGeneral Native Client QuestionsWhat is Native Client?Native Client is an open-source research technology from Google for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. Why is the download so large?As this release is mainly intended for the security and research communities, we focused on making them self-contained, and making it build robustly, at the cost of download size. For the "nacl_mac" download, here's what you get (uncompressed sizes):
One download gives you everything you need to try the system, build your own Native Client modules, and even build the SDK, plugins, and secure module container. What's the process for becoming a contributor?Before sending us any code, please sign a Contributor License Agreement (CLA). The CLA protects you and us.
Once you've signed the CLA, you can contribute code by posting the diffs to the Native Client Discuss group. Implementation QuestionsWhy doesn't Native Client work on 64-bit Windows?The short answer is that we intend to support 64-bit Windows, but it's going to take some time because our 32-bit Windows solution depends on APIs that aren't in some 64-bit versions. For the long answer, see the discussion group post. Why does Native Client use a whitelist for the URLs of untrusted modules?The whitelist is a precaution while we work on hardening the system and on features that are required for defense in depth. Eventually, you should be able to load Native Client modules from any http URL. How can I make Native Client load modules from non-localhost URLs?Edit the whitelist in npapi_plugin/origin.cc. For example, if you want to load modules from a Google Code project named kw-test, add http://kw-test.googlecode.com like this: bool OriginIsInWhitelist(std::string origin) {
static char const *allowed_origin[] = {
"http://localhost",
"http://localhost:80",
"http://localhost:5103",
"http://kw-test.googlecode.com", // NEW: WHITELIST MY PROJECT'S WEBSITE
};
...
}After modifying the whitelist, rebuild as described in Building Native Client, and then reinstall as described in Getting Started. Build/Install QuestionsWhy isn't the plug-in loading?Assuming you've already installed the plug-in, verify that all files required by the plug-in are in place. For example, on Windows three files are required: sel_ldr.exe, SDL.dll, and npGoogleNaClPlugin.dll. See FilesInstalled for details. Why is make failing in cygwin (Windows)?See the explanation and workaround in the discussion group: notes for makefiles, cygwin, and windows. I see a warning in my Windows build: "is Pywin32 present?" Should I worry?No, not as long as your build finished successfully. This message is generated by our build system and means that an optional component has not been found. | |
► Sign in to add a comment
Can we think of this for example, as a .NET platform detached from its desktop roots?
I would think it more as being able to use C/C++/Java instead of Javascript. You guys are trying to make javascript faster (Chrome) AND replace it at the same time?
Is this meant to only run on Intel processors? Or will it have an X86 emulator if you run on ARM, Playstation, Nintendo, RS6000, etc processors?
sounds like we need an explanation here =)
Any idea of when OpenGL support might be added to the Native Client API?
p.s. This is a really exciting development that we've been waiting for literally for years - don't listen to the naysayers!
Could this be the end for Javascript?!?!? ... Thank Jesus, Thank Buddha, Thank Mohammed, Thank Allah, Thank Baal, Thank every f*kin God in the book
Don't get me wrong, I don;t love javascript. But on the other hand, what are we to do, build gmail-like stuff in C/C++/Whatever? Does that make more sense? I thought the idea of various kinds of scripting was ease of use, rapid development, fast learning curve, etc. I mean, ok, maybe its better to have stronger languages for server based stuff than php/asp/whatever, but for the client side...?
The idea is very interesting, thanks for putting this out.
btw, would it be safe enough to be useful? i mean, Wouldn't a VM idea (like .net/java) be a better way to go?
very interesting.
@cbaltatescu: what about client-side cool stuff, multimedia/video games, whatever(just like the screenshot)...ha yes there is something called hmm.. flash?
Is Native Client somewhat similiar to vx32?
Or uses the same or similiar techniques?
zarutian: It looks like they're pretty similar. Vx32 translates code into something that's safe and aligns jump targets; NaCl has the compiler generate safe code and just verifies it. The NaCl paper mentions Vx32.
It looks like neither NaCl nor Vx32 can run 64-bit code, because 64-bit mode does away with memory segmentation, which the sandboxes need in order to restrict reads and writes.
Wonder where that will lead, since, if people end up liking this whole native-code sandboxing thing, someday we will want 64-bit code.
There might someday be a sandbox based on processors' built-in virtualization technology, depending on where that technology goes. The NaCl paper mentions existing virtualization-based approaches but says there are portability and speed problems now. Fair enough.
Or processor makers might someday extend x86-64 to have just the memory-isolation features NaCl and friends need. Lightweight sandboxing of parts of an process seems like it could be a valuable technology, so it's not an insane idea.
Or we might end up with might something like existing programming language VMs (or a software-only x86-64 VM) but closer to metal: instruction sequences would either have to stay verifiably within the sandbox address space or be replaced with a safe callout.
Heady stuff. I guess first we have to see how the NaCl saga plays out in the real world.
Also, check out this useful Slashdot comment: http://tech.slashdot.org/comments.pl?sid=1056231&cid=26048381
Well, let's skip to the chase. What kind of FPS is Quake getting right now?
A little question: why don't you use Java? - Java is too slow, I don't think it because the CPUs can now run the java code as fast as the native code, - Java is proprietary? Not at all, there are groups of companies that work on new specs. - Java requests a heavy JRE to work. JRE is now as light as the other browser plugins - Java is not secure. Java has the best security model - Java is not documented. Java world has the best end complete documentation for all its apis and technologies - Java is not portable. No comment: java can run everywhere
So if google wants to develope a new WEB technology, can develope a better JRE instead of a plugin for the native x86
We come on google maps, we move a map... Also we do not notice, that at this time the computer takes part in the distributed calculations and counts parametres of a nuclear bomb...
The present day JRE is not as light as a browser plugin is. I use my college mail which uses java applets. it works with lotus i think. whenever i access it, my firefox gets stuck for a second. If Java JRE will get better in terms of heaviness...etc then it would be a good option. But I still think that giving flexibility of coding in different languages is always a better option.
So, I wonder how this will all play out. I'm sure Microsoft is planning for Silverlight to become more than just a video player and rich-media presentation viewer AKA Adobe Flash replacement. Unlike Flash which basically uses a modified form of javascript, Silverlight is an embedded version of the .NET CLR virtual machine, allowing client-side programming to be done in stronger languages such as C#, managed C++, VB.NET, IronPython?, IronRuby?, and anything else that can target the CLR.
Think of it as a way to run any binary (providing it does not do prohibited stuff) that can be produced by GCC.
GCC can compile binary code from C, C++, Objective-C, Fortran, Java, and Ada and of course assembly. You could also port you favorite scripting engine easily like python and the like and use it instead.
It's binary code so it's as much fast as you can get.
Regarding security applications can not directly access your hard drive to write nor use the network. And it checks the binary instructions for bad combinaison.
It can use libraries like SDL. Others will certainly follow like OpenGL, xvid, ogg and has certainly h.264 and other open-source libraries.
And it's open-source so unlike Flash or .NET you will be able to use any piece of code or open-source project to create your application : you are not limited to what that framework give you.
You could create a video or imaging editing software using HD video or hi-ref picture with an OpenGL 3D like user interface and do all sort of crazy thing with it right inside your browser and it will run as fast as a native application. That's the idea : getting the highest speed inside your browser to do bold and crazy thing and doing it in a secure way.
Regarding .NET, the first release was almost 7 years ago. Why if it is so good nothing has yet to be seen on the web using it; except Windows Update I don't see anything. Certainly not Quake in a browser.
simon.huet: actually, the Unity engine uses Mono for scripting and includes a light-weight browser plugin for running Unity games. It's pretty cool technology. Soon as the Linux port is out, I may pick up an Indie license.
I'm not entirely sure how useful this plugin will be in the long run. Assuming Mozilla pulls off all of its long-term goals with Tracemonkey, its JavaScript? engine will be approximately as capable as traditional C (although C run in a tracing micro-VM would likely be even faster still... drool), and combined with a 3D canvas element and some kind of eventual networking support, there wouldn't be many use-cases left for native code in the browser. I suppose that's a lot of big assumptions, though. :)
Personally, the only reason I'm even half-interested in this plugin is to get networking in JavaScript?, which I'm not sure this plugin will even make possible due to the restrictions it makes. All I want is a portable way of letting JavaScript? open a true bi-directional TCP connection to the host server (I don't really care if it's a fully open connection or some kind of mini-protocol; e.g. NUL-terminated messages) so that real-time multiplayer games, chat systems, and so on can be implemented without requiring Flash or Java. HTML5 has some proposals, but the discussions on the WHAT-WG mailing list (e.g. the massively retarded WebSocket? proposal) are quite disheartening.
How can I install NaCl firefox plugin without using python?
I can't get the thing to work on WinXP-64, anyone else have luck?
This native client approach is the best idea ever! I love you guys for finally taking first steps into the right direction. I think it wont be long before you will show the rest of the world how silly their virus fears have been, and how much time was wasted on wrong technologies and standards. With proper library support this native web programming can make half of today's technologies totally useless. Which of course is something I totally look forward to. It won't be a first for us programmers to write everything from stratch anyhows :)
> Regarding .NET, the first release was almost 7 years ago. Why if it is so good nothing has yet to be seen on the web using it;
One reason, I think, is that programmers don't want to be constrained by the technology they are using. I feel uneasy just from thinking about using some kind of problem specific IDE and problem specific language that comes with it (like macromedia mx studio and flash language). I'm not saying that .net technology is some kind of really narrow-purposed tool that allows you to do just one thing and nothing else.. No, it is kinda on it's way to becoming industry standard. Just not sure if this is voluntary transition, or are programmers forced to go that way.. Since microsoft is pushing this technology on our bosses, and our bosses are pushing it on us. :) For me, there's still something fishy about technology that doesn't support C-style global functions and variables. :)
I'm a little worried about web fragmentation. Plugin makers might not want to write code for each individual CPU (let alone different SIMD subsets on x86, and both 64-bit and 32-bit code..), so we'll get some things available on some platforms and other things available on other platforms. It's a bit like Microsoft releasing Silverlight which only works for .net, though obviously not as bad or as evil.
On the other hand, both linux and Windows use x86 so maybe there's no fragmentation there, and now fortunately Mac also uses it. I guess for the most part that leaves mobile users, and mobile devices are slow enough that if the plugin needs to be to use native code to be fast enough, it might not apply to mobile devices anyway.