Windows phone 7 native code support

2 questions:

• Can someone tell me if unmanaged c++ code will be supported in future versions of Phone 7 OS for all developers?
• What a开发者_如何学Gore MS reasons for not supporting unmanaged c++ code?

This answer is purely speculative, but I feel that most others who have answered this question miss the point by a long shot. Let's for a moment assume that this is not a vindictive decision by Microsoft, but instead actually a very well thought out engineering decision that has absolutely nothing to do with content restrictions or otherwise. Those issues are just a bonus for MS

Microsoft is entering into the mobile market, this time for real it seems. Pretty soon there will be tens of millions of Nokia phone being shipped using Windows Phone and whatever they get on top of that will just be gravy. Windows Phone though still hasn't really found its home.

In the next year or two, phones, tablets and laptops will finally start converging into a single device. People will carry their phone in their pockets, but that phone will also be the CPU unit of their PC. That means that by simply sitting near a wireless HDMI monitor and connecting a keyboard and mouse via wireless USB (or bluetooth if we're all unlucky), the user will have their entire PC with them at all times. Tablets will become just a battery powered touch screen which interfaces to the PC in your pocket.

So, all software written for Windows Phone should be able to run unmodified on a PC, a tablet and/or a phone. This is because there's a huge chance that the PC you're running will be either x86 or ARM based running Windows 8. When the PC is in your pocket, the user interface you'll see will be the Windows Phone GUI. When you're hooked up to a monitor, you'll see the ribbon interface. But the underlying OS will most likely be Windows 8, not the Windows CE that is currently used.

Based on all this, the only way Microsoft can insure that developers who invest in producing apps for the Windows Mobile market will not be screwed and that users of Windows Mobile devices won't be shorted when the newer platform comes around is to ensure there is a standard system for running apps on all these processors.

Even now, writing for Honeycomb is a nightmare since if you develop native code, you have to support both ARM and x86 and there's no real support mechanism for it. The only solution is to develop, package and ship two versions. Writing apps for iDevices are a little easier since there's no overlap. x86 on desktop, ARM on device. If you have to use native code on device, ARM is all you need. Even then, there is fat binary support on both device and desktop, so this won't be a problem except when optimizing.

In the end, the decision by Microsoft to stick strictly to .NET is probably a good one. Once they have a gazillion Nokia phones on the market and things have settled a bit, native code could be a real possibility.

These answers are for the application development perspective. OEMs can write native code today, as that's how they create drivers, but that's not open or available to most developers and therefore of no use to most.

For #1 Microsoft has made no announcements, so only Microsoft knows the answer and they're not saying.

For #2 it's all about code security and overall platfrom stability It's very tough to sandbox native code and they don't want your app being able to affect other apps or the platform itself. The general idea is that you should be using Silverlight or XNA for application development, so that's what they expose.

Windows phones will go nowhere with native support. Games and other more intensive apps are driving sales. Android was forced to blow the lid off of its NDK to support the games industry. As far as supporting multiple processors, etc., those of us doing this kind of work have been doing it for a long time, so its no problem. Already handling Intel and ARM without a problems with our systems.

EDIT, finally: for WP7 unmanaged code won't ever be supported, but in Windows Phone 8 - yes it will! They've just announced it. Native apps, C/C++, iOS/Android portability and code sharing, DirectX. You'll need Visual Studio 2012 and Windows 8 for WP8 development, though. Looks like VS2010 is not getting the requisite WinRT SDK.

The nongame UI, however, will still be XAML-based. Win32 API will not be supported. They're pushing a model with managed UI layer and a native middleware beneath it.

SDK will be available later this summer.

For the sake of posterity, here's the pre-06/20/2012 answer:

1. Microsoft probably can.
2. To ensure platform closeness, as a means for attaining stability and UI consistency. To enforce app isolation. Also, to make jailbreaking/rooting harder.

EDIT: if you want a native SDK on WP7, like I do, please go sign this petition and/or that petition. Thank you!

EDIT: see this.

EDIT: also this. Still not official, but this rumor moves the timeframe for native app support even closer - to the upcoming Tango release.

I believe MS will support native development like C/C++. Really. Seriously.

Because, for end users, one of the killer app is game. And Most of game codes are based on C/C++. JS or C# based codes are exist, but meaningless from industrial perspective. Consider big players in game field like Unreal or EA. They made huge investment on C/C++ codebase. They won't give it up. In other words, MS has no power to force them to spend money for .NET. Even Xbox360 development offers C/C++ development. Because of that.

And leading platforms like iOS/Android all supports native development. WP can't bear up the situation without any game from big players. MS really wants 3rd path games, and offering native code is the only way to get them.

Of course, this can be applied to other apps which are not game, but games are biggest one. When C#/XNA just came out, there's no library. People had to make everything themselves. Now there're a little more, but still meaningless for professional games.

If MS won't offer native environment, just don't go there. MS wants to make developers to use managed .NET code, but .NET has too many limitations can be solved with only unmanaged code.

The only question is just when will MS support native development.