I think it is better to focus on being able to write apps in VS.NET that are targeted to the different platforms as native apps (rather than webviews).
1 - C# is not native code, it is slow, even slower than Java
2 - targeting platform native libraries and APIs will result in applications which are not portable - you will have to write the application for every different platform, as they all come with different application APIs
Currently, when portability of applications and development efforts are concerned, Qt is the best, or if you wish - the least sucky solution - it is C++ at its core, so it is as fast and efficient as it gets, and you code against the Qt libraries, so the same application code will work out of the box on every supported platform with no or at most very little modification. And it has QML which is very easy and fast to work with, way better than XML based markup and integrates JS directly.
We are saying the same thing. We want portable apps so the comparison is about whether the QT APIs are 'better' than the MS APIs for what you want to do, i.e.: If you need to squeeze every single bit of performance out of a device which API simplifies coding of the app while giving you as much performance as possible?
Mostly the choice of syntax. It is a lot like JSON, so instead of the XML-like <tag> content <endtag> you simply tag { content }. The there is the property binding, which is an extremely flexible and powerful feature. Also, JS is directly integrated, integrating with C++ code is very easy, as is the ability to define your own types in C++ and use those in QML. Lastly - the runtime performance is rather good and efficient - compared to webview based applications.
Modern hardware certainly has the power to spare, allowing more and more widespread use of inefficient scripting languages for application development. But even then, aside from performance never hurting anyone, in the case of mobile devices, battery life will surely appreciate the reduced CPU cycles. Memory usage is an important factor too, again - especially on mobile devices, where RAM is still fairly small in volume - it is not uncommon to see C/C++ workloads using 3-4+ less memory than the same workloads implemented in Java/JS/C#
Finally - MS has the habit of designing some fugly APIs, even the latest and "greatest". People who haven't seen better cannot really appreciate that though.
Sounds enticing, but the languages features you mention are also found in other languages like C#, Java, JS, Ruby, etc tosome extent to help you build different types of workloads while still caring about managing your resources like memory, battery, etc.
APIs is a different aspect which I agree to some extent and look to QT, Xamarin, and similar to address.
Every language has a runtime, including C and C++, which are as hardware native as it gets. This applies even more so to C#, as it is also a managed language.
Having a run time is not the same as being native/not native. With the Xamarin stuff you can apparently compile c# to actual native code, with and not just MSIL.
Not to belabor the point, but every JIT-ed language compiles to native code - i.e. machine code, be that Java, JavaScript, C# or whatever.
However, from the performance figures of those it is quite obvious that there is more to the story than whether it is native or interpreted code - even if C# is compiled to native code, it is nowhere as fast and efficient as native code, produced by a C/C++ compiler from C/C++ code.
There are many reasons for it, but the most prominent being that managed languages are simply not cache friendly, and that JIT compilation, aside from the hype from its proponents, is nowhere nearly as good at optimizing as the ahead of time compilation of code that is close to the hardware. Managed languages are abstracted away from the hardware, so there is not that much room for code analysis and optimization.
.NET was already JIT. What they're talking about is stuff like .NET Native (there have been other solutions around for some time too). It's not JIT. Yes it has a minimal runtime, and no that doesn't mean it's "not native". Far from it. The developers don't even need to compile it themselves, it's done in the cloud. This allows for faster app installs vs compiling locally, but since it's done in the cloud the code can be recompiled easily for new targets, when the compiler sees improvements, etc.
As far as libraries and APIs go, they already have the iOS bridge written, they could build on top of their work there to go the other direction, or they could port their APIs and libraries. Similar to Qt. So it's not impossible for them to go multiplatform/portable. But it's hard to say what their goal is, so I'm not certain how they will proceed.
It all makes sense now, why you think c# is slow. You're looking at C# compiled for the Mono VM and mistakingly concluding that C# compiled to Microsofts CLR VM is slow. C# on CLR (windows) is is very fast.
Unlike yours, which only talks silly ;) Performance figures can be empirically proven, it is not a matter of subjective opinion, if you have something factual to say on the subject - put up or shut up.
Performance can be proven, but only with relevant comparisons. Comparing the performance of C++ to a third-party .NET runtime (Mono) is not indicative of the performance of the official runtime or pre-compiled C# code.
I am one of the most vocal Qt critics, and unlike most of its user base, I have no problems admitting that it sucks, and the only reason I use it is that it is the least sucky solution.
@ddriver: "1 - C#... is slow, even slower than Java" I can tell you from personal experience that for the use cases that I had, both developing the code and executing the code was faster in C# than it was in Java.
And Xamarin's been doing great work. Given that .NET is in the process of being ported to Linux and .NET has consistently been closer to the metal than Android's various VMs and RTs, I wouldn't be surprised if .NET ends up being more native than Java on even Android.
Isn't the point that Xamarin makes it portable?
C++ is "as fast and efficient" as you can get it to go. Not the same thing.
I wonder if this is due to how well the iOS bridge is coming along and they don't want the confusion of having 2 big bridges; or if this is because the Android bridge just had issues and had to be abandoned.
Astoria ended up not being a "bridge" but more akin to an entire android subsystem. All of the W10 Mobile builds with Astoria enabled ended up having degraded performance the longer they ran due to the "effective" Android subsystem siphoning resources.
Astoria was nothing like Islandwood - it was not a "recompile and forget" process, it was literally running native Android binaries on windows phone by catching and modifying native android calls... the overheads were enormous, and ended up impacting native applications.
It never made sense for Microsoft to introduce a bridge for one ecosystem (islandwood) and then a whole-hog abstraction layer for another. If they re-imagned Astoria as a bridge (like Islandwood) but for Android applications, it would be far more successful, far more usable, and would in no way detract from making native Windows Phone applications.
I don't really feel that's much of a valid concern though. Android applications can't call what isn't in the SDK, so Microsoft just needs to use the SDK as a base for the bridge. As long as they can provide analogues for all of the calls used in the SDK, they can build a bridge compatible with all apps built against that version of the SDK.
Any calls that don't have direct analogues will need to be coded for on an as-needed basis, but since Microsoft controls both half of this potential software stack (Bridge and OS), they wouldn't have much issue doing so with minimal performance loss, so long as performance-critical calls were handled natively rather than abstracted.
Note that my comment also included the NDK extensions to the SDK for covering native syscalls. Luckily those are getting rarer in Android development, since they tend to limit application compatibility between devices. Only apps made purely using the SDK are officially going to work across all Android versions (and handsets) that support that level of SDK, so it's a good place to start for Microsoft to get the best compatibility, with the least amount of work.
It's very easy to make Windows Phone apps or port Android apps to the platform. The problem with the lack of apps is not due to a shortage of talent, experience or tooling, it's due to incumbent project bureaucracy and the perceived cost of supporting an extra platform. If your budget or timelines are tight, the small market of the Windows version of your app is the first to go.
A full abstraction layer would alleviate this, particularly if WP10 were to have access to the Play store, as the software houses wouldn't have to do anything at all.
It's a shame these technical hurdles were insurmountable, as I don't see Islandwood as fixing the right problem.
most apps that have any level of usefulness and success also get developed for iOS quite soon, if you can port that to W10 mobile, then that's good enough. That android thing surely wasn't an optimal solution.
What's confusing to me is, they've had Xamarin for years to be able to port any application to all three platforms, but yet, Microsoft itself is releasing IOS and Android only Office applications... as a Windows 10 Mobile user, I know this first hand, because when you run into them, the hand must scratch the head. If you are promoting Xamarin to be what your developers should use, but don't use it yourself for the exact purpose you are telling developers to use it for, what does that tell your developers, the developer community and any end users who care to understand and comprehend this?
While MS works with Xamarin for quite some time, they are not actually a single entity (until MS bought the company). Xamarin has business to operate, it offers Mono for iOS/Android for a price that might not be too compelling to everyone.
To get developers on board, MS has to do something to attract those rather than just says "hey, you can use Xamarin's tool to port your apps to us", and ask them to pay $999 (per developer) annually to Xamarin which is the 3rd party. Also using Xamarin tools means rewritting the code. It's not like you have a iOS or Android app and use Xamarin to port it, rather you just have a common ground so people can write codes once and (hopfully) can use them accross platform (except for some UI-specific code, if I'm not mistaken).
And, at $999 a year, is pretty high for a developer tool. IntelliJ offers a buffet of all tools they have at $649 a year (and the price would go down for each subsequence years). The cost of development plus the subscription fee would be enough to drive people away. MS has to come with a better plan, that's why they come up with those projects.
When i first bought Nokia Lumia 620 i was able to download great Youtube App from MS itself. As i have quickly discovered it was not app at all, it was just image with direct link to youtube website. I guess that app was ruining on Project MS LAMOs. This app might be still there.
Project this , project that, bala bla bla if MS wants to get more market share than laughable 5% it should not only give developers options to port their app but also just simply pay best developers to make sure they will port their app. MS has more than enough $$$ to do so.
With 5% market share it is just waste of time and money to bother to do any ports.
MS actually built a really nice YouTube client but was forced to take it down by Google, which opposes users accessing its products from Windows phones (see what they did with Google Maps on WP8). Nonetheless, MyTube and Perfect Tube on Windows Phone are better than Google's first-party YouTube apps on iOS and Android.
Google refused to release their apps for the new Win runtime. So in the case of youtube MS made one themselves. The original MS-built YouTube app was great. They were later forced to trash it because Google actually BLOCKED the app from accessing content. I was around when this happened and saw it in action. One day, the app works great. The next, mysterious errors prevented you from playing anything. A quick search revealed Google was intentionally blocking the app.
Hence the current inferior version was released that just directs you to the youtube mobile site. But as amb said, there's several good third party solutions.
what's funny: Google was/is fighting with Sun over Android being java. It isn't on the device, of course. Google takes the java/jvm bytecode and converts it to dalvik/ART code. M$ could have done the same: convert dalvik/ART to whatever.
"...the question then became why you wouldn't just go buy an actual Android device"??
And that pretty much sums it all up, doesn't it? Frankly, I'm a bit tired of this new MS CEO's attitude, concerning Windows 10, of "Take it or leave it, we don't care". Fine, neither do I, and since I've now taken the time to reassess my computing needs that require Windows operating system, I'm finding out that they are few and far between.
Since MS obviously doesn't give a crap about the little guys, I'm more than happy to make the jump to another OS. If MS is going to act like Apple during the Steve Jobs era, so be it.
Microsoft in years past has exhibited the attitude you mention. I think that's more an indicator of the company's position of market dominance influencing executive management decisions than something specific to the current CEO. However, I also agree that there are viable options outside the Microsoft ecosystem that can fulfill most day-to-day computing needs as long as one is willing to accept a different set of platform limitations.
The lack of data collection transparency from Microsoft that seemed to begin during the Windows 8.1 to 10 transition was enough to push me into taking a long, hard look at what I do with a computer and figure out that any of the more popular Linux distros would address every categorical computing need I could identify. Having dabbled in various *nix operating environments since the late 1990s, the transition for me was an easy one. The only thing I gave up were a few games that I didn't care bring over because I don't want to add WINE, but those are the lowest priority items on my list and there's lots of other entertainment available in native binaries.
To get back to the article though, I think what we're seeing is part of Microsoft's surrender of the mobile market to Apple and Android. They're still failing to capture more than the smallest fraction of handset sales so investing in development platforms isn't good for the balance sheets. Unless something dramatic happens in the mobile market over the next year or two, I expect to see Windows 10 Mobile to go to the same graveyard in which earlier PDA-based Windows Mobile is buried.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
45 Comments
Back to Article
atirado - Thursday, February 25, 2016 - link
I think it is better to focus on being able to write apps in VS.NET that are targeted to the different platforms as native apps (rather than webviews).ddriver - Thursday, February 25, 2016 - link
That's a big no for two good reasons:1 - C# is not native code, it is slow, even slower than Java
2 - targeting platform native libraries and APIs will result in applications which are not portable - you will have to write the application for every different platform, as they all come with different application APIs
Currently, when portability of applications and development efforts are concerned, Qt is the best, or if you wish - the least sucky solution - it is C++ at its core, so it is as fast and efficient as it gets, and you code against the Qt libraries, so the same application code will work out of the box on every supported platform with no or at most very little modification. And it has QML which is very easy and fast to work with, way better than XML based markup and integrates JS directly.
atirado - Thursday, February 25, 2016 - link
We are saying the same thing. We want portable apps so the comparison is about whether the QT APIs are 'better' than the MS APIs for what you want to do, i.e.: If you need to squeeze every single bit of performance out of a device which API simplifies coding of the app while giving you as much performance as possible?What makes QML better?
ddriver - Thursday, February 25, 2016 - link
"What makes QML better?"Mostly the choice of syntax. It is a lot like JSON, so instead of the XML-like <tag> content <endtag> you simply tag { content }. The there is the property binding, which is an extremely flexible and powerful feature. Also, JS is directly integrated, integrating with C++ code is very easy, as is the ability to define your own types in C++ and use those in QML. Lastly - the runtime performance is rather good and efficient - compared to webview based applications.
Modern hardware certainly has the power to spare, allowing more and more widespread use of inefficient scripting languages for application development. But even then, aside from performance never hurting anyone, in the case of mobile devices, battery life will surely appreciate the reduced CPU cycles. Memory usage is an important factor too, again - especially on mobile devices, where RAM is still fairly small in volume - it is not uncommon to see C/C++ workloads using 3-4+ less memory than the same workloads implemented in Java/JS/C#
Finally - MS has the habit of designing some fugly APIs, even the latest and "greatest". People who haven't seen better cannot really appreciate that though.
atirado - Saturday, February 27, 2016 - link
Sounds enticing, but the languages features you mention are also found in other languages like C#, Java, JS, Ruby, etc tosome extent to help you build different types of workloads while still caring about managing your resources like memory, battery, etc.
APIs is a different aspect which I agree to some extent and look to QT, Xamarin, and similar to address.
Brett Howse - Thursday, February 25, 2016 - link
C# can be compiled as native code for UWP apps:http://www.anandtech.com/show/9661/windows-10-feat...
The Xamarin purchase yesterday also outputs native code targeting the different platforms.
C# is a programming language, not a runtime. .NET has traditionally used a runtime on older versions of Windows but it's not always the case now.
ddriver - Thursday, February 25, 2016 - link
Every language has a runtime, including C and C++, which are as hardware native as it gets. This applies even more so to C#, as it is also a managed language.Dunno what code Xamarin outputs, but from the looks of it, it is on average 3-4 times slower than C++: http://benchmarksgame.alioth.debian.org/u64q/compa...
extide - Thursday, February 25, 2016 - link
Having a run time is not the same as being native/not native. With the Xamarin stuff you can apparently compile c# to actual native code, with and not just MSIL.ddriver - Thursday, February 25, 2016 - link
Not to belabor the point, but every JIT-ed language compiles to native code - i.e. machine code, be that Java, JavaScript, C# or whatever.However, from the performance figures of those it is quite obvious that there is more to the story than whether it is native or interpreted code - even if C# is compiled to native code, it is nowhere as fast and efficient as native code, produced by a C/C++ compiler from C/C++ code.
There are many reasons for it, but the most prominent being that managed languages are simply not cache friendly, and that JIT compilation, aside from the hype from its proponents, is nowhere nearly as good at optimizing as the ahead of time compilation of code that is close to the hardware. Managed languages are abstracted away from the hardware, so there is not that much room for code analysis and optimization.
Alexvrb - Saturday, February 27, 2016 - link
.NET was already JIT. What they're talking about is stuff like .NET Native (there have been other solutions around for some time too). It's not JIT. Yes it has a minimal runtime, and no that doesn't mean it's "not native". Far from it. The developers don't even need to compile it themselves, it's done in the cloud. This allows for faster app installs vs compiling locally, but since it's done in the cloud the code can be recompiled easily for new targets, when the compiler sees improvements, etc.https://msdn.microsoft.com/en-us/library/dn584397(...
As far as libraries and APIs go, they already have the iOS bridge written, they could build on top of their work there to go the other direction, or they could port their APIs and libraries. Similar to Qt. So it's not impossible for them to go multiplatform/portable. But it's hard to say what their goal is, so I'm not certain how they will proceed.
DerekZ06 - Friday, February 26, 2016 - link
It all makes sense now, why you think c# is slow. You're looking at C# compiled for the Mono VM and mistakingly concluding that C# compiled to Microsofts CLR VM is slow. C# on CLR (windows) is is very fast.lmcd - Friday, February 26, 2016 - link
He's also ignoring that Roslyn is bringing .NET to Linux. No doubt, Android will be a follow-up target of that particular branch of .NET.lilmoe - Thursday, February 25, 2016 - link
"even slower than Java""result in applications which are not portable"
That behind of yours sure talks big...
ddriver - Thursday, February 25, 2016 - link
Unlike yours, which only talks silly ;) Performance figures can be empirically proven, it is not a matter of subjective opinion, if you have something factual to say on the subject - put up or shut up.MartenKL - Friday, February 26, 2016 - link
DDriver, didn't see you post actual benchmarks on mobile devices. C# does pretty well on iOS according to this post https://medium.com/@harrycheung/mobile-app-perform...Guspaz - Friday, February 26, 2016 - link
Performance can be proven, but only with relevant comparisons. Comparing the performance of C++ to a third-party .NET runtime (Mono) is not indicative of the performance of the official runtime or pre-compiled C# code.The_Assimilator - Friday, February 26, 2016 - link
Your posts show an amazing lack of understanding of how C#/.Net actually work.lmcd - Friday, February 26, 2016 - link
Qt shill. Yes, it's a great toolkit, but it's not exactly Christ-like.ddriver - Saturday, February 27, 2016 - link
I am one of the most vocal Qt critics, and unlike most of its user base, I have no problems admitting that it sucks, and the only reason I use it is that it is the least sucky solution.boozed - Saturday, February 27, 2016 - link
Calling someone a "shill", the new corollary of Godwin's Law.AndrewJacksonZA - Friday, February 26, 2016 - link
@ddriver: "1 - C#... is slow, even slower than Java"I can tell you from personal experience that for the use cases that I had, both developing the code and executing the code was faster in C# than it was in Java.
lmcd - Friday, February 26, 2016 - link
C# is slower than Java? Where have you been?And Xamarin's been doing great work. Given that .NET is in the process of being ported to Linux and .NET has consistently been closer to the metal than Android's various VMs and RTs, I wouldn't be surprised if .NET ends up being more native than Java on even Android.
Isn't the point that Xamarin makes it portable?
C++ is "as fast and efficient" as you can get it to go. Not the same thing.
ddriver - Saturday, February 27, 2016 - link
OK, let's be generous and say it is not slower, but only AS SLOW as Java, still far from ideal.CaedenV - Thursday, February 25, 2016 - link
I wonder if this is due to how well the iOS bridge is coming along and they don't want the confusion of having 2 big bridges; or if this is because the Android bridge just had issues and had to be abandoned.Omoronovo - Thursday, February 25, 2016 - link
Astoria ended up not being a "bridge" but more akin to an entire android subsystem. All of the W10 Mobile builds with Astoria enabled ended up having degraded performance the longer they ran due to the "effective" Android subsystem siphoning resources.Astoria was nothing like Islandwood - it was not a "recompile and forget" process, it was literally running native Android binaries on windows phone by catching and modifying native android calls... the overheads were enormous, and ended up impacting native applications.
It never made sense for Microsoft to introduce a bridge for one ecosystem (islandwood) and then a whole-hog abstraction layer for another. If they re-imagned Astoria as a bridge (like Islandwood) but for Android applications, it would be far more successful, far more usable, and would in no way detract from making native Windows Phone applications.
lmcd - Friday, February 26, 2016 - link
Well, yes and no -- the more open nature of Android means that there can be surprising system calls that you wouldn't get in iOS development.Omoronovo - Saturday, February 27, 2016 - link
I don't really feel that's much of a valid concern though. Android applications can't call what isn't in the SDK, so Microsoft just needs to use the SDK as a base for the bridge. As long as they can provide analogues for all of the calls used in the SDK, they can build a bridge compatible with all apps built against that version of the SDK.Any calls that don't have direct analogues will need to be coded for on an as-needed basis, but since Microsoft controls both half of this potential software stack (Bridge and OS), they wouldn't have much issue doing so with minimal performance loss, so long as performance-critical calls were handled natively rather than abstracted.
Omoronovo - Saturday, February 27, 2016 - link
Note that my comment also included the NDK extensions to the SDK for covering native syscalls. Luckily those are getting rarer in Android development, since they tend to limit application compatibility between devices. Only apps made purely using the SDK are officially going to work across all Android versions (and handsets) that support that level of SDK, so it's a good place to start for Microsoft to get the best compatibility, with the least amount of work.Chufteh - Friday, February 26, 2016 - link
It's very easy to make Windows Phone apps or port Android apps to the platform. The problem with the lack of apps is not due to a shortage of talent, experience or tooling, it's due to incumbent project bureaucracy and the perceived cost of supporting an extra platform. If your budget or timelines are tight, the small market of the Windows version of your app is the first to go.A full abstraction layer would alleviate this, particularly if WP10 were to have access to the Play store, as the software houses wouldn't have to do anything at all.
It's a shame these technical hurdles were insurmountable, as I don't see Islandwood as fixing the right problem.
Cliff34 - Friday, February 26, 2016 - link
I sure hope there are good apps being developed for Windows 10. No good apps = the death of mobile market for Microsoft.Murloc - Friday, February 26, 2016 - link
the most used apps are all good.Murloc - Friday, February 26, 2016 - link
most apps that have any level of usefulness and success also get developed for iOS quite soon, if you can port that to W10 mobile, then that's good enough. That android thing surely wasn't an optimal solution.Dodge1350 - Friday, February 26, 2016 - link
What's confusing to me is, they've had Xamarin for years to be able to port any application to all three platforms, but yet, Microsoft itself is releasing IOS and Android only Office applications... as a Windows 10 Mobile user, I know this first hand, because when you run into them, the hand must scratch the head. If you are promoting Xamarin to be what your developers should use, but don't use it yourself for the exact purpose you are telling developers to use it for, what does that tell your developers, the developer community and any end users who care to understand and comprehend this?mr_tawan - Friday, February 26, 2016 - link
While MS works with Xamarin for quite some time, they are not actually a single entity (until MS bought the company). Xamarin has business to operate, it offers Mono for iOS/Android for a price that might not be too compelling to everyone.To get developers on board, MS has to do something to attract those rather than just says "hey, you can use Xamarin's tool to port your apps to us", and ask them to pay $999 (per developer) annually to Xamarin which is the 3rd party. Also using Xamarin tools means rewritting the code. It's not like you have a iOS or Android app and use Xamarin to port it, rather you just have a common ground so people can write codes once and (hopfully) can use them accross platform (except for some UI-specific code, if I'm not mistaken).
And, at $999 a year, is pretty high for a developer tool. IntelliJ offers a buffet of all tools they have at $649 a year (and the price would go down for each subsequence years). The cost of development plus the subscription fee would be enough to drive people away. MS has to come with a better plan, that's why they come up with those projects.
mr_tawan - Friday, February 26, 2016 - link
Corrections, IntelliJ IDEA is a product. I'm refering to "JetBrains", when I mentioned that one.milkod2001 - Friday, February 26, 2016 - link
When i first bought Nokia Lumia 620 i was able to download great Youtube App from MS itself. As i have quickly discovered it was not app at all, it was just image with direct link to youtube website. I guess that app was ruining on Project MS LAMOs. This app might be still there.Project this , project that, bala bla bla if MS wants to get more market share than laughable 5% it should not only give developers options to port their app but also just simply pay best developers to make sure they will port their app. MS has more than enough $$$ to do so.
With 5% market share it is just waste of time and money to bother to do any ports.
amb9800 - Friday, February 26, 2016 - link
MS actually built a really nice YouTube client but was forced to take it down by Google, which opposes users accessing its products from Windows phones (see what they did with Google Maps on WP8). Nonetheless, MyTube and Perfect Tube on Windows Phone are better than Google's first-party YouTube apps on iOS and Android.Alexvrb - Saturday, February 27, 2016 - link
Google refused to release their apps for the new Win runtime. So in the case of youtube MS made one themselves. The original MS-built YouTube app was great. They were later forced to trash it because Google actually BLOCKED the app from accessing content. I was around when this happened and saw it in action. One day, the app works great. The next, mysterious errors prevented you from playing anything. A quick search revealed Google was intentionally blocking the app.Hence the current inferior version was released that just directs you to the youtube mobile site. But as amb said, there's several good third party solutions.
FunBunny2 - Friday, February 26, 2016 - link
what's funny: Google was/is fighting with Sun over Android being java. It isn't on the device, of course. Google takes the java/jvm bytecode and converts it to dalvik/ART code. M$ could have done the same: convert dalvik/ART to whatever.Wolfpup - Friday, February 26, 2016 - link
Huh...yeah, I guess that makes sense if they already have a route from iOS anyway.I just want Marvel Unlimited on both Windows Mobile and regular Windows...
boozed - Friday, February 26, 2016 - link
Microsoft's continuing missteps in the mobile arena really are quite entertaining!marvdmartian - Monday, February 29, 2016 - link
"...the question then became why you wouldn't just go buy an actual Android device"??And that pretty much sums it all up, doesn't it? Frankly, I'm a bit tired of this new MS CEO's attitude, concerning Windows 10, of "Take it or leave it, we don't care". Fine, neither do I, and since I've now taken the time to reassess my computing needs that require Windows operating system, I'm finding out that they are few and far between.
Since MS obviously doesn't give a crap about the little guys, I'm more than happy to make the jump to another OS. If MS is going to act like Apple during the Steve Jobs era, so be it.
BrokenCrayons - Monday, February 29, 2016 - link
Microsoft in years past has exhibited the attitude you mention. I think that's more an indicator of the company's position of market dominance influencing executive management decisions than something specific to the current CEO. However, I also agree that there are viable options outside the Microsoft ecosystem that can fulfill most day-to-day computing needs as long as one is willing to accept a different set of platform limitations.The lack of data collection transparency from Microsoft that seemed to begin during the Windows 8.1 to 10 transition was enough to push me into taking a long, hard look at what I do with a computer and figure out that any of the more popular Linux distros would address every categorical computing need I could identify. Having dabbled in various *nix operating environments since the late 1990s, the transition for me was an easy one. The only thing I gave up were a few games that I didn't care bring over because I don't want to add WINE, but those are the lowest priority items on my list and there's lots of other entertainment available in native binaries.
To get back to the article though, I think what we're seeing is part of Microsoft's surrender of the mobile market to Apple and Android. They're still failing to capture more than the smallest fraction of handset sales so investing in development platforms isn't good for the balance sheets. Unless something dramatic happens in the mobile market over the next year or two, I expect to see Windows 10 Mobile to go to the same graveyard in which earlier PDA-based Windows Mobile is buried.
Agnes Philomena - Thursday, March 3, 2016 - link
Can this stack UDR code from Reject 5.1 without the Sys Admin zombies wailing about backdoor locks?I mean, common. After our lab monks plugged BitJam's proprietary "device" they just laughed at the hysteresis. 15 micros is enough.
XmppTextingBloodsport - Saturday, March 19, 2016 - link
Ignore the elephant-gorilla hybrid in the room: malware masquerading as free.ALL adware is malware.