Printable View
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.
"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 :)
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.
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.
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.
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...
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.
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 :)
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 :)
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.
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.
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.).
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.
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.
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.
"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 :)
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.
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 :)
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.
Don't even know how to comment the "lol" post but ok...some1 made some1 laugh.
W8 might be interesting to developers mainly because of the tablet market..
The fact that your app can be also deployed on a PC can't harm can it?
Porting is easy. Problem is it is the most anoying thing to do !
Porting isn't easy when you have to recode everything in a different programming language using a different toolkit and don't have access to Native Code on the new platform (WP7/8) when it was available on the others (Android, iOS).
What types of applications have you actually ported, especially games. Do you have any idea why so Many Windows games aren't ported to Mac or Linux? Precisely the reasons I mentioned. Porting to Console is easy since Development Firms get Native Code access while most indy developers don't nevermind frameworks like XNA run on Windows as well.
Im more academicly involved in programming so most things I ported were algorithms on graphs, genetic algorithms and stuff like that. It is true that in my field it is much easyer to port because other then different usage of data stuctures the idea of the algorithm is the same.
Up until some point porting game logic should be easy. Its just a different syntax thats all.
The game graphic i don't know much about but I what experience I have is that WP7 sux when it comes it.
I've been making a game my self for WP7 and spent a day implementing a custom pixel shader only to be greeted with an error something like "Custom pixel shaders are not alowed in WP7".
So native code must be a pain when it comes to games but apps should be a bit more simple.
My opinion is that if you coded it once you understand your code. If you understand it, a different language should be a minor setback.
Edit:
About the games on linux. Porting is not the reason why so little games are made for linux.
The problem is much bigger then it first seems and it might not be sutable for this forum since theres a lot of Windows guys here.
Wrong. In the early 2000s there was a huge movement to port games to Linux, and many were. Most of them were OpenGL games. Loki was a huge part of that. Games like Quake 3 [Team] Arena and Neverwinter Nights were ported to Linux, among many others. Those were all OpenGL games. This was at the height of Linux hype (when ZDTV was raving about it and showing people how to install it on Leo Laporte's show like 3 days a week, Lol).
But there were a ton of games that couldn't be ported, because DirectX usurped OpenGL as the [generally] preferred API for game development and it's not portable to non-Microsoft OSes. That's why a lot of games aren't ported to Mac OSX. Same difference.
We all know about Linux' lack of backward/forward compatibility, unstable kernel driver ABI, crappy X.ORG, and 100k different distros with varrying configurations/package versions/etc. We know about its sub 2% marketshare as well.
That still is non-factor because DirectX stops that before you even get to those considerations. You'd have to port the whole graphics engine (built on DirectX) to OpenGL or use some generally terrible (for large scale projects) API layer like Wine to even get the game to compile and run on Linux or MacOS, which isn't worth the money or time given Windows' desktop marketshare. The first thing any company looks at when considering a port is whether the graphics engine and other libraries (additionally physics engines, UI toolkits, etc.) are portable. With game development costing millions these days and developers already (in many cases) rushing products to market due to budgeting issues, non-portable engines and Libraries simply cost too much to work around.
Additionally, you can use XNA (also unportable and built on DirectX IIRC) to target both XB360 and Windows Desktop OSes.
Some graphics engines can use both OpenGL or DirectX but not all and I'm not even sure if we can say the majority can...
Yes, porting logic code can be trivial, even between platforms AND programming languages. Stuff like this, however, isn't. If the UI toolkits and graphics engines are not available, it means you aren't porting the code but essentially rewriting it for the other platform. Alternatives almost always exist, but it's a cost/effort vs. returns (often monetary) consideration.
I still belive that if the development studios saw profit in porting games to Linux they would do it.
Note that linux may have 2% market share but those 2% are not desktops but mostly servers.
With such a low market share I can't find any reason why game studios would invest time into linux.
Tha graphic Librarys can be a problem but i still think that if they saw profit in the platform they would port their game, graphic and physics engines and from there on just port the games on regular bases.
I do agree on the fragmentation Linux distros have. Those problems could be solved if there was any point in solving them. The whole point of distros is the difference between them and the task they are meant to be used for.
Another thing that comes to mind is that the development process of a game is very expenssive but not only because of development but also because of design.
Designers play a big part nowdays with all the graphic details and 3D modeling needed.
Those costs don't apply when porting games or do they?
Back on topic
We started this discussion on general porting.
Though both of us have different opinions on porting we probably can agree that porting games on mobile platforms is easyer?
For example. most games use physics engines like box2D that is supported on all platforms.
WP7 has farseer physics that is a clone of Box2D. Where a few steps from having some cross-platform graphics enegines.
If those were available porting would be a peace of cake.