[rodan01]

Non-blocking UI != Async. My programs do all sorts of background processing using the standard Win32 multithreading model. Win32 has the most sophisticated implementation of multithreading of any OS. Instead of taking advantage of that, MSFT threw it away and implemented the goofy Async model, which intertwines threading and UI code. It's a horrible design. And not only is it a terrible design, it also has horrible performance due to Async and the FileBroker. For example, simply enumerating files is orders-of-magnitude slower in WinRT than in Win32 (Win32 is 180 times faster). You might say, "so what, WinRT is fast enough". Not true, the MSDN forums are full of baffled devs trying to figure out why simply listing all the photos on a device takes so long. Win32 could enumerate them in 15 milliseconds while RT's lovely Async **** takes three seconds. That's a real-world impact ... now add in the requirement to actually touch the data in image file (e.g. get the photo size) and things slow to an absolute, unusable crawl in WinRT.


That's why MSFT should have simply added a native scalable UI API in Win32. MSFT needs to do only what's required, not go off on some idiotic "new paradigm" that screws all the existing Windows developers. They did the same back in my day with OS/2 and after it failed they fell back to Win16 (which is the equivalent to Win32 today) and had enormous success..

I like Task as a construct that abstracts an asynchronous call. It's cleaner than passing callbacks.


The async keyword in c# does an amazing job in simplifying the asynchronous calls, the callback spaghetti is over. So, to me those are good changes.


In winrt every API that takes more than 50ns (if I remember correctly) has to be async. The framework was developed from the ground up for touch devices that can't block the UI thread. In win32 it's optional, the developer decide when they use background tasks.


People generally repeat that developers shouldn't write complex multi-threading code because it's not cost effective. The solution in winrt goes in that direction.



Yep, winrt is here to stay. The last bit of information related to office and winrt, I think it was at build. Supposedly the office team was working with the winrt team to add new APIs to support desktop related features in vnext. Microsoft is standardizing in winrt

[Maitrikkataria]

If you're aware of those bits of information, then maybe It's a lack of the basic ability of dismissing inconsistent ideas. Because what you posted doesn't make sense.

API's are important, you cannot develop everything on your own. For example, if you hadn't had leap motion or MYO's API, you would be doing a monkey dance to develop them, probably charging a ton to your client or else shredding each and every penny of your pockets.

Believe me, if you want to keep an ecosystem health and viable, API's are important!

[Maitrikkataria]

Based on this comment I'm concluding that you aren't a software developer. Although we work on creating software because there is money to be made it isn't the only motivator. Good software requires developers who have a passion for what they're working on. It is that personal investment that drives developers to create software that is of high quality, innovative, and useful.

New APIs means being able to do more things... or do existing things in a more efficient manner. It's exciting to see if a current product can be enhanced and expanded. The availability of these new APIs flips the switch on thinking about new opportunities. I've stopped developing for any of Microsoft's mobile platforms because they talk a good game, but fall far short in their delivery. In the memorable words of Sweet Brown, "Ain't nobody got time for dat!"

Of course there are software mills that churn out basic, no-frills, uninspired apps. Those are the ones that aren't interested in new APIs. But those apps aren't the ones that grab customers' attention.

Yes, I agree with you. There are hardwares that needs API to integrate with Apps, I don't know how he intends to keep the economic app development while developing the entire API alongwith the application.

[Maitrikkataria]

Samsung makes a boatload of money with their Android devices and if they focus on another platform it's Tizen not Windows Phone.

True, I agreed with what you have said. To support you with statistics, please find the coverage of "Microsoft Now Builds Nearly 95% Of All Windows Phones" by the Verge. People are not trying to rationalize their thoughts on how much the WP's are actually made by Microsoft. I hope this drives the conversation in positive way.

[Mike Gibson]

I like Task as a construct that abstracts an asynchronous call. It's cleaner than passing callbacks. The async keyword in c# does an amazing job in simplifying the asynchronous calls, the callback spaghetti is over. So, to me those are good changes.

Multithreading in Win32 eliminated the callback problem 20+ years ago.

In winrt every API that takes more than 50ns (if I remember correctly) has to be async. The framework was developed from the ground up for touch devices that can't block the UI thread. In win32 it's optional, the developer decide when they use background tasks.

It's 50 ms (milliseconds). MSFT's own RT apps violate that rule, e.g. Solitaire routinely sputters when dragging and animating cards. So, what did the vaunted Async in WinRT buy us there?

People generally repeat that developers shouldn't write complex multi-threading code because it's not cost effective. The solution in winrt goes in that direction.

What do you think Async is? It's a method of multithreading that uses callbacks from the Async/Thread Pool manager. Async solves NONE of the problems intrinsic to multithreading in programs, e.g. protection of variables from simultaneous access, preventing users from starting the same operation again, aborting operations, etc. You can see devs running into these problems over and over again in WinRT on the MSDN forums.

Async solves none of the important problems, completely screws up simple things like file operations, nukes the use of widely available open source libraries, and has abysmal performance. What a huge mistake.

[rodan01]

Multithreading in Win32 eliminated the callback problem 20+ years ago.


It's 50 ms (milliseconds). MSFT's own RT apps violate that rule, e.g. Solitaire routinely sputters when dragging and animating cards. So, what did the vaunted Async in WinRT buy us there?


What do you think Async is? It's a method of multithreading that uses callbacks from the Async/Thread Pool manager. Async solves NONE of the problems intrinsic to multithreading in programs, e.g. protection of variables from simultaneous access, preventing users from starting the same operation again, aborting operations, etc. You can see devs running into these problems over and over again in WinRT on the MSDN forums.

Async solves none of the important problems, completely screws up simple things like file operations, nukes the use of widely available open source libraries, and has abysmal performance. What a huge mistake.

[wuiyang]

all i want is that windows phone SDK can have access to call log, that's all, and SMS too
and microsoft should have a pop up when an app is trying to get data from your phone