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.

"In recent years, our customers have indicated that their
organizations are moving to mixed IT environments and require
UI tools that enable them to deploy applications in either
Windows or open source environments," said Dean Guida, CEO of
Infragistics. "With Mono compatibility in our ASP.NET toolkit,
we enable developers who have a need for open source
development to create UIs that are the basis for Killer
Applications and deliver the best user experiences possible."

Infragistics ASP.NET toolset excels in top performance,
flexibility and usability and enables developers to build rich
Web applications for line of business. By providing full
compatibility with the Mono runtime, Infragistics extends this
functionality to the Mono community.

Congratulations to the team. They not only improved the UI
and the editing experience, but they support Gtk#, ASP.NET
MVC, Silverlight, MonoMac and MonoTouch deployments from the
same IDE. We have also added support for WCF references and
T4 macro processing.

Next Steps for MonoDevelop

For the next release we have a couple of big goals in mind
for MonoDevelop:

One cute feature of C# 1.0 was the introduction of the
Conditional attribute. When you apply the conditional
attribute to a method, calls to this method are only included
in the resulting code if the appropriate define is set.

Calls to Foo.Log become no-ops unless you pass the
-define:DEBUG command line option to the compiler.

What is interesting about this compiler-supported feature
is that that the code inside the method Log is checked for
errors during compilation as any other regular method. They
are first class citizens.

I am proud to introduce my first iPhone App built entirely
using standard HTML5 technologies.

I felt that I had to go with HTML 5 as I did not want to
write the app once for the iPhone and once for the Android. I
am also open sourcing this application in its entirety, to
help future generation of mobile HTML 5 developers learn from
my experiences and hopefully help them write solid, cross
platform mobile applications using HTML 5.

I use this app every time we go to a pub, or when we are
having lunch at the Cambridge Brewing Company.

Before you check it out, my lawyer has advised me that I
need to add the following disclaimer:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

What People Are Saying about iCoaster!

"I am currently resorting to use my four iPhones to create one giant iCoaster; this is ridiculous. Need iCoaster HD!!!!"

"Buying an iPad every time I want to put a drink down is
expensive, though it is better than getting those little rings
all over my shiny new table."

"Four coasters per iPad would be ideal"

"Please keep up the great work. Not sure what I would do
without this app, would at least have a lot of ruined coffee
tables."

Sadly, we do have some bugs being reported, and I can
assure everyone that I am working around the clock to fix
these issues. Ensuring that iCoaster is reliable is my top
priority:

"If I put my drink on iCoaster, and then rotate my phone to
the landscape orientation, my drink gets spilled onto my
lap. Please fix this in the iPad version."

Survey Results as of 14:50 EST

Updates

Update: We have confirmation that it works on WebOS
and Blackberry as well. HTML5 FTW!

Update 2: Due to popular demand, I am launching an
effort to bring iCoaster to the iPad. If you want to
participate in the beta for iCoasterHD,
please fill
in this survey, your feedback will help me prioritize
features.

Update 4: For those of you complaining about the
missing DOCTYPE Geoff Norton has done what any honorable open
source contributor would have done: he forked iCoaster and
made it HTML
"compliant": icoaster-fork.

Our previous debugger, a hard debugger, worked on Linux/x86
systems but was very hard to port to new platforms and to
other operating systems. With our new soft debugger we can
debug Mono applications running on Windows, helping developers
test before moving to Linux.

Faster Transfers

When you are developing large applications or web
applications, you want your turn around time from the time
that you run hit Run to the site running on Linux to be as
short as possible.

Cheap Shot Alert: When dealing with large web sites, we
used to behave like J2EE: click run and wait for a month for
your app to be loaded into the application server.

This is no longer the case. Deployments that used to take
30 seconds now take 2 seconds.

Support for Visual Studio 2010

Our plugin now supports the Visual Studio 2010 new features
for plugin developers.

This means you get a single .vsix package to install, no
system installs, no registry messing around, no dedicated
installers, none of that.

The full plugin installs in 3 seconds. And you can remove
it just as easily.

Then you can just from VS's Mono menu pick "Run In Mono"
and pick whether you want to run locally or remotely.

We now also support multiple profiles, so you can debug
from Visual Studio your code running on Linux boxes, Mac boxes
or your local system.

Polish and more Polish

MonoTools was our first Windows software and we learned a
lot about what Windows developers expected.

We polished hundreds of small usability problems that the
community reported in our last few iterations. You can also
check
our release
notes for the meaty details.

Appliances

And we integrate directly with SuseStudio to create your
ready-to-run appliances directly from Visual Studio.