What I would do if I was in charge of Windows 8

Apple and its AppStore did for software programmers what Google's AdWord did for bloggers and writers: it provided a mechanism for people to make money while doing what they love.

The AppStore takes a big weight from the shoulders of software developers by taking care of the distribution and billing system.

If I was in charge of the Windows 8 future (or MacOS for that matter), I would try to reproduce that formula on my mainstream operating system. And it seems from the leaked presentations that this is where Microsoft's head is.

The leaked mockups for the AppStore are creative, but the entire slide deck misses the fundamental point that people are scared of installing software on Windows.

Everyone is scared of installing applications on Windows either because they break the system or because you might be accidentally installing malware. In either case, the end result is countless wasted hours backing data up, reinstalling the operating sytem and all the applications.

An AppStore wont fix this.

For a Windows appstore to work, they need to guarantee that installing software wont ever break the system.

They need to produce an appliance that allows users to install and remove software in seconds, and yet, guarantee that installing and removing apps will never break the system. This is not a problem that can be solved by hiring an army of curators and people that just sit all day rejecting apps.

To solve the problem, Microsoft needs to both alter their kernel to ensure the safety of the host OS and come up with a new way of distributing applications. They need:

  • A sandboxed execution system.
  • Self contained applications, fully embedded in a single directory that require no installation.
  • A set of supported APIs that will run in the Sandbox execution system.
  • A public contract for extension points.

The Sandboxed Execution System: would prevent applications from touching the registry, installing any drivers, any hooks, any visualizers or any other deep integration features that applications typically use to integrate with the OS.

The sandboxed execution system would prevent applications from looking at the file system, except for locations that have been predetermined for sharing.

The kernel would have to enforce what files they get access to, what devices and what components they get access to. And should be set to a bare minimum.

Self Contained Applications would be required to install software from the network, or from their appstore. These applications would get absolutely no rights to modify anything outside their directory. Any extension points that they could register with the system ("open with") would have to be registered with the public extension point contract.

Public Contract for Extension Points Any extension points like "open with", or handlers for mime-types would be self contained in a manifest in the application directory.

Instead of having every app poking at the system registry and dumping their junk everywhere, applications would list all of their requirements from the operating system on the manifest and the OS would rebuild its internal data from all of the application manifests available from a user.

Limited APIs: File access APIs, display access APIs would have to be altered to give applications limited access to the host operating system, and to give them as little access to anything that most applications do not need.

The above obviously does not apply to frameworks like the .NET framework, Java or Adobe's AIR. But beyond frameworks, there are very few cases where an application really should have legitimate access to all of the features in the OS. Video games certainly do not need it, and even applications like Visual Studio would not need it.

Posted on 28 Jun 2010 by Miguel de Icaza
This is a personal web page. Things said here do not represent the position of my employer.