Vlad Hrybok's Tech Notes

There are two different Windows 8 types: the tablet one, with ARM CPU, and desktop/laptop/server one, with Intel x86/x64/i386 CPUs. Old code base won't run on the ARM tablets, and Metro will not run on Windows 7,Vista and XP. Given that porting applications to Windows 8 is likely to be not trivial, here's the dilemma we, developers, face:

• If we write WinRT/Metro UI applications, we'll be able to run it only on Windows 8, both ARM and Intel, but not on ealier Windows version. We'll also be able to sell it at Microsoft app store.
  
• If we write a traditional Windows application, we will be able to run it on any non-ARM Windows version, including 8, losing ARM/tablet market and the ability to distribute the app via the app store.

So it all comes down to whether developers will believe that getting Metro/Tablet market is going to be worth forsaking Windows 7/Vista/XP desltop/laptop/server market.

Only Intel and AMD can truly save MS back by enabling legacy software on the tablet - if they create low-power yet fast, tablet-worthy x86 CPUs. This would enable programmers like me to write bulk of the logic in the backward-compatible modules and supply dual UI: Metro and traditional Win32. In other words, I'll do Metro programming sooner if Metro port is inexpensive, and if I don't lose backward compatibility with the huge install base of legacy Windows.

Here's all you need to know to build Windows 8 Metro applications.

http://msdn.microsoft.com/en-us/library/windows/apps/

.NET developers have had major source of anxiety lately: Microsoft mentioned only JavaScript as a programming language for Windows 8 Metro UI application development. Now, since the Windows 8 Preview with development tools was released yesterday, I installed it and it's clear it's not only JavaScript, but also C#, VB and C++. Why Microsoft didn't say this at the same time as they mentioned JavaScript is totally beyond my comprehension.

Here's how Visual Studio 2011 New Project dialog screenshot looks like:

Once the project is created, you end up in the very WPF- and Silverlight-like environment, with new project containing XAML & code-behind files. First thing I did was I looked at the project's properties to see whether Windows Runtime (WinRT) is actually an extension to a standard .NET Framework. To my surprise, Target Framework project property is disabled and blank.

For me personally, I was most worried about whether I will be able to port or extend my UltiDev Web Server Pro project (a tiny free redsitributable web server) to support Windows 8 UI. I wanted to make sure that WinRT framework is compatible with existing .NET Framework. It appears it is.

To find out what .NET framework Metro applications are running in, I simply put a breakpoint in my app and inspected Environment class member values. Here's the answer:

It appears that .NET Framework we'll be targeting is still good old 4.0, with tons of WinRT exntensions, all in GAC, to support tiles-based Metro UI.