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!
mithril
shared this idea
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.
281 comments
-
Tom
commented
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).
-
henador
commented
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.
-
John
commented
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?
-
John
commented
Hi Cliff,
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.
-
Tobias
commented
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. -
John
commented
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.
-
Noel
commented
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!
-
John
commented
"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:
https://dev.windowsphone.com/en-us/featured/windows-phone-8-sdk
"When Windows Phone SDK 8.0 is available, we’ll update this page with a link to the release."
-
Daniel
commented
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.
-
Anonymous
commented
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
-
Vsevolod Alekseyev
commented
WinRT allows C++ code-behind. If the WP8 platform is indeed WinRT the way is currently appears in Win8, then yes you can. Daniel de Souza, however, claims otherwise. He might be a troll.
-
Jasper
commented
My Question is: Will WP8 allow C++ developers to create UIs in XAML or is native development only for games and non-ui-libraries?
-
John
commented
There is something positive in the move to use the NT Kernel in WP8. It has to do what I have written about before - internal struggles inside of Microsoft. [Again that I am in no way associated with Microsoft.]
I would not be surprised if there were an internal struggle inside of Microsoft between the Windows CE kernel team and the Windows NT kernel team. As we all know, in the entire world of Windows, there are really only two OS's: Little Windows (Windows CE) and Big Widows (Windows NT). Various flavors of mobile devices having numerous labels (Pocket PC, Windows Mobile, WP7, etc.) are all essentially variants of Windows CE. Windows NT, 2000, XP, 2003, Vista, 2008, etc...those are Windows NT.
It's human nature to guard one's turf, and so perhaps the Windows CE team fought hard to keep Windows CE as the core of WP7 and future Windows Phones. They lost. This is good. Having separate OS's was not a technical necessity, but an artifact of historical momentum, probably perpetuated by those who stood to lose their project after a reconsideration. Windows CE had warts that seemed benign until one stopped to think of the implications. For example, Windows Mobile (Windows CE) only recently allowed more than 32 processes to run simultaneously as of Windows Mobile 6.0:
Furthermore, my biggest pet-peeve with Windows Mobile was the lack of CreateWaitableTimer, which I use very heavily in my work.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682492(v=vs.85).aspx
Yes, one could have hacked a funky work-a-round, but not having it as part of the OS is a PITA. The file system was different: The paths had no drive letters. The Shell was extendable, but extending it was very different from Big Windows, and as shell developers know, extending the shell on Big Windows is often a multi-year effort. All those problems are now gone, because beneath the pretty face on a WP7 is the lurking giant of an Inudstrial-Strength OS that goes back to the days of VMS engineers who migrated to Microsoft.
Given the choice between having real native C++ development, and having Windows NT as the kernel of smartphones, I would prefer having the NT Kernel. Why? Because it almost guarantees future real native C++ development. Once that Industrial-Strength OS is in place, mechanism no longer becomes and issue. Only policy remains.
That means that all we native developers have to do is sit back and wait. Consumers, businesses...all kinds of customers will eventually create overwhelming demand (indirectly) for applications that break through the sandbox. The .NET bloat and performance problems will not be sustainable.
Microsoft will likely relent, and eventually do what they should have done in the first place: Give us developers industrial-strength under the hood, while making the surface really pretty.
The problem of allowing the device to host crappy software will still be present, but as I have said: it is not possible to have one's cake and eat it too.
-
Vsevolod Alekseyev
commented
2Daniel: um, so what about that statement at the Summit about "shared application platform between Windows 8 tablets and Windows Phone 8"? The Win8 tablet platform is WinRT (which is XAML-based, like Silverlight, but not 100% compatible). I took it as a commitment to WinRT on the phone.
The fact that Win8 tablet development will be WinRT-based has already been widely advertised. I've attended a conference in May where half the sessions were about this.
XAML, for the record, is the basis for Silverlight (phone and Web), Windows Presentation Foundation (WPF), and now WinRT. It's not unique to Silverlight, nor did it originate with Silverlight. In fact, Silverlight's early codename was "WPF Everywhere".
I took some time this week to port a C# Silverlight app to C++ WinRT.
