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.