- Right now, Windows Phone 7 comes with "native" widgets and controls and frameworks for user-interface development. These are used by some (if not all?) of the native applications that come on the system, such as the Settings area.
- This includes the "panorama" control, swipe/slide controls, and a few others.
- Windows Phone 7 applications, on the other hand, have to use controls and widgets developed entirely in/on Silverlight. Silverlight does not provide a thin managed wrapper around the native panorama/etc controls, instead they're entirely re-implemented.
- As a consequence, if Microsoft wants to make WP7 applications run on desktop Windows in some "enhanced" mode where a panorama view is expanded to show all the areas they would probably make a start by modifying the behaviour of the native controls, but they would alsohave to update how the Silverlight controls work, but this then doubles the amount of work required, as a probable consequence Microsoft will not do this.
- Therefore if WP7 applications will be enabled to work on desktop Windows, it will be such that they appear as they do in the device emulator (just with a prettier display border). Do not expect anything mind-bend-y.
- Case in point: early on in WP7's life Microsoft didn't implement the "push" state effect on various Silverlight controls. Developers were annoyed they had to re-implement something that the system should provide itself; many developers did, but couldn't get the effect to look right. Microsoft is free to parameterise the native push effect and make it more prettier in the next release of WP7, but because the Silverlight versions re-implemented it themselves they're stuck with the old look.
- TL;DR: By making the Silverlight stack use its own re-implementation of controls on WP7 Microsoft hasdoubled the amount of effort involved in making changes to the platform, this will stifle innovation.