There isn't a way to call an executable outside the browser without the types of things you described (and I'd probably use the application URI scheme in your place because it's the least custom plugin work on your part). This is because if you could call any application without the user requiring a registry edit or some related change, you could do anything you wanted with any application you know would be on the users' machine. It's called sandboxing, and HOWTO GEEK has a decent article on it.
A sandbox is a tightly controlled environment where programs can be
run. Sandboxes restrict what a piece of code can do, giving it just as
many permissions as it needs without adding additional permissions
that could be abused.
For example, your web browser essentially runs web pages you visit in
a sandbox. They’re restricted to running in your browser and accessing
a limited set of resources — they can’t view your webcam without
permission or read your computer’s local files. If websites you visit
weren’t sandboxed and isolated from the rest of your system, visiting
a malicious website would be as bad as installing a virus.
As they point out, you're already in a sandbox when you're in the browser. If you want to write an application that can be accessed from within there, you need to work within the capabilities and restrictions of HTML, JavaScript, etc.
From your own MSDN link you can see that on Windows,
Without this key, the handler application will not launch.
Your post seems to indicate that Windows is indeed your relevant target OS. If you want to do this on another operation system (or if someone else reads this question), the methods will vary from what you already found (these are already Stack Overflow questions):
In theory, you could create plugins or configuration applications specific to each likely browser to do something totally custom. However, you'd be reinventing the wheel because you'd need the same rights elevation to install your app/plugin. Additionally, you'd be reinventing the protocol mentioned above and somehow distributing the application for installation ahead of time.
Also, sometimes it looks like applications are smoothly gaining access to the user's browser experience when new web functionality like webcam access and geolocation is being utilized. What we're actually seeing here is somewhat new JavaScript APIs in place of Flash applets and other things we used to need to harness through 3rd party software.
- getUserMedia (or it might be
webkitGetUserMedia or mozGetUserMedia depending upon the browser) allows use of media from the webcam and mic. Browsers have implemented a permission prompt before allowing this, but the application is still a JavaScript app.
- The Geolocation API is written into the HTML5 standard here and the simplest implementation (JavaScript) would look like this:
navigator.geolocation.getCurrentPosition(show_map); It's still simply a JavaScript library. If you use it, this site mentions adding some error handling / fallback and such. It's available starting with IE 9. See that link for other browsers.
- You can use
navigator.registerProtocolHandler (read more here from Mozilla docs) However, besides built in protocols (mailto, for instance), you're going to be looking at handling the URI with a web application on the same domain as where you're calling this function. To set up a handler where the protocol burger in the link <a href="burger:cheeseburger">this</a> will be handled, you could write: navigator.registerProtocolHandler("burger",
"http://www.google.co.uk/?uri=%s",
"Burger handler"); You could find more information at the W3C spec, including other whitelisted schemes but you'd need to do a lot of careful picking of browsers to support and ensure your target audience can use this. I like to reference CanIUse whenever I want to determine browser support. It looks like Chrome and Firefox are in and IE is out.
- I did just find a way to bolt on some functionality like this in Ubuntu by adding a protocol handler, IF you assume the ability to get all your client machines to run some scripts (with SUDO rights) before using the links. This is how apt: links in Ubuntu call the package manager. Since this gets back into the realm of "create an install script that can edit MIME types in the registry" for a Windows solution, I think I can stop here.
