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.)

Thoughts on the Windows SmartScreen scare

Important update: My original post failed to address the data in FName and as a result, was slanted towards Microsoft. I have since then, however, re-evaluated the issue and edited the article as such. The original content has been left intact/scratched out for full transparency. This is the first time I've ever hit publish on data I haven't fully checked and I'm extremely disappointed with myself. Sorry I let you down.

So a tinkerer by the name of Nadim Kobeissi wrote a scare piece today, proclaiming Windows SmartScreen was reporting back information about every application you download and install on your machine. Kobeissi, oddly, failed to actually show what this data looked like. So here's what the fuss is about:

<Rq V="1.2">
  <RqT>0</RqT>
  <App>
    <FName>U2FtZUdhbWUuZXhl</FName>
    <FHash>d3ff5939726c9f8fa6e514fb65eb470a1f9ec7a65b2706732
a03749226c2520</FHash>
    <Sig>0</Sig>
    <Sz>45056</Sz>
    <M>1</M>
    <SR>100</SR>
  </App>
  <ID>0F98AD9C-D498-42B3-B421-E6C97A8E61E7</ID>
  <G>B68802CA-B396-4773-8FD9-EEECA4DE65D9</G>
  <L>ZW4tVVM=</L>
  <OS>6.2.9200.0.0</OS>
  <I>OS4xMC45MjAwLjE2Mzg0</I>
  <C>10.00.9200.16384</C>
  <DJ>2</DJ>
</Rq>

The only interesting part here is the data contained in the FHash element. This data represents a SHA-256 hash of the exectuable content (not filename) you ran on your PC. (In this case, I just downloaded and ran a random XNA-based game from Codeplex.)

The interesting nuggets of data here are contained in the FName and FHash elements.

FName contains a base64 encoded representation of the executable file name you downloaded and ran on your PC. In this case, I downloaded and ran a random XNA-based game from Codeplex with a name of SameGame.exe. If you run that through a base-64 encoder, you end up with U2FtZUdhbWUuZXhl.

FHash represents a SHA-256 hash of the executable contents, to eliminate file name-based false positives (think of a game named virus.exe).

So could Microsoft track everything you download and use? No. Yes. But will they? Unlikely.

Microsoft doesn't have hashes of every piece of software out there to match against, nor do Windows SmartScreen users send in enough data (like filenames) to build such a database dynamically. Assuming they retained IP data -- which I seriously doubt they do -- they could possibly determine what types of malware you almost ran. But who cares? It just saved your ass at that point.

Armed with file names, Microsoft could -- in theory -- be building a database matching IP addresses to files downloaded/run, but let's be real -- it's Microsoft. This is the same company that's scared to fart in fear of litigation. (They won't even defend their Metro design language naming for crying out loud.) I expect Microsoft to respond with a statement about how this data is anonymized internally. And if that doesn't relieve the pressure, I expect an update to remove the file name reporting aspect of the service, given malware often mutates and changes file names.

But look, you have the power of choice. You can turn off Windows SmartScreen via Action Center -> Change Windows SmartScreen settings, and subsequently turn off annoying Action Center warnings by clicking Turn off messages about Windows SmartScreen in the same window.

Windows 8 Secrets, Beyond the Book: Guide to Product Editions

In the book Windows 8 Secrets, we provide a handy series of tables explaining the major differences between the Windows 8 product editions, which include Windows 8 (Core), Windows 8 Pro, Windows 8 Enterprise, and Windows RT. Here, however, we present a far more complete feature breakdown than you’ll see anywhere else. Pre-order Windows 8 Secrets today on Amazon.com and save!

As a reminder, Microsoft first provided a feature breakdown for the various Window 8 product editions back in April, in a post titled Announcing the Windows 8 Editions. As with similar Microsoft-produced tables for previous Windows versions, however, this this breakdown is woefully inadequate. So in Windows 8 Secrets, we provide a more detailed set of tables based on functional areas such as hardware capabilities, upgrade capabilities, Metro features, desktop features, and so on.

In the book, we were somewhat constrained in the book by space reasons and by the needs of the target audience. But we know that some readers are interested in the most comprehensive possible breakdown of features that are included in each product edition. And while the following is not technically complete—a full features breakdown would be mind-numbingly complex and arguably pointless—what you see here is an exclusive deeper dive than you’ll see anywhere else.

Our goal, of course, is to keep this table as accurate as possible. If you notice any mistakes or missing features, please let us know: Paul ThurrottRafael Rivera

This post was cross-posted at Paul Thurrott's SuperSite for Windows.