Anyone else see Microsoft losing momentum?

[crystal_planet]

money is obviously not the problem with MS. The problem is how people see Microsoft. They don't think about Microsoft the innovator, but more about Microsoft the undead behemoth(they want it dead).

So, what do you want then? Microsoft to have a weekly presser to announce some cool new technology it's working on? The last half of 2013 saw some pretty great news for MSFT, but now that we are in a bit of a lull the wheels have fallen off? Give me a break. Do you think Google/Android folks are gnashing their teeth because the buzz has worn off Google Glass?

The reality is MSFT is a demonized company. It got that rep in the early 90's and it stuck even today. That means MSFT has to fight harder for mindshare - and will continue to do so for a long time to come.

The people that scream about how unethical Microsoft is (because of the IE debacle in the 90's) are current users of Android - you know the ones that will use your personal info for advertising. Or Apple fans - the ones that beat their chest about innovation, and now that Apple is no longer innovative, beat their chests about how it "just works".

 

[Simon Tupper]

So, what do you want then? Microsoft to have a weekly presser to announce some cool new technology it's working on? The last half of 2013 saw some pretty great news for MSFT, but now that we are in a bit of a lull the wheels have fallen off? Give me a break. Do you think Google/Android folks are gnashing their teeth because the buzz has worn off Google Glass?

The reality is MSFT is a demonized company. It got that rep in the early 90's and it stuck even today. That means MSFT has to fight harder for mindshare - and will continue to do so for a long time to come.

The people that scream about how unethical Microsoft is (because of the IE debacle in the 90's) are current users of Android - you know the ones that will use your personal info for advertising. Or Apple fans - the ones that beat their chest about innovation, and now that Apple is no longer innovative, beat their chests about how it "just works".

I saw an article about the Antitrust ruling against MS. It said that Microsoft might have never had an antitrust ruling against them in today's market, because it is much more competitive than it use to be. Which I think shows that Microsoft only made a minor mistake in the 90's that was demonized too.

So basically Microsoft was "shut down", because it was too strong. No one was able to keep up with them. much like Android, but it's different nowadays.

 

[bilzkh]

Those are tweaks on existing releases and I'm not talking about D3D12 right now. According to AMD/ATI, MSFT has no plans for a Direct3D12. No plans -- meaning it is a dead end. As for future GPU innovation, I'd like to see Output Merger stage shaders. Most important are the things I can't even think of right now.


A Win32 program can certainly start up in its previous state. My Win32 apps start up in nearly the same state that they were in when closed. And look at WM_QUERYENDSESSION for information on how to know when your Win32 app is force-closed. Adding a few more messages would have been far easier than reinventing the wheel over and over again.


Yes, they should have produced a stripped down version of Win32. I would have completely supported a new Win32 subset that cut out old, obsolete stuff (especially insecure APIs and access) while adding a simple, scalable UI API. I also like the Store managing updates, etc. (though not the 30% cut, that should be no more than 10%). Take the good stuff from WinRT (scalable XAML, store, etc), repackage it for Win32, then backport the damn thing to Win7 and they'd have a winner. I would have converted my Win32 programs over to this new Win32X platform instantly.

What I do *not* like is MSFT wasting their time reinventing file access, forcing ISVs to use the stupid Async pattern, etc. Basically nuking all existing Win32 code. The market has proven this to be the wrong course. Windows is dying right now. The MJF article on ZDNet says that MSFT has abandoned their plan to bring WinRT and WinPRT closer together in the upcoming Win81 update. Why? Because Win8's OEM sales dropped 20% in the latest quarter. That's a forward-looking number which means that OEMs expect sales to get even worse than they were in 2013. MSFT is panicking and tossing everything aside to try and fix the Win8 disaster. And note that this Win8 disaster is *not* independent of the WinRT development disaster. It's reflected in the lack of large selection of WinRT programs. Why would an ISV duplicate all their Win32 effort for a entirely new, critically limited, and poorly performing WinRT system? Do I even need to mention the orders-of-magnitude slower file access in WinRT?


I'm talking about the future of Direct3D, not the present. See my comment above about MSFT not developing future versions of D3D.


An OS is written C++ and I'm a C++ programmer. I don't care what framework goop other languages use to communicate with the OS. I want a clean, simple OS that I can access from C++. You do know that WinRT is written in C++, correct?


Very few Win32 APIs are available to WinRT programs. And even then they're inconsistent between WinRT and WinPRT. For example, WinRT only has the Windows.Socket APIs while a WinPRT program can use WinSock. The HTTP situation between the WinRT/WinPRT is even worse. I couldn't use XMLHttpRequest2 because of the differences in behavior between WinRT and WinPRT (e.g. both fail range-byte GET requests differently because they set the gzip flag on requests, both cache things differently, etc.). What's stupid is that XHR2 calls WinInet to do the actual work but my C++ programs can't access WinInet. To fix this, in Win81 MSFT wasted more time implementing an entirely new HttpClient API. Guess what, it turns around and calls Win32's WinInet. Why didn't they simply give C++ programs access to WinInet in the first place???


See my comments above about C++ and OS access. I don't care how many layers of goop MSFT wants to place between the OS and other languages/scripts.

100% agreed. It's no surprise that Windows Phone has more developer and market attention behind it than Windows. Between the two OS it's clear that Windows Phone is more in-tune with the market realities (albeit still flawed/off in a few ways). It would've been smart to do what you suggested, i.e. new Win32 APIs allowing for legacy applications to become tablet-friendly apps (i.e. new UI, scalable XAML, but legacy power). Do you think Microsoft has the time and resources to make Windows Phone OS apps run well on Windows *and* do justice to Win32? Since the Windows Phone team is in charge and intent on bringing back the Start Menu, things look promising, no?

 

[Mike Gibson]

100% agreed. It's no surprise that Windows Phone has more developer and market attention behind it than Windows. Between the two OS it's clear that Windows Phone is more in-tune with the market realities (albeit still flawed/off in a few ways). It would've been smart to do what you suggested, i.e. new Win32 APIs allowing for legacy applications to become tablet-friendly apps (i.e. new UI, scalable XAML, but legacy power). Do you think Microsoft has the time and resources to make Windows Phone OS apps run well on Windows *and* do justice to Win32? Since the Windows Phone team is in charge and intent on bringing back the Start Menu, things look promising, no?

There should be no fundamental difference between a phone, tablet, laptop, xbox, or desktop program so I don't think growing WinPRT is the solution, especially since it isn't backwards compatible with Win7 (which I believe is critical to get broad ISV support). The entire RT concept needs to be replaced with "Win32X". The app should adapt to the screen size and available input devices.

MSFT definitely has the resources to do it. Creating a scalable extension API for Win32 would only take 10-20 crack devs, if they kept their noses to the grindstone and didn't try to impress their programmer friends with a bunch of all-the-rage crap like Async.

Unfortunately, MSFT folks think that the problem with RT is a lack of "education" of ISVs and end users.

 

[Cleavitt76]

Those are tweaks on existing releases and I'm not talking about D3D12 right now. According to AMD/ATI, MSFT has no plans for a Direct3D12. No plans -- meaning it is a dead end. As for future GPU innovation, I'd like to see Output Merger stage shaders. Most important are the things I can't even think of right now.

I did a web search for this topic and found absolutely nothing. If you happen to have a link I would be interested in reading about it. To be honest, it sounds rather hard to believe that MS would abandon Direct3D since there is currently nothing in place to replace it and so much of their own software depends on it. My guess is that AMD/ATI said something that was taken out of context by the Interwebs which happens all the time. In any event, I wouldn't get all worked up about it until MS makes an announcement.

A Win32 program can certainly start up in its previous state. My Win32 apps start up in nearly the same state that they were in when closed. And look at WM_QUERYENDSESSION for information on how to know when your Win32 app is force-closed. Adding a few more messages would have been far easier than reinventing the wheel over and over again.

Yes, I know that, but the developer basically has to go out of their way to do that and roll their own methods. It was really just an example of one of the many things that MS has to consider as they develop the runtimes for these new low power touch optimized apps.

...
An OS is written C++ and I'm a C++ programmer. I don't care what framework goop other languages use to communicate with the OS. I want a clean, simple OS that I can access from C++. You do know that WinRT is written in C++, correct?
...

We both know it makes zero difference what language WinRT is written in except to the developers at MS that write those libraries. WinRT could be written in Notepad as a string of 1s and 0s and it wouldn't matter to you an I one bit. The whole point of APIs is to hide the implementation so that developers can just use the functionality with minimal fuss.

Anyway, you and I are just talking in circles and splitting hairs are this point. You have some valid points and I can certainly relate to the frustration of loosing backwards compatibility with a lot of your existing code. I just disagree that this is going to be the "downfall of MS" which is how your original post read.

My only point is that MS is trying to create a new type of app that can be run on all types of hardware ranging from extremely powerful x86 to extremely weak ARM class hardware. Neither you nor I know exactly where this is going. Xbox is a safe bet, but smart watches, glasses, toasters, etc. are all possibilities. I feel that MS provides the best development tools and frameworks by far and I give them the benefit of the doubt on their decisions with WinRT. I assume they looked at their goals and determined the best approach was to build a framework (WinRT) that sits on top of native OS APIs like Win32 rather than try to modify the OS APIs directly. You clearly disagree and that's fine too. I respect your opinion, I just don't share it.

 

[Mike Gibson]

I did a web search for this topic and found absolutely nothing. If you happen to have a link I would be interested in reading about it. To be honest, it sounds rather hard to believe that MS would abandon Direct3D since there is currently nothing in place to replace it and so much of their own software depends on it. My guess is that AMD/ATI said something that was taken out of context by the Interwebs which happens all the time. In any event, I wouldn't get all worked up about it until MS makes an announcement.

Here's one link describing what happened and the follow up denial by MSFT:

AMD - No DirectX 12

You can google the AMD guy's name and DirectX12 to see more reporting on the issue. It was a real WTF moment when that story came out.

They're playing with fire up in Redmond these days and they're going to get burned.

 

[Cleavitt76]

Here's one link describing what happened and the follow up denial by MSFT:

AMD - No DirectX 12

You can google the AMD guy's name and DirectX12 to see more reporting on the issue. It was a real WTF moment when that story came out.

They're playing with fire up in Redmond these days and they're going to get burned.

Well again, it sounds like we will have to agree to disagree. I read the article, along with a few others, and it appears to be pretty much what I suspected earlier. Some non-technical VP at AMD makes a casual unofficial comment in an interview...

"... But there will be no DirectX 12. That's it. To our knowledge there are no plans for DirectX 12 If someone wants to correct me - wonderful. ..."​

The interwebs briefly went nuts until MS said in an official statement...

"... That is definitely not true in any way, shape or form. Microsoft is actively investing in DirectX as the unified graphics foundation for our key platforms, including Xbox 360, Windows Phone and Windows. DirectX is evolving and will continue to evolve. For instance, right now we’re investing in some very cool graphics code authorizing [sic] technology in Visual Studio. We have absolutely no intention of stopping innovation with DirectX"​

The bolded parts are pretty hard to misinterpret. Microsoft is basically saying (in a politically correct way) that the AMD VP is full of crap. Since then, DirectX has been updated to 11.2. It seems to me that AMD's uninformed VP of Global Channel Sales is the one playing with fire and MS got burned in the process. Which actually happens quite often. I really don't understand why you are blaming MS for this.

Since we are sharing links, here are a couple links to MSDN posts explaining why MS chose to make all file system APIs asynchronous in WinRT.

Opening Files from SkyDrive using .NET - .NET Blog - Site Home - MSDN Blogs
WinRT and .NET in Windows 8 | All Your Base Are Belong To Us

They didn't do it just to upset developers. In a nutshell they did it because WinRT apps are likely to be running on devices that primarily use cloud storage (i.e. SkyDrive) and might be accessing that storage through a slow cellular connection. If they had used synchronous IO, users would be dealing with a lot of apps that would appear unresponsive. For that reason, they felt that the WinRT framework should always use asynchronous IO to ensure what they consider to be best practices for that type of app. I can totally understand how it is annoying as a developer to have to rethink/recode something as common and simple as file system access, but I can also understand why MS decided to do that when considering the intended purpose of the WinRT framework.

 

[Mike Gibson]

The bolded parts are pretty hard to misinterpret. Microsoft is basically saying (in a politically correct way) that the AMD VP is full of crap. Since then, DirectX has been updated to 11.2. It seems to me that AMD's uninformed VP of Global Channel Sales is the one playing with fire and MS got burned in the process. Which actually happens quite often. I really don't understand why you are blaming MS for this.

AMD folks would know if there was going to be a D3D12 (because they would be the ones designing the GPU support, which has a long lead time) and they said it is not in the cards. I haven't heard a peep out of MSFT regarding future GPU technology.

Since we are sharing links, here are a couple links to MSDN posts explaining why MS chose to make all file system APIs asynchronous in WinRT.

Opening Files from SkyDrive using .NET - .NET Blog - Site Home - MSDN Blogs
WinRT and .NET in Windows 8 | All Your Base Are Belong To Us

They didn't do it just to upset developers. In a nutshell they did it because WinRT apps are likely to be running on devices that primarily use cloud storage (i.e. SkyDrive) and might be accessing that storage through a slow cellular connection. If they had used synchronous IO, users would be dealing with a lot of apps that would appear unresponsive. For that reason, they felt that the WinRT framework should always use asynchronous IO to ensure what they consider to be best practices for that type of app. I can totally understand how it is annoying as a developer to have to rethink/recode something as common and simple as file system access, but I can also understand why MS decided to do that when considering the intended purpose of the WinRT framework.

Those links don't justify the Async pattern. Accessing a SkyDrive "placefile" is no different from accessing a file on a network, all of which is handled just fine in a Win32 thread calling blocking Win32 file APIs. My Win32 programs read hundreds of files per day, with some being 10-20 MB in size, from real time internet data sources using background threads. When people use my apps to load archived data already on their PCs (loading and parsing those 10-20 MB files takes a few seconds per file), I fire up a file loader thread and it posts messages to a covering dialog box for progress updates. I'll note that the real time data downloader doesn't affect my programs' UI thread, which maintains a smooth 60 FPS display rate in D3D, because it uses Windows excellent multithreading support, the best of any OS out there. MSFT is throwing that battle tested, superior technology in the trash.

When using a Win32 thread your code is nice and sequential. You know where you are at all times. In Async you don't know where your code is executing at any moment and have to use all sorts of goofy syntax and boxing to keep variables alive for the lambda callback. Look at all the problems ISVs have with that issue. Looping on an Async callback, like you have to do in C++ to read an unknown length file, results in a vomit-inducing pseudo-recursive coding pattern. It's just stupid. There's a reason why all the C++ StreamSocket examples include a "length" field in front of the data -- it's so they don't have to include the grotesque pseudo-recursion in the example.

Couple of other notes:

1. Apparently this wonderful Async-is-required functionality is available for Desktop apps that use the Common File Dialogs (like mine):

Placeholder files (Windows)

How in the world did MSFT manage to do that in the ancient Win32 API???

2. And the wonderful Async pattern, as you might expect, requires special work to maintain performance (so much for "go Async and all your troubles disappear"):

Asynchronous Programming - Async Performance: Understanding the Costs of Async and Await

I found this to be the case when doing a simple test that added up the sizes of 2000 files in app local storage. Using the ancient Win32 FindFirst/FindNext APIs, my WinRT test app could perform the task in a single NT timer tick (15 ms). Using the wonderful WinRT Async directory functions, that same task took 3.75 seconds (250X longer). Screwing up performance that bad requires effort (!), so I decided to dig deeper. I isolated the Async part from the dreadful FileBroker in WinRT by using Win32 to enum the files and the Async pattern to step through them. That reduced the overall task time to around 150 ms. So, in this simple operation, using the Async pattern only cost me one order of magnitude perf hit! If I designed and implemented a system like that, I would expect to be fired ... and the people who approved the RT mess have already been canned (Ballmer and Sinofsky). That's a good start.

 

[ny_yankees]

I love Microsoft and I love Windows Phone but lack of apps like Yahoo messenger, Snapchat and such like that are really taking a toll on me. Considering that many third party electronics all have Android/IOS apps but they do not have one for Windows Phone

I was looking to buying a toy helicopter for my little cousin and great part about it was that it can be operated by your phone. Then only to find out it only supports Android/IOS. Things like these are whats really annoying when owning a windows phone.