A closer look at the Windows 8 post-RTM update process

So, last week, Steven Sinofsky announced the availability of a cumulative update for Windows 8. Bundled with that announcement was some insight into what happens with fixes made after the OS goes gold (or RTM). Specifically, Sinofsky explained that certain fixes get delivered to OEMs prior to the public:

We would often create dozens of changes for each OEM for these new PCs. Those changes would be deployed during manufacturing of those PCs and thus would be invisible to customers. While those changes could potentially apply to a broader range of PCs, we did not have in place the testing and certification to broadly distribute these updates. As a result, customers would have to wait until the first service pack to see these enhancements.

He continued, indicating that with Windows 8 some internal processes changed, allowing Microsoft to deliver these updates sooner than general availability (GA):

During the final months of Windows 8 we challenged ourselves to create the tools and processes to be able to deliver these “post-RTM” updates sooner than a service pack. By developing better test automation and test coverage tools we are happy to say that Windows 8 will be totally up to date for all customers starting at General Availability. If you are an MSDN or enterprise customer, these updates will be available for your Windows 8 PCs via Windows Update as of today (October 9), following our standard cadence for Windows Updates on the second Tuesday of each month at about 10:00am.

Sounds good to me.

But let’s not fool ourselves into thinking this process is new. Gregg Keizer (Computerworld) fell into that trap, writing:

In Microsoft's terminology, RTM designates the point at which it considers the code completed, and ready to ship to computer makers for installing on new PCs. Microsoft has never updated a version of Windows between RTM and when the OS hits retail and PCs powered by it reach stores.

Matthew Siegler did too, mumbling:

Probably not the best sign in the world that Microsoft has to release service packs [sic] to the RTM version of Windows 8 before it has even launched. I mean, why declare RTM then? Well one possibility is that you’re working to meet a deadline rather than releasing when a product is fully baked.

Look, guys. Microsoft has been updating Windows in this manner for ages – at least since Windows Vista. That was so 6 years ago. To be more specific, Windows Vista saw a heap of updates, including the infamous Ultimate Extras pack, January 29, 2007 (a day before GA). Windows 7 received similar reliability updates on October 12, 2009 (10 days before GA).

Here's what the timelines look like, with the pre-GA/post-RTM release cadences in red:

What’s really new here is the delivery of updates previously reserved for OEM first use. (Ever wondered why OEMs had those atrocious software download pages with a weird assortment of Windows hotfixes?) It is the inclusion of these specific updates as part of the old patch delivery cycle that likely required the tooling and engineering improvements Sinofsky mentioned -- something definitely worth lauding.

Okay, maybe it's about app restrictions on Windows 8? Not that either.

[This is part 3 of the Minecraft/Windows saga. Go back and read part 1. Or part 2.] So if all this Minecraft noise isn't about closed marketplaces, then maybe it's about changes to how desktop applications get installed/run on Windows 8. That must be it, right?

Nope.

Windows 8 will run all your existing desktop applications from Windows 7. Windows 8 simply introduces new channels to advertise and obtain software for your PC. A common mistake is to confuse Windows 8 with Windows RT, a subset of Windows 8 tailored for devices (like how iOS is a subset of Mac OS).

Here's a chart showing app options available to users, starting with Windows 7. As you can see, Windows 8 didn't lose any features. To claim it's closed or more restrictive than Windows 7 is just completely bogus.

Rev 1: Changed marketplace accessibility row label, removing the 120 markets it's not clear if App Store reaches 120 markets. (Not likely.) Added the 120 number onto the value for Windows 8 in this row.

Maybe it's about closed marketplaces? Nope.

[This is part 2 of an on-going saga. Re-read part 1. Or move on to part 3.] Yesterday, I brain dumped in response to Notch's complaints on Twitter. My goal with that post was to point out that Microsoft reached out to Notch in a friendly attempt to get Minecraft listed in the Windows Store as a desktop app, not a "Metro" app. His reaction to the email appeared to be based on confusion surrounding how apps work on Windows 8 and the new Windows Store.

But a buddy of mine -- Leo Davidson -- suggested that I may have missed Notch's point, writing:

[...] he disagrees with the move to a model where Microsoft control[s] which [what] software people find [...] Rather than support that model, as easy as it might be for him, he would rather have nothing to do with it, even if it means his games reach a smaller audience as a result.

That would be a fair point, ... if Mojang AB wasn't already participating in identical models:

Rev 1: Added Amazon's App Store, thanks to reader Ian A.

Notch doesn't hate Windows 8, he's just confused

[This is part 1 of an on-going saga. Check out part 2. Or part 3.] http://twitter.com/notch/status/251239807257296897

http://twitter.com/notch/status/251240819892305922

So last night, Markus "Notch" Persson -- the Minecraft guy -- mentioned that Microsoft reached out to the company (Mojang AB) in an attempt to get the wildly popular Minecraft video game into the Windows Store. Shortly after, though, he denounced Microsoft for "ruining the PC" with Windows 8 and its "closed" nature. What's really going on here: Notch is just confused about Windows 8.

Allow me to help.

After Windows 8 hits the shelves, there will be two classes of applications that run on the PC:

  • Desktop Apps
  • Windows Store Apps (previously Metro Apps)

(There are also Desktop Device Apps but lets ignore those.) Desktop apps are the applications we use today. Photoshop. Visual Studio. Office. Each application has its own experience which, at times, can be difficult to use or even master. Take Minecraft for example -- it had a "textbox" for specifying the hostname or IP address of a server to connect to. But it wasn't until recently that users could paste text into this textbox from the clipboard. Users expected it to work, but it didn't.

Cue Windows Store Apps. These are newer PC apps that are held to a strict code to ensure users are provided a consistent, elegant, and easy-to-use experience. These apps come from one place -- the Windows Store -- with dependencies quietly in tow and out of sight. You can say, in most cases, they Just Work. (For more insight on this vision, be sure to check out Steven Sinofsky's write up on the Building 8 blog.)

Both app types are supported in the Windows Store. Windows Store Apps obviously get preferential treatment -- that is, they are submitted to and hosted by Microsoft, tie into bug reporting and analysis tools, support in-app purchase, etc. Desktop apps are left to continue doing what they do today but can benefit from a listing in the Windows Store. (More details on how desktop apps look and behave in the store can be found on the Windows Store blog.) [Added 9/28/2012 @ 8:55PM PST]

Like the classified ads in your local newspaper, listing your app in the Windows Store isn't free. Justifying those fees, however, is access to Windows users across 120 markets -- that is, nearly anyone on this planet using Windows. Crazy, right?

And one other thing: Your application must follow some rules to ensure nothing goes awry on the user's machine. These rules differ based on what kind of app you're submitting and unsurprisingly require one of two certifications: Windows Store App Certification or Desktop App Certification.

Let's return to the tweet situation for a moment.

I contacted Microsoft about the ordeal and they confirmed reaching out to Notch. But Microsoft did not ask for the guys to rework Minecraft into a Windows Store App or participate in any walled app gardens. (Though it's noteworthy that Mojang AB is not unfamiliar with playing in these spaces. After all, they have Xbox 360, iOS, and Android versions of Minecraft in some form on the market today.) Microsoft was simply offering assistance in pushing Minecraft through the Desktop App Certification process.

Let's dissect that process now.

The Desktop App Certification process isn't new. Back in the days, it was called the Windows Software Logo Program -- you know, that program that Microsoft tried to nudge developers to participate in to no avail. Generally speaking, it's a document filled with best practices-turned-requirements that if implemented net you a spot in the Windows Store. A fair deal, I think.

But you can't implement and submit your app to the Windows Store blind. Microsoft conveniently provides a set of tools to mock certify your application, eliminating most of the guess work associated with submitting your application to the Windows Store. They run the same tests over there.

I took Minecraft and ran it through these tests myself, to see what passed and what failed. While I passed my mock certification, I did so with some warnings that would very likely result in rejection or at the very least raise some eyebrows. (I suspect they are labeled as warnings because waivers could work around them if needed.)

Here's what I got dinged on:

Windows Security Features Test

Microsoft is constantly evolving the security landscape of Windows operating system, developing and improving protection against coding mistakes that lead to scary-sounding issues, like buffer overflows. Enabling these features once required app developers to opt-in to the protection. Not anymore. To play ball, you need to get with the program and ensure you compile your app with the following security features enabled:

Details: Minecraft.exe currently fails this test (with a warning). While I can't be certain, it appears Mojang AB cross-compiles Minecraft.exe for Windows via gcc. Or perhaps they use a mingw/cygwin/vc++ compiler environment. Let's hope for the latter because gcc doesn't support some of these features. A switch to the Windows SDK or Visual Studio 2012 Express for Windows Desktop software is likely in order.

User Account Control (UAC) Test

UAC is a set of complicated security technologies that debuted in Windows Vista. Short version: Your application is reduced to having little to no privileges by default, requiring "elevation" or hoop jumping by authorized users to gain access to sensitive bits of Windows. They relaxed it a bit in Windows 7, to the point where it's now a Good Thing. (You can read all about it on MSDN.) This particular test just inspects the app for a little XML file called the Application Manifest. It describes to the OS what the app needs in terms of permissions, dependencies, etc.

Details: Minecraft.exe fails this test (with a warning). This is trivial to fix -- embed a tiny Application Manifest that simply indicates that it needs no special access and can run safely in the user's sandbox. (i.e. add requestedExecutionLevel level=asInvoker)

Digitally Signed File Test

This one is simple. Code should be digitally signed to confirm where it came from and to ensure its intact when the user receives it.

Details: Minecraft.exe fails this test (with a warning). It isn't digitally code signed. (Now, there's no requirement that Mojang AB actually "check" this signature, so modders fear not.)

Install To Program Files Test

For application storage consistency and security, Microsoft requires apps be installed to the trusty ol' Program Files folder.

Details: I put together a quick, NSIS-based per-user installer for Minecraft.exe. Per-user installers typically install apps for use by a single user so naturally they cannot be installed to Program Files. I chose per-user in the certification tool but Minecraft still failed this test (with a warning). It appears I hit a certification bug but I'm waiting for Microsoft to get back to me on this one.

... and, that's it. Minecraft passed every other test.

If Mojang AB needs a hand, feel free to email me. I'd be delighted to help.

Rev 1: Added a clarifying paragraph on how Windows Store/Desktop apps get hosted in the Windows Store. It has been time-stamped with gray text accordingly.

My Crazy Adventures with RemoteFX, Part One

[This is part one of the "My Crazy Adventures with RemoteFX" series]

Over a year ago, I began documenting my adventures with a quaint little technology called RemoteFX. But to the dismay of my readers, and myself, I abruptly stopped with only laziness to blame. (Okay, that's not fair to myself. I do have a full-time job and all.) But it was the barrage of personal requests and continued support in Windows Server 2012 that enticed me to pick it up again. So here we are; let's try this again. (I'll be rehashing some of the old material as it's still useful and current.)

What is RemoteFX again?

RemoteFX is a fancy name affixed to a set of technologies purchased from Calista Technologies. This tech was first introduced in Windows Server 2008 R2 SP1 with one main goal in mind: Improve the end-user experience for virtual desktop users – users that use a Windows desktop over a RDP client. By improve, we're talking about bringing users closer to a "real" local experience – full-motion video, fluid Flash and Silverlight animation, and accelerated 3D graphics.

RemoteFX enhances both Windows desktop virtualization paradigms – session virtualization and a Hyper-V based Virtual Desktop Infrastructure (VDI). The former generally refers to the aging Terminal Services-like set up, in which users remote into a server and have a space for doing what they do. The latter replaces the spaces with full blown, virtualized instances of an operating system. While RemoteFX brings some improvements to the classical session-based configuration, I won't be covering them at all.

So how does this all work? Well, there are a few moving pieces:

  • A WDDM-capable virtual GPU (vGPU) driver
  • Hyper-V management and platform integration components
  • Virtual Graphics Manager processes

The vGPU driver lives within the guest virtual machine. This driver implements all the necessary functions to emulate a WDDM-capable graphics device driver. It receives calls to various graphic APIs and, using the Hyper-V components, ferries them to the host virtual graphics manager for rendering and encoding. (This occurs on the host's more powerful GPU.) After completion, the results are transmitted back to the guest and then to the client.

How, exactly, does my experience improve?

To talk to how RemoteFX makes life better, we have to talk about a handful of specific scenarios that weren't possible before over a vanilla RDP client. Specifically, scenarios involving:

  • DirectX-accelerated applications, games
  • Silverlight and Flash
  • Full-motion video
  • USB devices

Let's break it all down.

DirectX

I put DirectX at the top of my list because it's one of the most compelling features of RemoteFX. To be able to play an accelerated game, like Unreal Tournament 3, over RDP on a laptop with unusable Intel graphics is just amazing. To set expectations, RemoteFX currently supports Microsoft's latest offering of DirectX 11. In terms of pixel/vertex shader support, you've got full access to 5.0 level goodies. If you were thinking of virtualizing Minecraft, however, you're out of luck — OpenGL was left on the side-lines, with minimum software-only (1.1) support.

Feature summary:

  • DirectX support: 11
  • Vertex/pixel shader support: 5.0 and earlier
  • OpenGL support: Nil (uses built-in 1.1 software support)

Microsoft Silverlight/Adobe Flash

With regards to Silverlight and Flash… well, how many times have you used Internet Explorer over RDP and stumbled across a page with humongous rich advertisements causing slowdowns? Those days are over. RemoteFX ties into both Direct3D and DirectX Video Acceleration (DxVA) APIs to accelerate Silverlight and Flash respectively.

Flash (starting with 10.1) ties into DxVA APIs for the acceleration of video decoding and (full-screen) rendering operations. But because of the way RemoteFX was implemented, hardware acceleration isn't a capability Flash (10.1) can detect at this time, so it falls back to using some software logic. Don't fret through, RemoteFX still accelerates lots of DxVA operations – software or otherwise – and boosts performance greatly. (In newer versions of RemoteFX/Flash this is a non-issue.)

Silverlight, on the other hand, with its custom software renderer, is accelerated a little differently. It supports off-loading to the GPU, but… to be honest, I don't understand how it works. Not even after a year of tinkering with it. (It doesn't tie into DirectX.) Any information you have on this subject would be greatly appreciated.

Feature summary:

  • Silverlight: Off-loads work to the GPU via magic. (I don't have details yet, sorry.)
  • Flash: Accelerated video rendering, (mostly) software video decoding.

Full-motion video

With the tie-ins to DirectX Video Acceleration, RemoteFX also enables full-motion video delivery. For example, by using a DxVA-capable player (e.g. Windows Media Player, VLC), you can decode and send full blown 1080p video to a laptop or thin client. Some of you may be wondering – wait, wasn't this already possible with Multimedia Redirection? Not quite. Multimedia Redirection is simply just that – a redirect. It redirects the source stream to the client, for rendering on the client side (requiring a decent GPU). RemoteFX differs in that it renders on the host side and takes advantage of the GPU there.

Feature summary:

  • Ties into DirectX Video Acceleration
  • Can work alongside Multimedia Redirection or replace it altogether

USB devices

Last but not least, RemoteFX supports the redirection of USB devices including isochronous (time sensitive) devices such as webcams, where audio and video must be synced together. Because devices are redirected as such a low level, the client doesn't even need drivers installed. This enables all sorts of neat server-side management scenarios not possible over vanilla RDP.

Feature summary:

  • Let's you connect a wide-range of USB devices to your virtual environment
  • Notable support for isochronous devices, such as webcams.

Looking forward

In the next several posts, I'll explore RemoteFX dependencies, to include licensing and hardware, and provide clarifying details on installing and configuring RemoteFX. Stay tuned!

 

Revised August 31, 2012 (Changed DirectX support from 9.0 to 11.0. Was a carry over from old post that wasn't updated correctly.)