Ladies and gentlemen, I have for your delectation and  delight a quite extraordinary trick. Watch as the giant of Redmond compiles 100,000 apps with a compiler that has no track record...

Microsoft has finally announced some of the details of Windows Phone 8. Much of the presentation was important for what it didn't say and for the stage-magic misdirection making you attend to the unimportant while the truly amazing was passing under your nose.

Specifically, Microsoft's promise to support WP7 apps under WP8 seems to contain some quite bizarre elements.

Microsoft product managers and evangelists have repeatedly stated that WP7 apps will run on WP8.

They really have to, don't they. After convincing developers to create over 100,000 apps, they could hardly simply throw everything away and and start again.

What would users say to a WP8 that had no apps ready to use?

What would developers say on being urged to build their apps all over again?

No, whatever happened, Microsoft could not afford to make WP7 apps redundant.

So without any doubt it has to be the case that WP7 apps will run on WP8.

What they haven't said is that you can continue to build and develop WP7 apps for WP8.

Perhaps you might want to add to this the observation "using tools designed for WP8".

Most developers would suppose that this is implicit in backward-looking support for WP7. After all, how could you allow WP7 apps to run without including the infrastructure that would also allow apps to be developed?

It seems that the simplest and most direct way of making things backward compatible would be to include Silverlight and XNA so that WP7 apps run - and as a by- product allow WP7 apps to be developed and maintained using WP8. This would make WP8 the last hiding place of SIlverlight and almost the last for XNA.

While there is no hard evidence to say that this is not what will happen, there are a few hints that Microsoft plans to go down a different route.

In the WP8 presentation we are suddenly told that Microsoft is going to do something amazing for developers.

"All WP7 apps will be compiled to machine code before being delpoyed as WP8 apps".

In more detail, Microsoft is going to use its cloud compiler to take all of the WP7 apps and compile them to machine code. This will make them go faster and load quicker.

And Microsoft stresses that developers will get this huge benefit without having to lift a finger or do anything...

This is very strange.

The first thing is to ask what cloud compiler?

It might be based on Roslyn, the experimental cloud compiler for .NET, but as it stands this seems unlikely and would need a lot of work. At the moment Roslyn doesn't compile to machine code - and certainly not to ARM machine code.

So Microsoft is going to have to develop a cloud compiler that can compile Silverlight and XNA assemblies to ARM machine code.

This is not a trivial undertaking.

When they have their compiler they are then going to use it to compile 100,000 apps.

This is astonishing.

imagine compiling one app, now ten, now one hundred,  now a thousand and so on... Compiling 100,000 apps is no small task.

Then we have the promise that developers will not be involved in the process.

Why not?

Do you really want a third party compiling your app?

How can you be sure it will work?

A brand new compiler, running in the cloud, compiling 100,000 apps and doing the job correctly - first time?

And without even a public beta of the compiler?

This is beginning to sound like real magic not just stage magic.

The chances of creating a compiler that can do this job correctly are small. Even if the compiler is 100% perfect at its task, things still don't always work.

Consider if any app has a process that is based on any timing loop or delay. As the resulting code runs at a very different speed, even if the compiler was 100% perfect there would still be apps that didn't work as originally designed.

You also have to ask why is this a cloud compiler?

The best reason I can think of is that by making it in the "cloud" they can avoid having to make it available to anyone else.

That is, not only will you not have to be involved it is absolutely impossible for you to be involved.

That is, Microsoft will not be putting this tool into your hands.

So why exactly is Microsoft taking on this very difficult task just to make your apps go a bit faster?

The most likely reason is that Microsoft is taking a very different route to getting WP7 apps running under WP8 than simply bundling Silverlight and XNA subsystems. The compiler is most likely not only doing the job not only of speeding up WP7 apps but making them into WP8 apps.

This is potentially and even more difficult task than just creating a simple compiler.

Microsoft haven't said that this is what the compiler does but suppose it just takes a WP7 app and compiles it to a WP7 app that goes faster. Why not let the new "go faster" WP7 app run on existing WP7 phones?

In other words, a compiler that takes existing managed code apps and turns them into machine code is generally useful, and not just for WP8. You could even say that such a tool would give the old WP7 platform enough extra power not to need an upgrade to WP8.

Another small point is that over the years the issue of managed code versus native code languages such as C++ has often hinged on the differences between the compilers. Managed code compilers produce slower code because they protect the system from programming errors - buffer overruns, pointer errors and so on. It has long been held that you can't compile managed code to machine code without sacrificing the protection.

So either the job cannot be done, and the whole project is doomed to failure, or it can be done and the whole move to native code language is quite unnecessary because manged code can deliver the same performance.

Something doesn't add up.

Again, Microsoft hasn't said that compiled WP7 apps won't run under WP7, but it seems like a reasonable guess because, as already stated  if all the compiler were doing is making things go faster why would Microsoft bother to make us this gift. And why would Microsoft take on the task of compiling 100,000 apps?

The more you consider the situation, the more it makes sense interpreted as a cross compiler, which converts WP7 to WP8 - one-way and possibly one-time-only.

How can you modify your new WP8 app if for some reason it doesn't work or if you want to add some new features?

My guess is that Microsoft will allow you to edit and work with your old WP7 app on WP7 using WP7 tools and will recompile it for you to a WP8 app, but the pressure will be on to port it to a "native" WP8 app.

Doing things this way seems to give Microsoft what it wants - 100,000 apps ready when WP8 launches but no chance of WP7 Silverlight/XNA apps hanging around in the future.

We all get a breathing space to convert our apps to proper WP8 Metro apps - and the sound of twisted arms can only be heard fading in the distance.

Good ploy - we all need to move to WP8 and Metro.

Fine, but consider this,

do you really think the 100,000 app compiler trick is going to work?

If it doesn't, things are going to be interesting.

Related Articles

Windows Phone 8 - A Restart

How Microsoft Could Have Done Metro

Microsoft's Extinction Event

Why your next language better be C++

Windows Phone 8 - Silverlight Apps Are Legacy

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin,  or sign up for our weekly newsletter.