The document analyzes a developer's initial impressions of Windows 8 and its new metro-style apps built on the Windows Runtime (WinRT) API, highlighting both its potential and limitations. It emphasizes the significant changes in app development, the challenges for legacy applications, and the enhanced focus on web apps over traditional desktop applications. The author expresses concern about the user experience of legacy apps, suggesting that unless improvements are made, Windows 8 may disappoint developers and users alike.

1. A Developer's First Impressions on Windows 8
Developer: Justin James
Microsoft unveiled a developer preview of Windows 8 at its BUILD event last week. A lot of
writers are slicing and dicing Windows 8 in terms of the UI, handling, features, and so on; I’ll add
to the conversation that the legacy and Metro-style apps on the same system feel like the Win 3.1
days when you were constantly bouncing between the GUI and 80×24 mode to get things done,
and I really hope Microsoft improves the experiences before launch. I’m focusing on looking at
Windows 8 from the developer’s perspective. (I used VirtualBox for the preview; if you want to do
the same, follow these directions.) Here are my initial thoughts and findings about Windows 8.
Metro-style apps and WinRT
The really big change is that Windows 8 supports a new app paradigm called Metro-style apps,
which are built on a new API called Windows Run Time (WinRT). Metro-style apps look and feel
like Windows Phone 7 (WP7) apps and can be built in XAML + C#/VB.NET/C++ or HTML +
JavaScript.
WinRT seems to be a new provider of system or OS services to applications. .NET was not a clean
break from the past, as it merely wrapped existing system calls up into a comprehensive package.
While the details are not known, it looks to me like WinRT may be a full-fledged replacement of
the Win32 API. That said, WinRT is accessible from other languages, and it seems that non-Metro-
style apps (.NET and C apps) can use WinRT as well.
WinRT supports a host of interesting features, including:
 Single Sign On
 Windows Push Notification Service (WP7 already has this feature.)
 Can act as a contact source to the OS (i.e., it can provide details to the address book)
Like WP7 and Silverlight apps, Metro-style apps will run in a heavily sandboxed environment.
While this is great for the end user, you can expect that your apps’ functionality will have a
number of strict limitations on what they can do to the system. Applications that need deep OS
functionality will probably still need to be written in .NET or native code.
To support this new paradigm, Microsoft has a new version of Expression Blend in the works,
with heavy emphasis on HTML and JavaScript development. Microsoft is making it clear that this
is not going to be used for static HTML sites, which leads me to believe that Expression Web
(which I like a lot) will still be around. The HTML + JavaScript apps will run within IE 10, in a
full screen, no “chrome” mode, so they look and feel just like the other Metro-style apps (which,
like WP7 apps, fill the screen completely and have no OS UI elements visible when using them).
In this IE session, no plugins will be enabled, so you won’t be able to embed Silverlight, Flash,
etc. in your apps. If you want that, you would probably be better off writing in XAML and

2. embedding the HTML and JavaScript in it, although it is unclear if they would be able to access
WinRT. Important note: Metro/WinRT apps will not be backwards compatible to previous versions
of Windows. Also of note is that Metro/WinRT applications will not be cross-platform compatible,
even though the development technologies are.
Reading through the WinRT documentation is illuminating. For example, it is clear that WinRT
will not be allowing you to access data outside a “shared” location or an application-specific area.
There is also a very heavy emphasis on asynchronous operations, just like in WP7. While Metro-
style apps can still access some parts of the Win32 API, COM, and .NET Framework, the access is
limited. You cannot work around the WinRT file access limitations by using the classes in
System.IO (like the File object) — they are totally gone. It is clear that the access to the .NET
Framework, Win32 API, and COM is to “fill in the blanks” of what WinRT does not provide, or to
have alternative methods, not to allow you deep access.
Visual Studio 11, .NET 4.5
Visual Studio 11 (VS11) looks almost identical to Visual Studio 2010, but there are a ton of UI
enhancements and new features. None of the features are quite as “blow me away” neat as, say,
IntelliTrace in VS2010, but they all add up to a nice upgrade. The developer preview ships with a
stripped down, Express edition, but you can get the full version from Microsoft (it also runs on
earlier versions of Windows). It is not a Metro-style app, and I can understand why. F# is still on
equal footing with C# and VB.NET. The changes to VB.NET and C# are underwhelming, aside
from the support for Async. ASP.NET 4.5 supports HTML5’s WebSockets and asynchronously
flushing request and response streams, as well as some less interesting features. IISExpress is the
new development Web server, and LocalDB gets a lot of support.
Miscellaneous
A new version of Team Foundation Server is coming as well, but details are sparse at the time of
this writing. F# 3.0 is included, with a number of new features; notably, it seems to have gotten
more beneficial upgrades than C# or VB.NET in terms of quantity (although Async/Await is pretty
nice), but that’s in large part because F# is still quite new and has a ways to go.
There will be a Windows app store, which will function like a smartphone app store. The app store
will also support in-app purchases, which is another bonus. There is integration directly in VS11
to hook into the app store, including a very cool feature that lets you reserve an application name.
Also, Microsoft will be providing its application review tools, so you should know before
submission if your app will pass or not.
Another interesting cloud-based idea is that Metro-style apps can sync information easily to
Windows Live for use on other devices. The Windows 8 + WP7/WP8 combo could be absolutely
killer for on-the-go professionals and for enterprise apps. Even if the WP7/WP8 OS remains
separate from Windows 8 and apps need to be rewritten for each platform (although my guess is
they won’t need to be), being able to immediately see work or settings from an app on one PC

3. happen on all devices is awesome. WP7 already can do this with Word, Excel, PowerPoint,
SharePoint, and OneNote, although the configuration is rather annoying.
Recommend Office .NET/Silverlight Component:
Spire.XLS for .NET and Silverlight
Spire.Office for .NET and Silverlight
Spire.Doc for .NET and Silverlight
Spire.PDF for .NET
Spire.DataExport for .NET
Read Justin James’ Take on Windows 8
I think that the new Metro-style apps look fantastic. I haven’t gone into the details about WinRT at
a technical level yet, because there are few details available.
When looking at the number of code examples, it stood out that: Microsoft is really pushing
JavaScript (147), C# did well (74), C++ had a surprising number too (72), but VB.NET had only
one example. While I wouldn’t call that proof of anything, it is not a good sign to VB.NET
developers that Microsoft is in no rush to put sample code out there for them.
A number of people have asked, “what about phone and Xbox?” It’s a good question, and right
now, there are no answers. Microsoft isn’t saying if WP7 (or WP8) is going to merge with
Windows 8, or if it will remain separate.
WinForms, Silverlight, and WPF are still supported by VS11. I am surprised Microsoft isn’t
saying that WinForms devs are officially obsolete and need to stick to VS2010 or earlier, but there
is still time for that to end. If you are writing an application now, it will still work with Windows
8. If you want to write an application that takes advantage of the touch interface functionality
really well, and works great on a tablet (and possibly a phone or game console), Metro/WinRT
will be the way to go. I see the big problem for legacy (non-Metro/WinRT) devs is that the
experience of using these apps is currently quite poor; hopefully, Microsoft can improve that
between now and the final version. For the time being, it feels very clunky to go to a Windows 7-
style desktop that lacks much of its functionality (like a “Start” menu).

4. For developers who want to write Metro/WinRT applications, the transition is going to be rough,
unless you have already been working in Silverlight or WPF. Even if you have used WPF, that will
give you the XAML and application model concepts but not the UI paradigms. The UI model that
Metro/WinRT uses is straight from WP7. In the demo apps, there is no easy way to exit. I assume
that Microsoft uses a WP7-like tombstoning/multithreading model, because the only way to break
out of them is CTRL+ESC. Likewise, in WP7 apps, there is no “legal” (as in, “will get past the
App Hub testing process”) way to deliberately exit the app. Don’t like it? Neither do I, and neither
do a lot of other developers. It makes sense for a phone and probably a tablet but not a desktop
OS.
I realize that it is early in the development cycle of Windows 8 — the release isn’t even mature
enough to be called a beta, and there is roughly a year before it hits gold status by most estimates.
Microsoft has been slammed by a ton of analysts, industry observers, and reporters about its habit
of announcing things like this in public well in advance of the actual release. Those folks are only
seeing the PR side of things; for us developers, who are the lifeblood of Microsoft’s ability to
maintain or grow Microsoft’s market share, we needed to see this now. The Metro/WinRT apps are
a major change, and Microsoft needs us on board now so the company can launch with a full slate
of quality titles. Think “new game console” style launch, not a traditional “new OS” launch. The
problem is that unless Microsoft makes the experience of using legacy apps a lot better, Windows
8 will be a very unpleasant experience overall. And the new Metro-style apps are not mapping
well to the keyboard/mouse; for instance, things that on a touch screen require a simple finger
swipe now require the user to hunt down a scroll bar and use it. Metro works great on my WP7
phone and I love it there, but just as the Windows UI was a mess when translated to Windows CE
and Windows Mobile, the Metro UI is a wreck on a desktop PC.
At this point (in other words, if nothing changes on these items between now and final release), I
think this is a good time to decide if you can transition your applications to Web apps.
Metro/WinRT is lousy for apps that do complex work. Meanwhile, IE10 is very invasive
throughout Windows 8. While I often dislike Web apps, I think that for sophisticated tasks, they
are better than Metro/WinRT from what I’ve seen, and the legacy app experience is so bad that not
many developers will want to use it if they can avoid it, and new apps will feel very dated.
Regardless of what shakes out in the final project, it is clear that Microsoft is signaling that
sophisticated desktop applications are a relative rarity, Web apps are much more common, and for
the things that use local resources, users prefer simple apps on the phone/tablet level of
complexity, not applications like we see now. I think Microsoft’s strategy may backfire, as
developers choose to write Web apps (possibly with non-Microsoft technologies) instead of trying
to make their applications work in the very unique, non-backwards-compatible Metro/WinRT
style, or having their applications using the clunky legacy desktop.