[ShabbyDoo]

It seems like the risk of not collecting $500 from a bunch of developers is peanuts compared to the real threat MSFT now faces of people choosing to develop non Windows-specific apps which happen to still work on Windows. How many "apps" have you installed lately which are really just local servers with web front-ends? Qt-based stuff? Java SWT/Swing? What else? While many of these apps likely are built upon 3rd party components developed using Visual Studio (perhaps a free version), the makers of these apps almost always provide a Mac and Linux version. Microsoft has passed a dangerous tipping point where it is now like Apple in the early 90's -- fighting to attract developers who will provide killer, platform-specific apps. We all laughed as Ballmer screamed, "Developers, developers, developers!" However, he's all too well aware of the danger Microsoft faces of losing its dominance as a platform provider. I'd say "lost" as I believe they're already running on fumes, but they still control a huge portion of the desktop market. They should be worrying that developers won't develop anything at all which relies on their APIs and forgo the overly ambitious goal of buying developers' use of Metro. In a storm, any 'ol port will do.

[simonh]

True they still control a huge proportion of the desktop market, but most of that is business desktops. Apple's market share is heavily lopsided towards the high end consumer market. It's similar to their position with the iPhone. They have a minority market share, but its the most valuable part of the market.

For over a decade Microsoft has essentially been able to behave as if they have no competition, while Apple still has a culture of being lean, mean and hungry - plus they now have a hundred billion dollar war chest. I'm glad I'm not working for a competitor of theirs right now. At least

Microsoft does seem to be well aware of the problem, but the question is are they too big and slow to be able to react effectively? In mobile the answer was no. On the desktop they have the advantage of a real and significant market share dominance. It's going to be very interesting to see where things stand in 3 or 4 years time.

[bztzt]

That's exactly what the motivation for the "Metro/WinRT" strategy for Windows 8 was in the first place, though - to get more developers writing directly for (new versions of) Windows rather than relying on third-party (or even first-party) runtime layers.

[malkia]

WinRT feels foreign on many fronts.

I'm evaluating Win8 for us, and I compiled few of the examples that MS provided. My absolute first impression was that it's hard to debug these applications:

While there was a time, where few or more files were auto-generated, now there are dozens more. On top of that not one project, but two - one container (dll, your app), the other one - the runner (some small exe).

And then press F11 (debug), and see what happens - you are debugging full screen app (metro), and your debugger is running on the desktop. I don't have two monitors, so it might be better there - but what about people with laptops, or other mobile forms that ARE supposed to be the Windows 8 primary devices?

It seems like Windows 8 is collection of ideas, not very well stringed together. I like the "hooking" of one app to another, but it seems too limited - I was much more expecting docking of apps, even if it had some hard limits, but not only 2 apps side-to-side.

Things might improve, but I doubt many people would do professional software that is entirely for Metro. Once you do that, you are taking away from people the ability to run other apps at the same time on top of them.

For example, I regularly run DeskPins, and then I can pin on a window to stay on top - for example notepad, or something else. Now this is not possible.

The File Open/Search aspect is also strange. One thing that I loved of the Open File Dialog in normal Windows is that I can actually put a real URL from http, and it would download the file somehow, and later I can reopen it. Now this is gone.

The whole direction makes sense for mobile devices, but not for professional tools, unless the tools are modified that much that it won't hurt.

In our game studio, it's typical to see Maya/Motion Builder working together with two or three other tools opened, and often they cooperate - one tool displays data, the other edits it - now how... and why would I want to change this into the Metro way?

[bztzt]

Oh, I wouldn't consider Metro style apps as any kind of replacement for desktop apps or most professional tools. I've been running Windows 8 for a while now, but to me on desktops or larger screened laptops they are just fancy gadgets that live off the left side of my screen. I like having them because they are isolated and suspended when not running, so I can use lots of them without impacting the system (or even cluttering the taskbar). I just grab one from the switcher or the start screen, check something or do something simple, and then click in the upper left corner to go back to the desktop. It's a bit like I might have a phone next to me while using a PC and check mail on it sometimes, but there are some advantages such as being able to use your keyboard to enter text, being able to click on a link and have it open in the desktop, etc. However for integrating into any more involved workflow I would stick to desktop apps for the reasons you mentioned. (I also agree that the Metro open file dialog is really lame, it somehow manages to be even worse than the Windows folder browser dialog and I didn't think such a thing was even possible).

There is a lot of weird FUD about the desktop being "legacy" and on its way out, and although that's not something Microsoft has actually said it does come partly from them being overeager to hype their new thing because it's their new thing, and partly from the press echo chamber liking to hype things in general. But it's completely absurd.

re debugging, I think there is an "emulator" you can use which is really a remoting session into your own machine, but it will run your app in a window.