Native-code access "on the radar" for Windows Phone developers

We have what looks like great news for current and potential Windows Phone developers. Now that Microsoft has made great strides with Windows Phone 7.5, they appear to be turning their attention to native access for developers, at least in some form. Up till now, developers have had no access to certain aspects of the OS, including telephony, codecs, graphic engines or deeper file access. Reasons for such restrictions were thought primarily to revolve around OS-stability and security. Now, Microsoft seems to be seriously considering opening up some native code to developers--either as part of a reconsideration of the policy or perhaps just being able to focus on implementation.

Stemming from a discussion on the Microsoft WPDev Feedback site, one of the most requested features is native development. In a subsection titled "How can we improve the WPDev application platform?" a suggestion of a Native SDK is sitting in the 4th spot with 1,000 votes. The thread is quite revealing as devs discuss how the current  limitations of the platform are hurting their work. One example comes from an iOS developer who states "I want to do DSP on WP7. My DSP algorithms in Tunepal (my app) take fractions of a second on IOS and Android (written in C++) and about 10 seconds to run on WP7." Likewise, others discuss the need for 3rd party gaming engines e.g. Unreal or Unity, both of which are currently not allowed in the OS.

Cliff Simpkins, Senior Product Manager for Windows Phone 7, posted a response to the native SDK request and didn't pull any punches:

"...we are interested in providing developers with more options to develop great apps for Windows Phone, and native is one item that is high on the radar."

The goal of his post, dated just three days ago, is to solicit specific feedback on what exactly developers want most e. g. C++, third-party gaming engines, etc.. As he points out, while it would be nice to give developers everything, Microsoft is on a fixed schedule needing to prioritize any such opening up of the platform. Clearly Microsoft would need time to develop the SDK, APIs and do what they do best which is make premium, easy to use developer tools. Putting that aside, it seems quite clear that Microsoft wants to open up the platform to developers, resulting in more feature-complete apps and games for consumers.

Microsoft's only hesitation at this time seems to be:  What parts do you want now and what do you want later?

Source: WPDev Feedback/User Voices; Big thanks to Amir, for the tip!

Daniel Rubino

Daniel Rubino is the Editor-in-chief of Windows Central, head reviewer, podcast co-host, and analyst. He has been covering Microsoft since 2007 when this site was called WMExperts (and later Windows Phone Central). His interests include Windows, laptops, next-gen computing, and for some reason, watches. Before all this tech stuff, he worked on a Ph.D. in linguistics, watched people sleep (for medical purposes!), and ran the projectors at movie theaters because it was fun.

  • Native code access doesn't necessarily mean that they will give developers access to the core features of the OS. iOS has had native code access since day one and it has all of the restrictions in the world.
    Either way, native access is something that is necessary and will mean a lot for the platform.
  • The point is that we'll have things like Unreal Engine made available.
  • Not necessarily, but here's to hoping eh?
  • We might also get proper audio apps with low latency and good timing...
  • I could say that this might be the one thing that can potentially bring in a horde of developers to the platform which need native access.
  • Would be nice to see this happen we might finally start to get some more of the games iOS gets now that it uses engines such and Unreal and Unity that have been stated in the post already.
    It would be nice to see Infinity Blade make it over to WP7 and maybe even Shadowgun and others! Surprised this is something Microsoft have not been pushing for its LIVE titles I would love games on those engines with achievements!
  • What does this mean for us mere app-using mortals? Can you give some examples of new features an app or game would have? 
    The more devs the better..
  • A few things, really.
    1) faster apps, in some cases.
    2) more crashy, in some cases. unsafe code and whatnot.
    3) most important part: more devs from other platforms bringing their apps to wp7.
  • The only "native code" access MS will give them is what they did with the sensors and the sensor API.   That is, 3rd party devs ask the native sensor api to do some work for their app so they don't have to write any native c++ directly to the sensors themselves.    This keeps things secure and managable in the end because any changes to the core bits of the OS or the sensors wouldn't effect your apps in the end because all you're doing is asking the API to give you an answer not trying to do the work on your own.
    The same can happen for DSP like in the example, MS can make a DSP/Sound API much like the sensor API and let you use that.  Once again, devs aren't writing directly to hardware but to a layer above.  This is the best way to do it for 3rd party devs as well since it takes away lots of code and time that you'd otherwise have to do yourself.
    As for 3rd party game engines, if MS wants, they can shift off of XNA which is the limiting factor here, and use more of DirectX which itself is yet another API and layer above the GPU.   The thing is that MS wants to keep portability, they don't want all these things to just stop working one day if they decided to change one bit of code in the OS etc.
  • I think MS is right to be so guarded about WP's security and stability. It's one of the stronger arguments for converting android users. At the same time, one of the biggest criticisms leveled against our beloved mobile OS is lack of apps, and MS may need to compromise a little to attract more high-end devs and software. Perhaps they could work directly with devs to create stable native code?
  • Oh! come on! C# IS NOT >10 slower than C++.
    He obviously doing it wrong.
    Everybody mean something else when they say 'native'. So microsoft is trying to understand what they really want.
    Some want to port C++ code. Managed C++ would be sufficient.
    Others want full access to phone's cababilities. Not gonna happen.
    A selected few mean custom shaders for XNA or access to DirectX.
    None of them actually gonna write directly to ARM's asm. 'Native' has become a buzzword and people think it's a panacea to their problems.
    What I see coming is Managed C++, custom shaders and maybe later directX api (dx11 on WP8).
  • I completely agree. I am surprised how many people (developers) do not understand .NET code is compiled from IL (intermediate language) instructions to native CPU instructions before actual execution. There is no way properly written C# code will execute 10x slower than its equivalent C++ code.
  • amen to that. No way it can be >10 times slower unless he did a very lazy port . No system will let you do some sort of auto convert and get the same performance unless your program is VERY simple.
  • Either a poor port or (that's my guess) he substitute a highly optimized C++ FFT with a simple textbook implementition.
  • Internally the MS devs are already sure to be calling some generic APIs they wont be calling the hardware directly every time too hard to control and keep stable. Its going to be a tidy up and publish effort
  • Surely it will be via WinRT?
    Essentially native code, but verifiable and without ability to call dangerous APIs.