Getting shelf space in the Store

Reading the Windows Store for developers blog recently, I was pleasantly surprised to see that desktop (i.e., non-Metro-style) apps would be allowed to show up in the Windows Store. Desktop apps won’t get the same treatment as Metro-style apps, of course; instead of being able to install apps right from the Windows Store, desktop apps will have a similar listing page with a link to the developer’s site to handle download.

Still, it’s better than nothing — the Windows Store is likely to have a lot of window shoppers looking to buy apps.

However, a hurdle to get an app listing page is that the app must pass “certification.” In the past, this was known as the Windows Logo program and had many pages of technical requirements. In Windows 8, the list is much smaller and less prescriptive. For example, the Logo program for previous versions required the use of MSI, then required MSI or ClickOnce; for Windows 8, there are no technology restrictions.

Some requirements that struck me as interesting:

1.2 Your app must not take a dependency on the VB6 runtime

VB6, IE6 — anything v6 must go away. 🙂

5.1 Your app must properly implement a clean, reversible installation

If the installation fails, the app should be able to roll it back and restore the machine to its previous state.

If Windows 8 certification is anything like previous versions’, it will involve automated test suites that will highlight rollback that’s less than perfect.

5.4 Your app must never block silent install/uninstall

So don’t throw UI from custom actions and don’t rely on being able to prompt the user (i.e., also don’t break requirement #5.1).

6.1 All executable files (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) must be signed with an Authenticode certificate

MSI packages aren’t mentioned. But if you ship a Burn bundle or other bootstrapper .exe, that’s going to require signing.

10.1 Your app must be installed in the Program Files folder by default

There’s nothing mentioned that would exempt per-user apps in general from this requirement, though you can always request exceptions. Given the emphasis Metro places on per-user, restricted apps, perhaps this requirement will be extended/relaxed for per-user desktop apps too.

10.6 Your app must write user data at first run and not during the installation in “per-machine” installations

Long-time readers of wix-users will recognize this as advice given again and again. Good to see Windows catching on. 🙂

10.7 Exceptions and Waivers

A waiver is required for apps that write to the global assembly cache (GAC) .NET apps should keep assembly dependencies private, and store it in the app directory unless sharing an assembly is explicitly required.

I suspect it’s a response to the GAC getting used too often when it’s not needed or very useful. (See also Rico Mariani’s blog post on using NGen, which falls into the same boat.) Still, I’m mildly surprised to see it a requirement.

12.5 App running under the WoW64 emulator should not attempt to subvert or bypass Wow64 virtualization mechanisms

This one’s interesting, depending how struct “subvert” turns out to be. For example, several WiX custom actions make fairly trivial “subversions” of WoW64 to avoid the need for both 32-bit and 64-bit custom actions just to write to the right version of Program Files.

All in all, there’s nothing terribly surprising in this set of requirements. A lot of them just codify what’s already known as best practice for Windows apps in the age of UAC. Of course, this is just the first version of the certification requirements and Windows 8 isn’t yet shipping; there’s plenty of time for Microsoft to add, drop, or change requirements. In the end, you get to decide whether the effort of certification is worth having a presence in the Windows Store. Remember the Metro-style app folks, who have no choice in the matter: The Windows Store is the only way they can ship.

Same as it ever was

Microsoft’s BUILD conference is going on this week and it’s chock full of new information about Windows 8 (or whatever they end up calling it). The biggest news is the new Metro-style application, which includes the AppX package format for installing them.

There are three primary buckets applications fall into in the brave new Windows 8 world:

  1. Metro-style
  2. Windows 8 non-Metro-style
  3. “Retro-style” (aka legacy, anything created before 2011)

Metro-style apps get all the goodies Windows 8 offers, including AppX packaging I’ll blog about. As Rob describes, deployment is a first-class citizen in Windows 8. Apps in the other two buckets have the exact same options they have in Windows 7. And by exact, I mean “really, almost exactly 100 percent.”

No soup for you

As is its wont, rather than fixing the weaknesses of its existing platform, Microsoft replaced it with an all-new platform with a different set of weaknesses. Naturally, Windows 8 still includes Windows Installer. But if you were hoping for some of the same deployment love for your non-Metro-style apps that the Windows team showered on Metro-style apps, I’m sorry to disappoint: For better or worse, Windows 8’s MSI is functionally identical to Windows 7’s MSI v5.0.

A quick spelunking in the Windows 8 SDK available to MSDN subscribers reveals mostly structual changes to the MSI header files. For example, the _WIN32_MSI macro is defined as “500” for both Windows 7 and Windows 8:

#if (_WIN32_WINNT >= 0x0601 || (defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN8))
 #define _WIN32_MSI   500
#elif (_WIN32_WINNT >= 0x0601 || (defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN7))
 #define _WIN32_MSI   500

The only addition is a new MSIARCHITECTUREFLAGS value in Msi.h:

 MSIARCHITECTUREFLAGS_X86   = 0x00000001L, // set if creating the script for i386 platform
 MSIARCHITECTUREFLAGS_IA64  = 0x00000002L, // set if creating the script for IA64 platform
 MSIARCHITECTUREFLAGS_AMD64 = 0x00000004L, // set if creating the script for AMD64 platform
 MSIARCHITECTUREFLAGS_ARM   = 0x00000008L //set if creating the script for ARM platform

and a new property name in MsiDefs.h:

#define IPROPNAME_ARM              TEXT("Arm")

As we’ve known for a while that Windows 8 will support the ARM architecture, its presence isn’t too surprising.

There are no other new enumeration values. There are no new MSI API functions. While it’s possible there are, for example, new standard actions that wouldn’t have visible impact in the header files, I don’t find it too likely.

That yields two tiny bits of good news:

  1. Lack of visible interface changes probably means a lack of visible behavior changes. That likely means that your Retro-style installers will probably work without change, or at least as well as the classic Windows 8 desktop supports Retro-style apps.
  2. WiX and Burn won’t need to do anything to support Windows 8. OK, that’s something only a few of us need to worry about…

Coming up: More about Metro-style deployment.

MSI v5.0 features in WiX v3.0

MSI 5.0 ships in the recently released Windows 7 beta. When the Windows 7 beta SDK was released, Rob and I had the detailed information we needed to add support for those features in WiX. A week and a day later, WiX v3.0.4917.0 includes that support.

What’s new?

Google Chrome setup

Google today released (after a bit of a comic-book pre-release, presumably due to the Labor Day holiday in the US) Google Chrome, its long-rumored open-source browser. Plenty of people will talk (endlessly) about the implications of another browser and how well Google Chrome and Chromium (the open source project) do the job. Blah, blah. Whatever. What’s really interesting is a couple of choices Google made about deployment:

  1. The Google Chrome download is a svelte 474K bootstrapper that downloads the setup bits. No offline installer is available (unless it’s well-hidden).
  2. Google Chrome is a "composite" setup: The guts of the application are installed by a non-MSI self-extractor. However, Google Chrome includes Google Gears, the browser add-in/library that adds a bunch of functionality for making apps-in-the-browser more powerful. The Gears in Google Chrome is installed by an MSI package. And yes, it’s built with WiX.
  3. The Google Updater is no longer a LocalSystem service; instead, it starts at logon from the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key.
  4. Last and absolutely not least: Google Chrome is a per-user application. It even installs in the per-user LocalAppDataFolder. (The included Google Gears is marked as "UAC compliant.")

That Google Chrome is a per-user app is amazing. Even with UAC on Windows Vista and Windows Server 2008, it’s so easy to say that "everyone’s used to needing admin privileges to install." That Google took the extra effort to limit themselves to the capabilities of a per-user app says a lot about their desire to have:

  • a low-impact setup
  • and absolutely no barriers to entry.

I wonder if it’s the start of a trend…

Feature states in component conditions

MSI has some funky syntax to support checking the action state (what MSI is planning to do during the current install transaction) and install state (what MSI already did, in a previous install transaction) of both features and components. See Conditional Statement Syntax for the details and Examples of Conditional Statement Syntax for some examples. (As an aside, would it have been too much to ask to avoid the Perl-like prefix characters and have something function-like such as FeatureActionState(featureId)?)

A couple of people on the wix-users mailing list have asked about using the feature action state in component conditions. There’s good news and bad news.

Good news for simple cases

The good news is that in simple cases with simple conditions, there’s probably another way to get the behavior you’re looking for. For example, one component can be assigned to multiple features, so if you’re trying to install a component when any of several features are being installed, just reference the component in all the features. MSI will install the component once, regardless of how many features reference it.

The bad news

If you want to conditionalize a component based on whether a particular feature is being installed (i.e., its action state), you can’t rely solely on the component’s condition. The Component Table doc has this to say:

The Condition field enables or disables a component only during the CostFinalize action. To enable or disable a component after CostFinalize, you must use a custom action or the DoAction ControlEvent to call MsiSetComponentState.

The CostFinalize action doc says:

The CostFinalize action queries the Condition table to determine which features are scheduled to be installed. Costing is done for each component in the Component table.

Unfortunately, it doesn’t state explicitly that the order of the two sentences is the order of execution. But, even if it did, there’s this table in Conditional Statement Syntax:

Feature and Component State Values

The following table shows where it is valid to use the feature and component operator symbols.

Operator <state> Where this syntax is valid
$component-action In the Condition table, and in the sequence tables, after the CostFinalize action.
&feature-action In the Condition table, and in the sequence tables, after the CostFinalize action.
!feature-state In the Condition table, and in the sequence tables, after the CostFinalize action.
?component-state In the Condition table, and in the sequence tables, after the CostFinalize action.

So there are two fairly explicit strikes against being able to use a feature action state in a component condition:

  • Conditional Statement Syntax doesn’t list the Component table as a valid place to use the &feature-action syntax.
  • It says the syntax is valid only after CostFinalize but according to Component Table, that’s too late to use the component condition to enable/disable the component.

The Component Table says to use a “custom action or the DoAction ControlEvent to call MsiSetComponentState.” I haven’t quite deciphered whether the doc is saying to use DoAction to call a custom action from the UI or whether there’s a special, secret way of calling MsiSetComponentState via DoAction. If it’s the latter, I’m not aware of it (hence “special, secret”).

Here be dragons

Having been a writer for many years, I try to be nice about doc that is correct, even if in retrospect it’s not as helpful as it could have been. So here’s me being nice. The following sentence from Component Table easily leads a trusting reader down the wrong path:

The Condition column in the Component table accepts conditional expressions containing references to the installed states of features and components.

So here we have a sentence that contradicts the table in Conditional Statement Syntax and it’s really easy to misread the “installed state[s]” as “action states.” At the very least, it deserves clarification.