Native SDK for windows phone 7 devices

[sb1370]

As
Native SDK to support C++ Development
native sdk for winphone is under review.
Does 1st and 2nd gen devices get an update that able to run native apps on them?
Or it will be for apollo devices?
I'm going to buy a new phone and can't wait till october.

 

[rbrunner]

Only under review

"Under review" means that they are thinking about it, with uncertain outcome. Check other items on their site - there are an awfully lot of things under review which certainly won't all materialize.

Apollo may or may not appear in October. It may or may not be available for 1st and 2nd gen devices, or maybe appear for them much later. Apollo may or may not include the possibility for app devs to code directly in C++. This coding in C++, if available, may be more difficult and/or less of an improvement over C# than people hope.

Now you may or may not commit to a WP7 phone

 

[Dormage]

Without access to native code this platform is dead!
Closing an OS as much as they did prevents developers from writing apps that actualy function!
Faking background working and multitasking when infact none of it actualy works.
Apps running in background? Right... its just a cron job that calles your app every 15 minutes.

 

[rbrunner]

Does not need native access

Technically it would be no problem to multitask even "normal" C# apps. Just to add multitasking no native access is needed, these two things are not necessarily linked.

And anyway, native access could develop into a massive headache. Up to now, all WP7 phones are based on the ARM architecture, but if Intel becomes better with their low-power CPUs that could change, and after that you would have to deal with different instruction sets.

I really don't think that WP7 is dead without native access, but I do think that the almost totally locked-down APIs could snowball into a growing disadvantage.

 

[Dormage]

Your right, it isn't a problem with multitasking or background running. No need for native access if the OS would do things the right way! I never understood why WP7 brags so much on the fact that it does not need better hardware to work fluent. And then limations like this clearly show they running apps in the background is CPU consuming. Native access would solve a bit of those problems alowing skilled developers to override limitations like that?

I might have exaggerated a bit by saying WP7 is dead without native access but some limitations are so frustrating that many developers feel in chains when dealing with WP7.
Some apps can't even be ported from other platforms due to limtations like this.

 

[rbrunner]

Has its logic

I must say that up to a point I understand Microsoft:

Microsoft got a very bad reputation for all their security problems and breaches on normal Desktop Windows. It took them years to tame these problems, and they are still far away from a true "solution".

I guess that somebody inside Microsoft said: The very last things that we need now are viruses and trojans on WP7. Security must be very good. If it isn't people will shout "I knew it, I knew it, it's Windows, what did you expect, it will never change".

Some high-profile malware incident on WP7 could, in the worst case, destroy the platform in the eye of the public. Missing apps because they are not possible due to API restrictions on the other hand are nowhere this dangerous.

Unfortunately, the easiest way to good security is a very limited API. If you can't to anything, at least you won't do anything bad...

 

[Dormage]

Security might be one of the problems they are facing. This might be even the reason why they closed the platform so tight. But you've opened another huge discussion that
I think the past security risks Microsoft had, had little to do with the OS not beeing safe. It's just that from a "hacker's" point of view you write malware and viruses for a platform that will have the largest effect.
The fact is most computers run Windows. With the Mac's getting some marketshare in the past few years you can notice viruses are begining to pose a threat to mac OS as well.

You do have a point about security on mobile platforms. We saw lots of android phones infected. I think there are two things that provided those infections, the platform it self and the popularity of the platform and the impact the malware potencialy has.

That beeing said I still have hope the platform will open up just a little bit more.

 

[thed]

I'm guessing that the native SDK, if it comes, will only support WP8 and beyond. So whether it supports first gen devices will probably depend on whether or not they get updated. My guess is no, but I'd rather not open that can of worms in this thread, since there are several raging debates elsewhere in this forum

 

[Dormage]

Many debates not only on this forum but everywhere.
I my self don't worrie too much. If they woun't support it I will flash it my self

 

[sb1370]

Is it ok to buy a win phone today and wait for ndk for it?
Or buy an android device?
I want to be loyal to Microsoft!

And NDK is important for me. Some apps should be written in native codes.(emulators, players,browser,...). I had windows mobile for its great apps and you could find every app you needed. it was for supporting na
tive code.

 

[Dormage]

I think waiting is the single worst thing you can do
If your asking for an advice from the developers point of view I suggest go for WP7.
Android and IOS have tons of apps alrady and its realy hard to get people to notice your app.
WP7 is still a small market and your app will probably have better chance of sucess on WP7.

If your asking from a sonsumer point of view the answare would still be yes, buy it now!
It is true that emulators usualy use some native code but you have the NES emulator that is a living proof it dosen't have to be that way.
Browsers are another thing but IE9 is pritty fast and you will rarly have the need for any other. Other browsers will probably come with WP8 and if the platform gains marketshare.

 

[N8ter]

Technically it would be no problem to multitask even "normal" C# apps. Just to add multitasking no native access is needed, these two things are not necessarily linked.

And anyway, native access could develop into a massive headache. Up to now, all WP7 phones are based on the ARM architecture, but if Intel becomes better with their low-power CPUs that could change, and after that you would have to deal with different instruction sets.

I really don't think that WP7 is dead without native access, but I do think that the almost totally locked-down APIs could snowball into a growing disadvantage.

The only time you have ot deal with a new instruction set directly is if the Endianess is different (which can pose issues for some data structures, etc. and even then you're not really dealing with it, just have to work around platform differences as a result - apps like Microsoft Office have to deal with this) or if you either use Inline Assembly or code modules directly in Assembly Language (Different Instruction Set, Registers named differently, syntax differences even between different Assemblers on the same platform i.e. ML/TASM vs. GNU Assembler). The reason why people use HLLs is precicely to abstract the CPU to the point where they can write fairly portable code without having to delve to that level.

With Native + XNA Interop and a Native DirectX SDK for Windows Phone (in C, perhaps) it should not be a huge issue.

I don't think anyone here is a compiler/linker writer, so you shouldn't really care much about what platform runs under the hood. The compiler/linker (or VM in many cases) abstracts that.

Standard C/C++ on ARM is the same as Standard C/C++ on x86 with only a few exceptions that preprocessor directives can probably [very] easily fix.

Virtual Machines (i.e. .NET/Java) are no different (as implied). They have to run the bite code equally well on all architechtures supported.

The reasons to avoid C/C++ is not because of the instruction set differences. It's cause bad code is bad and Native C/C++ runs at a level that can cause issues if bad code starts misbehaving (remember HTC Sound Enhancer issues after Mango update?) - and also security issues (buffer overflow exploits, etc.).

 

[rbrunner]

Very good technical info

Very good and detailed info about technical aspects of an NDK.

Yes, you are right, in theory an NDK and HLL compilers abstract away any instruction set and architecture differences. The Android NDK is probably living proof of that, or the native code stuff that Google wants to introduce into its desktop Chrome browser.

My worries are this: With native code allowed the complexity of the whole system takes a pretty large jump upwards, and I have learned over the years to be very wary of complexity.

Instead of a system with 1 API running just managed code C# you have a system with two different compilers for C# and C++, probably 2 APIs as well, a more complex app file format with code for 2 different architectures in it (hoping no third surfaces, making all exisiting apps with native code in it problematic).

This means more chance for bugs, more danger for security holes, more chance a bug can take down the OS itself and force a phone reboot, more chance for programs that are not able to run cleanly on subsequent OS releases, and so on.

And what's on the positive side of all this?

I think offering more C# based APIs and opening the too-tight security model somewhat is a much more promising way to go. For things that absolutely must be native code because of performance problems (less and less things, there soon will be quad core smartphones, for heaven's sake) Microsoft itself could deliver something as part of the OS.

 

[Dormage]

When you talk about securty and apps that can harm the OS I think your missing the point.
Every app adds a bit of $ to Microsoft. The developer pays a % to Microsoft of every sold instance of an app. One of the reasons developers pay a % is because Microsoft provides quality service on app sumbition. Those services include app testing (black box and white box testing) to prevent any abuse or content that is not alowed. My expereience with those services is that they are very detailed.
I had an game that has sound effects and background music.
My app was rejected because I didn't check for the availability of the music player before playing the music. In some cases if a user is listening to music and starts my game. His/Her music would stop playing and the apps would take control. By M$ standards that it's not acceptable !

What I'm trying to point out is that they are very detailed when testing apps before publishing them. They get payed for it well and they do it well. It is their job to do it and even in the case of native code they would do the same!
App testing needs to server as a spam filter and a firewall and most of them do!
I can't see a security problem you mentioned if the app testing is effective.
Would a more strict app testing for apps using native code be a solution to such problems?
I belive it can be.

 

[Jeff Kibuule]

It's not as if a native SDK lets you suddenly jump outside of sandboxing. Windows 8 and OS X Lion already disprove that notion. However, it's possible to have more exploits and security holes when you no longer have a VM acting as an extra security layer.

Thing is, the benefits to native code are so numerous that they can't be ignored. Direct porting of game engines (Unreal Engine 3 among others), ability to use DirectX instead of XNA (which is far closer to the OpenGL most mobile developers are used to), and the ability for "good" developers to more heavily optimize their code compared to running in a VM.

 

[FLC]

"ability to use DirectX instead of XNA"

Isn't XNA technically just a wrapper over DX9?

Not that I disagree with your comments about sandboxing/c++ in general

 

[sb1370]

I need J2ME emulator.
It was available in windows mobile (And so many great apps).
If Windows mobile wasn't discontinued I'd buy a windows mobile device.
And please give me an advice.

 

[Dormage]

If I understand this right your trying to emulate java micro edition in Windows Phone 7 ?
If that is the case you will have to write the emulator your self.
Writing emulators is a pritty big project..
Maybe it allrady exists but I'm not sure...do check the Ineternet

 

[Jeff Kibuule]

"ability to use DirectX instead of XNA"

Isn't XNA technically just a wrapper over DX9?

Not that I disagree with your comments about sandboxing/c++ in general

It probably is, but you as the average developer still can't directly access DirectX in your code. And what that really stops is porting of game engines, since every game developer, not just the middleware engine provider, would need NDK access.

Honestly, I wouldn't be worried. The only difference between Windows 8 and Windows Phone 8 from a developer's point of view should be the UI layout. All of the APIs and hardware functionality should be the same, making it extremely easy to build a Windows Phone and Windows 8 app at the same time (thus solving the "app" problem Windows Phone seems to have).

 

[N8ter]

It probably is, but you as the average developer still can't directly access DirectX in your code. And what that really stops is porting of game engines, since every game developer, not just the middleware engine provider, would need NDK access.

Honestly, I wouldn't be worried. The only difference between Windows 8 and Windows Phone 8 from a developer's point of view should be the UI layout. All of the APIs and hardware functionality should be the same, making it extremely easy to build a Windows Phone and Windows 8 app at the same time (thus solving the "app" problem Windows Phone seems to have).

I guess that would be true if most developers do port their apps over to WP8/W8, but I don't see how it's a dependable assumption since companies like Zynga are already making bank concentrating almost exclusively on Android and iOS while ignoring the desktop altogether. It depends on how much potential they see in porting, which can lean heavily on Windows 8 adoption and I'm not sure it can be expected to skyrocket the way Windows 7 did (not being preceeded by a near decade old XP and disastrous/avoided Vista release).

Especially when you can already play some of their more popular games on Consoles, Facebook, or Native Windows 7.