I will make sure to bookmark it and come back to
learn more of your useful info. Thanks for the post. I will definitely comeback.

[...]Windows 8: BFD — Big Forking Decision | Monday Note[...]…

I can see if MS wants to deprecate Windows Forms for WPF, but “mouse and keyboard” UIs are here to stay, so I suspect developers will make dual UIs – WPF/WinForms for “mouse and keyboard” UIs, and metro UIs for touchscreens.

Also, HTML is not a programming language. It is a markup language. I think it is commonly understood that writing an app involves some programming language (C#, VB.NET, C++, etc.) and a UI markup language (or prebuitl objects in the case of WinForms). UI markup was WinForms, and then became XAML with WPF. So now we replace the *markup language* XAML with the *markup language* HTML5/JavaScript when writing Metro-UI apps.

As of now, Windows Phone 7 requires Silverlight (a XAML subset) for the markup language. That shifts to HTML5/JavaScript in Windows 8 for smartphones and other touchscreen devices that will use metro. The bulk of computers will remain “mouse and keyboard”, so programs written for them will continue to use WPF/WinForms.

WinRT is a smoother blending of the Win32/Win64 API and the .NET framework.

At least, that is how it appears to me at this early stage of dealing with Windows 8.

A) existing .NET apps will be relegated to the “desktop” ghetto

B) Metro apps are NOT required to be written in HTML. Metro apps may be written in C, .NET or HTML and all will finally use the same library: Win RT.

I’m sure that they’ll make some kind of cross-compiler thing for VS 2010+ or so. You’ll just need conditional defines to differentiate between platforms for ARM and/or x86 & x64. Still, if you define the libraries correctly, you can do that in an external DLL to code accordingly with the same main code.

When Windows 95 came out, a number of DOS programs, mostly games, did not run in the DOS window. Those apps had taken shortcuts and circumvented development standards MS had published. When VB.NET came out, some VB6 developers complained. They were still doing procedural programmign in VB6, instead of object-oriented (OO) VB6 programming, and ignoring the standards MS put in place for OO VB6 programming, their VB6 code would not port to VB.NET.

In those cases, MS was made the “boogeyman” for developers’ own shortcomings and arrogance. Some of that will be true as the shift to Windows 8 takes place. Well-written .NET apps will run on Windows 8, but again, developer shortcomings and arrogance will lead them to blame MS for their own doing.

However, if MS pushes the Metro UI on the desktop as the default, then they will justify valid complaints about the uselessness of that UI design on desktops/laptops/netbooks, which will lead to acceptance of the invalid ciriticisms.

If MS waits until months from now to deliver a definitive statement on whether legacy VB6 code will run on x86 Windows 8, and if so, what is required to do so, they will give developers who have been too lazy to rewrite procedural VB6 code to OO VB.NET a legitimate reason to criticize MS.

Only time will tell if the shift away from the short-lived WPF and Silverlight to HTML5/JavaScript was a wise one. Very few Windows developers know JavaScript. Unless the VS11 tools are really good, this could be a serious mistake on MS’s part. I suspect good software engineers will utilize the same business and data tier code, but split the UI into WPF for desktops/laptops/netbooks, and Metro for devices.

If MS really wants to dominate software development, they should 1) enable, if not appropriate, Mono so it is up to the current .NET framework version, and 2) make sure the .NET framework (VB.NET and C#) runs on Linux, OSX, iOS and Android.

Come on MS, step up, take charge, and lead! You used to do that, and it is time to do it again. In case MS management hasn’t heard, there is a deep recession going on. Price accordingly if you want both sales and admiration.

Also, you write “For the first time in Microsoft’s history, the users of Windows-powered hardware will have to ask: ‘Will this application work on that device?’ You can run Office 2010 if there’s Intel inside, but not on its ARM sibling.”

That’s not really true. In the late 90s Microsoft delivered Windows NT on various platforms (including x86, PowerPC, MIPS). Windows users (primarily enterprise, the only ones to use NT) had to choose, and the choice was rough and problematic. After dropping the promise multiple platform support of NT in Windows 2000, Microsoft then began supporting Intel’s Itanium IA-64 in addition to x86. That too was a mess. And when it switched its 64-bit platform focus to AMD’s x64, it again left a mess for users to determine if they had 64-bit apps, plugins and the 64-bit version of Windows, which initially couldn’t even run 32-bit apps.

Apple originally decided not to move to Intel in the 80s because, although it could port the Mac OS, it would have abandoned developers on 68k, forcing them to rewrite their apps. When it did port to PowerPC, it made great pains to support backward compatibility for users and developers. It did the same thing when it moved to Intel, and again in moving to x64 Intel chips.

In the move to tablets, Apple had already developed an ARM port of OS X, highly customized for portable uses in iOS. It made no suggestion that Intel apps might run or might work well recompiled for ARM and slogged on a mobile device. Microsoft has announced a very sloppy, unplanned trip to ARM. Most customers think it will “somehow” get existing Windows apps working on iPad-like hardware. They are wrong, as you indicate.

But the parallel suggestion, that Microsoft will also release Office for Metro and that it will be good, is also a farce. This is the company that couldn’t’ release a decent version of Office for Mac across the last decade, despite an installed base of 30-50 million Mac users. It announced it would port a few Office connectivity apps (not the full suite at all) to Symbian and just now got that out, two years later.

The Office unit within Microsoft has aways spurned the own company’s Tablet PC plans, and that was running Intel and the full Windows. Now they’re going to copy Apple’s iOS iWork apps three years late within 12 months of “not saying” they they “might have a plan in place” about bringing Office apps to an OS that isn’t going to be done for at least another year?

Best case for Windows Enthusiasts is to expect to run “Office 360″ web apps on the Windows 8 tablet, but you could already do that from an iPad. So where’s the value proposition? Apple now has iWork with iCloud support, at least a year ahead of Microsoft selling its first Windows 8 license.

Your Microsoft iPad will still have a mobile interface and mobile-optimized native apps installed only from a single, secure installer. It will still have open standard W3C HTML5 apps installed from anywhere. It will still have ISO MPEG4 audio video. It will still hide the file system from the user unless they want to install an app that provides that for them. All the stuff that Paul Thurrott has been complaining makes iPad suck.

The major difference is that Microsoft is going to have one Metro platform for apps, while Apple has the equivalent iOS but is also maintaining an additional power user platform on the Mac. This makes sense, though, if you look at PC pricing. Microsoft has $500 customers, while Apple has both $500 customers and an additional group of $1000 customers for the pro app platform.

> FYI, the next version of Office (Office 15) has already
> been demoed running on an ARM platform. It was the
> regular version of Office too, not a Metro app.

That is where the confusion started. That demo is being understood now as an epic blunder. They are not going to ship that. They never planned to ship that.

They have since explained that the purpose of that demo was to show that it was “the real Windows” they were porting to ARM, not “Windows Embedded” or some other thing that they have also named Windows. It was not actually running on a tablet, but rather on a disembodied mock-up that had many gigabytes more memory and storage than a tablet, and did not have to get 10 hours of battery life like a tablet. They may even have been running the ARM SoC at a much higher speed because they could put cooling on there if they liked, it was not built into a mobile device. The hardware they were running on would have cost much more than an iPad. You have to put in an extra 8 gigabytes of storage just to give the user the same free storage as iPad, because Windows 8 is 8 gigabytes bigger than iOS. You have to put in 4 times or 8 times the RAM as an iPad just to give the user the ability to launch an app. A small RAM allotment is a big part of why iPad is so cheap. You have to deal with the fact that Windows apps are made for a single 1-pixel thick mouse pointer, not 10 fat fingers that mash 60 square pixels at a time, and the way you deal with that is to build a user interface framework like iOS or Metro and get developers to port their apps to it.

So they are not planning to ship that a legacy Windows experience on ARM. That is just another kind of unicorn tablet.