Native SDK to support C++ Development
There... I said it. Allow native code (maybe sandboxed like in newer versions of Chrome) for better code usability. The 1st party apps are written in native code, then why not let us do it? If the apps behave bad you are free not to approve the app!
Thank you for the suggestion and the spirited commentary; as you have likely seen by now, the Windows Phone 8.0 developer platform does indeed support C++ development for DirectX games and by allowing you to run C++ code as part of your managed XAML apps. Download the WPSDK and give it a try. :)
4 Dec Update:
Adding some additional details to this update, the Windows Phone 8.0 supports two app models around native:
- DirectX can run apps that are fully written in C++ for game/business logic, graphics, and input
- XAML + C# apps can make use of C++ code written in DirectX and rendered using one of two XAML objects
- XAML + C# apps can make use of C++ code compiled into compute-only C++ libraries called ‘Windows Phone Runtime component’s.
What is not enabled is apps written solely in C++ and XAML…which is more a function of scope and resources than a religious decision. It was thought that what was delivered in this release meets the needs of 80% of the WPDev community (fully supporting native games and code reuse for both apps and games that want to target multiple platforms), with more coming in future releases.
Даешь С++! Сволочи!
It's a shame that such a thread even exists. MS should have supported C++ from the very beginning, or told developers native support would come in the future if it has not enough time. Instead MS let developers to sign petitions here. Fortunately, the market share tell MS it WP7 strategy is totally a failure and WP would have doomed without Nokia's support. MS may have thought devs would rewrite their game engines like Unity with C#!, or consumers would buy a phone without basic features like white list, orientation lock! ... MS has better bring C++/XAML as soon as possible
@Jasper - I believe there's two parts to your comment: (a) the needs of the games community and (b) potential security risks posed by native code.
To your point around needs of the game community, most top games aren't managed code...their optimized and built to maximize RoI for the publisher, and they mostly make use of game engines (e.g., Unity, Havok, Marmalade, etc.) that are designed to run the game code cross-platform and as close to the metal as possible. For these folks, us adding DirectX support in the 8.0 release does quite adequately meet the general need for those folks.
As to the security concerns of C++ and Windows Phone - you're mixing the rekerneling with C++ support. In Windows Phone before 8.0, running code in native provided full access to Win32 and allowed the apps/games to run outside of their chamber. This was addressed by the new WP8.0 kernel, thereby providing a reliable and secure way of enabling native code for the dev community, should they feel the need to use it.
But, as a whole, I wouldn't think of the addition of C++ support to the platform as a comment on the superiority of one programming style over another - we're providing the options that the mobile developer community need to deliver quality app experiences on our platform. On a totally personal level, I don't understand why someone would want to use unmanaged code after they've experienced what a language like C# can do for you (and I think the success of Mono show that I'm not alone); however, I do recognize that there are situations where app devs have some complex and existing algorithms (e.g., complex physics engines, media processing, navigation) where they want to quickly and easily use that code across device experiences.
Ultimately, as any community matures and grows, it becomes diverse -- and WPDev is no exception. ^_^
Seriously Mr. Simpkins, "It was thought that what was delivered in this release meets the needs of 80% of the WPDev community".
Guess who is the WPDev community -> managed developers and ex-Silverlight devs.
There are not many C++ developers looking at WP because for 2 years, you have been telling us that Native Code is not secure (I can provide sources to these facts). And now you are telling us that for games, C++ is good enough?
Great way to make a WPDev community.
death to all managed developers!
Thanks for the additional comments on the thread.
For XAML/C++ aspect, I'd recommend taking comments and votes for that capability over to the new suggestion that someone recently created at http://wpdev.uservoice.com/forums/110705/suggestions/3593968
As to XAML/C++, as we commented at Build (and in the last paragraph of the Suggestion response above) around XAML and WinRT (the Windows Runtime, not the ARM tablet SKU :) ) - it's not something that we're philosophically opposed to, it's just a capability that we didn't have time to implement in this release. With the focus on dev platform app compatibility and the Silverlight-style XAML+.NET programming, as well as the fact that Windows was building out their XAML/C++ development platform at the same time as we were building out ours...it just couldn't happen in the 8.0 release.
Petr Jurik commented
I've just tried to port our app from Windows 8 to WP8 and it's a real pain. Why WP8 doesn't support C++/XAML ? I don't want to rewrite our whole code to C# and some of the our code (like using WriteableBitmap etc.) cannot be used from C++ component. How developer would port his app to WP8 with such a restrictions ? Probably you've forgot that WP8 is a minor OS and MS should do much much more to attract developers. Sorry, but for now i'm not going to port our app to WP8 (once MS will make serious C++ support like in Windows 8).
Cliff, I'd like to add my voice to those requesting a complete C++ dev environment on WP8 (support XAML). I have a large C++/Direct3D core in my app and have to restrict the UI due to the C# interop stuff. Even with this restriction my app blows my competitors on iOS and Android out of the water performance-wise, even on lesser phone hardware.
You have a good system going here with Win8. Make it complete.
I guess now is as good as time as any for Microsoft to hear what many of us, The Old Guard, are thinking.
I, personally, have been "with" Microsoft since 1985, using MS-DOS on a machine that had a monitor with orange characters. I remember during the early days of Windows reading the Intel iAPX 386 architecture manuals, knowing that, it was likely that engineers at Microsoft were working hard to take advantage of the true, preemptive multitasking that it provided, unlike what was currently being used - the Yield() function.Through the ups and downs, I was always confident that Microsoft's overall trajectory was inspiring. No company is perfect, and the mistakes that Microsoft made where merely blemishes on a powerhouse of innovation, IMHO.
However, my gut feeling, after 27 years of watching Microsoft, is that this year, 2012, marked a turning point. I smell vulnerability. Even more important...the time remaining to "right the ship" seems to be months, not years.
Anyone who is not naive can read between the lines over the past year or so regarding Windows 8, Windows Phone 8, WinRT, etc...and deduce Microsoft's business strategy. I personally believe that the strategy is flawed, but a CEO has to do what a CEO has to do.
You, the engineers and managers inside Microsoft: You know the truth about the selling success of Windows 8. You can see it in your sales figures so far. You have been doing this long enough to know what is forthcoming. The pundits can write what they want, but you know the truth. And many of us have been "with" you long enough to know the truth without reading what the media writes. We know that there is more than one person inside Microsoft, right now, with respect to Windows 8 and Windows Phone 8 saying, "Hmmm....". Right now, that's all it is, and hopefully, it will stay that way.
That said, I would like to offer a suggestion: Open up your platform.
Yes, open it up. Not open source. Just do what you have been doing on Big Windows since the very beginning. You have an uncommonly-deep brain-bench that invested immeasurable intellectual capital on Windows. That brain-bench is starting to come apart, not by choice, but by necessity. Right now, this brain-bench is seriously considering Android (and other platforms) in ways that it has never done before. Some might say that the consideration was inevitable, but that is not true. There was still enough Microsoft loyalists that, had you introduced Windows Phone 8 in a different manner, we would have taken care of the rest. You created this situation with your (new) business strategy. Even small things like requiring Windows 8 for the WP8 SDK - not smart. Those seemingly small details have an amplifying affect on how long it takes a developer to ramp up, which affects whether other developers early-adopt, etc, and so on. You have a situation now where your hard-core engineers are avoiding developing for WP8 because their dev tool only runs on Windows 8, and they find Windows 8 distasteful. We all know how trivial it would have been to allow development for WP8 on Windows 7 and even before W7, but again...it is clear that a strategy was in place to induce upgrades to Windows 8. From what I am seeing on the ground, it's backfiring for a certain class of developer.
If you were to open-up the Windows Phone 8 platform, keeping the interface that you have now, but allowing those who create ground-breaking applications to do so on Windows Phone 8, you could turn the tide in that market relatively quickly.
As it stands, your "compete with Apple using Apple's tactics" is failing. Yes, you will retain many developers who are willing to follow your semi-closed app model, but you will lose the ones who are not. This latter category will migrate to Android so that they can innovate in the way that they would have on WP8. Once that happens, you will not be able to bring them back. On the contrary, once we have made the transition to Android, we will do everything in our power to make Android the new standard, not out of spite, but because we instinctively know that, in doing so, we accelerate the adoption of a stable, predictable, open platform that gives us the API freedom that we need. We would likely *not* opt for the multiple-platform strategy, at least not initially, where WP8 is included. Again, this would not be out of spite, but we instinctively know that if we deliberately exclude WP8, it will even further accelerate the adoption of Android, thus giving us what we need sooner than later. And finally, in a strange twist, we would likely be using Visual Studio, on Windows 7, to develop for Android as we make the transition.
I know that there are people at Microsoft who have considered this scenario. I can assure you that it is quite real. The things that I hear fellow engineers ponder out-loud would alarm you.
Michael Maguire commented
Dear @Cliff Simpkins, I used to work in the Windows CE team on DirectX drivers but I must apologize -- I don't understand the meaning of your Dec 4, 2012 statements about "C++ code written in DirectX"? Has the meaning of DirectX been re-branded? Is this a typo? What does it mean to write C++ in DirectX?
I would love to play around with the SDK, but I have no machines to do that [VS 2012 nearly ruined my primary dev machine a few months ago, so I am a bit weary.] My question is quite simple, even though one of my engineers is telling me that the answer is "No". First, before I ask, I have been writing software for Microsoft for 27 years, so I think it is safe to say that we both know what happens when CreateProcess, for example, is invoked against a PE image on disk. In other words, if there is any confusion about what I am asking, please let me know :)
The executable that is built on a Windows Phone 8 device: When it is executed, is it possible that the image is executed "in the raw", as a true native application, or is it always the case that the C++ code ultimately runs inside an interpreted sandbox.
I am receiving conflicting responses. One engineer says that it is in an interpreted sandbox. But I saw a video on Channel9 that says that "This is a true native application, and it could not have managed code in it even if you wanted it to."
What is the truth?
Finally, I am sure that I am not the only developer who is looking for a simple but concrete answer to this question. As always, thanks a bunch!
Okay - with time to wade into UserVoice topics, I've updated the status with additional information on this topic. For those that want a better view into what native support means in WP8, Sam George (who's team spec'd and implemented the C++ work in WP8) did a decent session at Build 2012 covering the C++ app model for games, which provides some good context as to what was implemented and why some of the decisions were made.
@Tobias - I wouldn't call them completely implemented. The areas you mention didn't get sufficient test coverage to get a green light to allow just yet in the release. There are some options on CodePlex to fill the gaps for now, but much of the D2D can be filled by building a XAML + DirectX hybrid app to render the text...I'm told the increased overhead is minimal (~5mb) of using the hybrid approach, and it gives your D3D app full access to the managed APIs/launchers/choosers, and not just the aligned/common Windows Runtime APIs.
Keep it to Microsoft to provide a SDK that puts C++ as second class developers. Let me say why: You cannot create a XAML application with C++ - you have to interop with .NET to even show a simple button. Almost all Native APIs are restricted for game development although they are available on the platform and used by the first party apps.
It is still impossible to create "complex" applications like pdf editors, rich font renderes, image decoders, and so on. These are clearly use cases that cannot be done with .NET but the Windows Phone team simply ignores these developers even after 2 years. The Windows Phone team has set to follow the Android model (although the WP SDK is even more crippled) instead of iPhone. Ever occurred why iOS apps tend to be more effiencent? I will not accept "compelted" unless the following APIs are "allowed" (they are implemented already!): Direct2D, DirectWrite, MediaFoundation with (Media Writers), Windows Animation Manager, WIC, DirectComposition, etc.
One of my engineers validated my suspicions regarding "native" development on Windows Phone 8. Let me be clear:
Native development on Windows Phone 8 is *not* really native development.
Your code will be in a sandbox that, for all practical purposes, keeps you squarely in the interpreted world. It was pretty deceitful of Microsoft to do this. When serious engineers complained about the lack of native development, they threw out a bone and labeled it "native", and the media became their megaphone. Technical managers everywhere hear "native C++ development", and think, "Great, problem solved."
Eventually the truth will come out, and Microsoft will be forced to either provide real native development (as Daniel hinted), or will be the target of sustained, unabated scorn by software developers for being dishonest in the first place.
Very nice, time to put my money where my mouth is...ordered a shiny new windows 8 box to write WP8 (and hopefully WinRT arm stuff) on!
"Phone 8.0 developer platform does indeed support C++ development for DirectX games and by allowing you to run C++ code as part of your managed XAML apps."
A friend of might owe me lunch.
A few months ago, we were having a "spirited" discussion about what exactly "native" development meant. Knowing Microsoft, I strongly suspected that native development meant that Microsoft would allow the CPU to eat machine instructions that were generated from C++ code compiled by a native-to-C++ compiler, but that the execution environment of the program module would still be managed. This would make sense in Microsoft's sustained attempt, over the last 12 years, to migrate C++ coders away from true native development and into the .NET/managed sandbox [and killing a number of competitive threats to the Microsoft ecosystem as a consequence].
Before I start dreaming about my cheeseburger, could someone (Microsoft or otherwise) explain, in engineering terms, what exactly does "native" development mean?
Michael Maguire commented
When you say "Download the WPSDK and give it a try" do you mean from here:
"When Windows Phone SDK 8.0 is available, we’ll update this page with a link to the release."
I don't wan to P/Invoke from a Silverlight application. I want to create "pure" native applications (like the first party apps)!
Marek Baranowski commented
I have big part of code, about 200k lines. This code, without changes, run under Windows, ppc, Windows Mobile, Linux, Android and iOS. For each I change only not-universal, small, UI part. And now I must rewrite this 200k lines for one system, Windows Phone:) Fortunelly I'm owner and simply I don't want do it. My clients must buy Android or iOS. Sorry.
Qt works on many systems and surely putting Qt on Windows Phone cannot be that difficult. Nokia/MS want Windows Phone to be the standard development platform. All the GUI has been converted to far harder namely Symbian. Make it a loadable add in or even a standalone base. The Qt SDK libraries are easy to port