Tag Archives: Windows 8

Why I’m not excited about Windows 8 Certified Store Apps

It’s come up a few times recently, and I’m frustrated enough that I thought I’d just post this here for reference.

The Windows 8 App Certification requirements has one particular requirement that makes me (as a life-long scripter) very unhappy:

3.9 All app logic must originate from, and reside in, your app package

Your app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code or data that changes how the application interacts with the Windows Runtime, or behaves with regard to Store policy. It is not permissible, for example, to download a remote script and subsequently execute that script in the local context of your app package

Bottom line: you cannot write extensible apps for the Windows Store. In fact, although Windows PowerShell is shipped even on Windows RT, you can’t use it from a certified Windows 8 Store app.

I don’t know about you, but the apps that I use on a regular basis are almost all extensible, and most of them have both plugins and scripting:

  • Visual Studio (Thank goodness for NuGet, ReSharper, StyleCop, GhostDoc, NCrunch etc)
  • Notepad++ and Sublime Text 2 and PyCharm
  • PowerShell and ConEmu
  • Microsoft Office: Word, Excel
  • KeePass
  • Firefox, and even Chrome and IE
  • XChat and even Trillian

I’ve been using Windows 8 for months now, but every app pinned on my taskbar is extensible, and leaving aside video games, I can only see three apps I’ve used in the last month which aren’t readily extensible: PeaZip (which does have some scripting capabilities, but I don’t use them since I script from PowerShell), Zune, and Trillian (which is technically extensible, but all the plugins I use ship in the box).

Even Windows File Manager has shell extensions.

Now, I’m not saying I won’t use an app that’s not extensible … but without even thinking about it, most of the apps I use are scriptable and/or extensible, and I bet that’s true of most of the apps you use too. As a side note, one of the coolest new phone apps from Microsoft is on{x}, an automation app which is only available on Android (and can’t ever pass validation on the Windows Store because of this policy).

So yeah. Most of the stuff I do with computers is about automation, scripting, robotics… or gaming. I can’t see myself getting really fired up about that App Store stuff.

Let me know when 3.9 is revoked.

Now, I have faith in Microsoft. I’m sure they’re not trying to kill off running multiple windows on a desktop, but I don’t understand why they would write terms in their certification requirements that would prevent an app like Sublime Text 2, KeePass, or Firefox from being written. I certainly hope that they can be convinced to rewrite that constraint to allow for users who choose to install modules and scripts.

As a side note, there’s another point in there that I’m not too happy with either:

4.4 Your app must not be designed or marketed to perform, instruct, or encourage tasks that could cause physical harm to a customer or any other person

We would consider an app that allows for control of a device without human manipulation, or that is marketed for use to resolve emergency or lifesaving situations to violate this requirement.

At first, that one seemed fine. But when you read the detail, it’s clear that any app that is for robotics/AI and wants to interface with external devices is basically going to be refused. Your Lego Mindstorms apps are only allowed if they’re remote controls which require human manipulation, because they … might cause harm?

As long as we’ve got desktop mode and sideloading of non-certified apps, we’re ok (I guess), but Microsoft needs to stop limiting certified apps before they alienate the hackers and tinkerers. I’m a big fan (and author) of Open Source software, but I don’t want a world where all the commercial software companies lock out the geeks and our only option is Open Source.

PowerShell 3 – Finally on the DLR!

For those of you living in a cave: PowerShell 3 will be released in Windows 8, and we got a CTP at roughly the same time as the Windows 8 Developer Preview was released (at Microsoft’s new //Build/ conference in September 2011). A second CTP was released just in time for Christmas.

I’ve been playing with PowerShell 3 for a few months now, and I guess it’s long past time I started blogging about it.

There are a lot of new things coming in this release, but for me, the biggest change is the fact that PowerShell is now based on the Dynamic Language Runtime, a runtime environment that adds a set of services for dynamic languages to the Common Language Runtime (CLR), which is the core of the .NET Framework. The DLR makes it easier to develop dynamic languages to run on the .NET Framework. Of course, PowerShell is a dynamic language that runs on the .NET framework, but it was originally begun before the DLR had been released, so it’s only now that it’s finally been adapted to the DLR.

However, although PowerShell 3 is implemented using the DLR, it’s not a DLR language in every way that IronPython or IronRuby are. Let me borrow a couple of graphics from the DLR overview documentation.

The DLR Overview

DLR Overview

You can see there’s three major sections to the DLR as it’s available on CodePlex: hosting, runtime, and language. However, not all of the DLR actually shipped in the .NET Framework 4.0 CLR.

The DLR shipped in CLR 4

DLR Shipped in CLR4

PowerShell 3 takes advantage of all (or most) of what shipped in the CLR, but since the PowerShell team wasn’t willing to be responsible for shipping the rest of the DLR in the operating system, they didn’t implement the rest of it. Which is to say, PowerShell 3 is using the DLR Language Implementation code, with Shared AST and Expression trees, as well as the DynamicObject and Call Site Caching portions of the runtime, but none of the Common Hosting pieces like ScriptRuntime, ScriptScope, ScriptSource, or CompiledCode …

This means that you cannot use the same hosting APIs for PowerShell that you use for IronPython or IronRuby. However, even though you’re stuck using the same hosting APIs that you used with PowerShell 2 … you do get to use dynamic instead of PSObject when you’re working with the output in C#.

This really is a big deal

I wouldn’t care to speculate how many of the changes you’ll see in PowerShell 3 are directly due to the conversion to the DLR, but there are a few changes that you ought to be aware of. The first thing that you’ll probably notice is the difference in execution and performance. Anything you’ve learned about the relative performance of Scripts vs. Functions vs. Cmdlets and the load time of binary vs. script modules is going to go right out the window with PowerShell 3, as scripts and functions are now no longer (re)interpreted each time they’re run, but are compiled, executed, and (sometimes) cached. The result is that initial runs of scripts and imports of script modules are sometimes slower than they used to be, but subsequent runs of the same script or execution of functions from script modules run much faster, and this applies in particular to actual scripts in files and pre-defined functions in modules. Running a function repeatedly is now much faster than pasting the same code repeatedly into the console.

A more subtle, but significant difference is the change to PSObject.

In PowerShell 3, PSObject is a true dynamic object, and thus the output of cmdlets or scripts called in C# can be used with the dynamic keyword in C# instead of with the pseduo-reflection methods which are required for working with PSObject. However, this is just the tip of the iceberg, so to speak.

In PowerShell 2, all of PowerShell’s Extended Type System (ETS) was based on PSObject. New members were always added to a PSObject which is wrapped around the actual “BaseObject” — regardless of whether they came from a types.ps1xml file, or from calling Add-Member on an object. If you use Add-Member on strongly objects that are not already wrapped in a PSObject, you have to specify the -Passthru parameter and capture the output in order to have your object wrapped into a PSObject that the new member can be added to. In addition, when you cast an object to a specific type, those ETS members are mostly lost. Take this script for example:

$psObject = Get-ChildItem
$Count1 = ($psObject | where { $_.PSIsContainer }).Count

[IO.FileSystemInfo[]]$ioObject = Get-ChildItem
$Count2 = ($ioObject | where { $_.PSIsContainer }).Count

$Count3 = ($ioObject | where { $_ -is [IO.DirectoryInfo] }).Count

In PowerShell 2, $Count1 and $Count3 will be the number of folders in the current directory, but $Count2 will always be ZERO, because the PSIsContainer property is actually an ETS property that’s lost when you cast the object to FileSystemInfo (and therefore it always evaluates as null and

However, in PowerShell 3 that’s no longer true. PowerShell now works with everything as dynamic objects, and Add-Member no longer needs the PSObject to keep track of these ETS members. This script will now get $Count1, $Count2, and $Count3 equal, as expected. Obviously the -Passthru switch on Add-Member is only needed when you’re trying to pipeline things, and not for simple assignments. However, there may also be other implications on when things get wrapped into a PSObject, and when it matters.

I think you’ll agree that having PowerShell on the DLR is awesome! But be aware that there are a few inconsequential breaking changes hiding in this kind of stuff. For example, after running that script above, try these three lines on PowerShell 2 and PowerShell 3 CTP2:

$Count1 -eq $Count2
$e = $ioObject[0] | Add-Member NoteProperty Note "This is a note" -Passthru
$f = $ioObject[0] | Add-Member NoteProperty Note "This is a note" -Passthru

In PowerShell 2, you’ll get False, and then the next two lines will work fine. In PowerShell 3 the first line will return True, and since Add-Member actually affects the underlying object even when it’s not wrapped in a PSObject, the third line will actually cause an error, because “Add-Member : Cannot add a member with the name “Note” because a member with that name already exists.”

Anyway, I’m sure I’ll have more to write about the DLR and the changes it’s bringing to PowerShell, but for now, I hope that’s enough to get you thinking ;-)