Developers developers developers!

Devs, responding to reviews boosts your ratings

Developer news!

Respond to customer reviews

Developers

New SDK and Emulators now available for developers

Apps

Windows Phone a target of more than 1/4 of app developers, despite market share

Developers

Developers: Here's how to give users the option for a Transparent Live Tile (Updated)

Developers

Xbox One games to benefit from major graphics boost with new XDK

Software

Internet Explorer Developer Channel offers bleeding edge web experience

Windows Phones

The journey of the Windows Phone platform and state of the ecosystem

Apps

Microsoft launches official #wpdev Windows Phone 8 app for developers

Developers

Low memory devices lead Windows Phone downloads, games are most popular category

Developers

Telerik makes controls free for a limited time in honor of TechEd 2014

Apps

Adobe releases PhoneGap Developer for Windows Phone

Developers

Learn to develop for Windows Phone 8.1 in one weekend with Channel 9

Developers

Windows Phone developer hooks up Cortana to control his lights

Developers

Windows Phone 8.1 and universal apps can now be submitted to the Dev Center

Developers

Microsoft to host new Publish Windows developer days with awesome prizes

Developers

Bookmark this: Microsoft's highlights from Build 2014

Developers

Microsoft releases unified Windows App Studio Beta

Microsoft News

Microsoft releases Windows Phone 8.1 SDK Development Tools RC

Developers

Google releases official APIs for Windows Phone developers

< >
16

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

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!

1
loading...
12
loading...
72
loading...
0
loading...

Reader comments

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

16 Comments

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.

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.