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.

What opportunities? Well, I have a few things in the works but for now here’s a vague Q&A using an icosahedral decision-making device:

Q Are you resigning from the WiX community as well?
A My sources say no.

Q Are you going to work for a Microsoft competitor?
A Don’t count on it.

Q Will you be available for consulting?
A You may rely on it.

Q Are you going to write a WiX book?
A Signs point to yes.

Q More than one WiX book?
A Outlook good.

Q Will you develop additional tools, custom actions, or extensions for WiX?
A Most likely.

Q Will you contribute them to the WiX project?
A Concentrate and ask again.

Q Will they all be available as open-source?
A Ask again later.

Stay tuned for details.

In closing, I’d like to thank Rob for creating WiX, doing the work to make it Microsoft’s first open-source project, and giving me an opportunity to contribute these past six-plus years. It’s safe to say it kept me moderately sane on more than one occasion. I got to know the original batch of core WiX developers and help the “next generation” come in. Along the way, I learned a lot, mostly (but not exclusively) about development, WiX, and MSI.

WiX was first released publicly a few months before I joined Microsoft and I was immediately intrigued. Then I joined Microsoft and helped ship WiX v2.0, v3.0, and v3.5. Now I’ve come back full circle, on the outside eagerly awaiting v3.6 and the opportunities it brings.

The latest release of Mercurial and TortoiseHg, a set of Windows shell extensions and GUI tools for Mercurial, was just released. This latest version (v1.5 and v1.0, respectively) includes both tools integrated into an MSI installer built with WiX. Previous versions were built with (the excellent but non-MSI-based) Inno Setup toolset. The WiX-based installer has the advantage of using a merge module for TortoiseOverlays (login as guest with an empty password), an icon overlay handler shared by shell extensions for several different version control systems: TortoiseHg for Mercurial, TortoiseSVN for Subversion, TortoiseCVS for CVS, TortoiseBZR for Bazaar, TortoiseGit for Git, and probably others.

As usual, I opened the TortoiseHg .msi in Orca before installing it on my workstation. I was pleasantly surprised by the low number of custom actions. I ran it through WiX v3.0’s Smoke.exe to run ICE validation; there were lots of errors and warnings but all but a few were from TortoiseHg’s use of the Visual C++ runtime libraries merge modules. (Is it ironic or just plain sad that they have so many ICE errors? Maybe both.)

Though we don’t use Mercurial for WiX version control—yet, anyway—both SourceForge.net and Codeplex support Mercurial for a project’s VCS.

• Read the Mercurial v1.5 release notes.
• Read the TortoiseHg v1.0 release notes.
• Download the combined Mercurial and TortoiseHg installer.

OK, so driving was not in the picture for my daily commute to the Fortress of NERDitude. Currently, my daily commute takes about half an hour of waiting for a bus or a train and sitting/standing while someone else does the driving. Doing nothing is much more relaxing than driving in Cambridge traffic, of course, but even with good music, doing nothing gets boring pretty quickly.

I could just bring along my trusty Nintendo DS but I figured that would get boring eventually too. Plus, I figured I could be a bit more mature than that and do something, I dunno, productive like read mail or blogs…

I considered just browsing the Web on my phone, but rejected that idea:

• Web latency over 3G networks is painful.
• 3G networks aren’t terribly reliable underground.
• Web UIs are painful on small screens.

A laptop or even UMPC is out, because I knew I’d frequently need to work one-handed, keeping the other handy for not falling over during the less-than-smooth parts of the Red Line.

No, I needed a small, handheld device that could sync mail and blogs and let me read them offline.

No, it’s not an iPhone

After some research, I bought an iPod touch. (Perhaps in a couple of weeks, my implant will kick in and I’ll do this all again on a Zune HD.) I also bought Phantom Fish’s Byline RSS reader, which syncs to Google Reader. Once I supplied my account name and password, reading blogs using Byline is easy:

• Tap the sync button to download the latest blog posts.
• Read posts and mark some for later follow-up once I’m back online.
• Before heading home, sync to update Google Reader with the posts I read and to download the latest blog posts.
• Once I’m back in range of my home WiFi, sync again.

Please, sir, may I have some more?

Buying apps from Apple’s App Store is simple; the hardest part is typing a strong password into the on-screen keyboard:

• Start the App Store app.
• Search or browse for an app.
• Tap the price and it turns into a BUY NOW button.
• Tap BUY NOW.
• Enter your iTunes password.
• The app is downloaded and installed.

Updates are handled in much the same way:

• Start the App Store app.
• Tap the Updates button.
• If there are any updates, tap the Update All button to download and install the updates in the background.

Because I have an iPod touch instead of iPhone, all my interaction with the App Store happens over WiFi at respectable speeds. (Even better, it doesn’t require interaction with iTunes, which continues to amply demonstrate that Apple has yet to master setup development on Windows.)

I’ve purchased many apps since buying my iPod touch and “purchased” many more free apps. In all cases, downloading and installing those apps was painless.

Knew you’d get to installation eventually

Well, yeah. Here are my takeaways; yours might differ:

• Mobile != connected. Even though 3G coverage is decent from the major carriers, there will always be dead zones, slow zones, and underground zones.
• Rich clients + local processing power == goodness. Sure, Web 2.0 and HTML5 will finally kill the idea of running local apps. Bah. Latency, especially problematic with 3G networks, kills the user experience (see, for example, About Face and other UX books). Rich clients can largely avoid the problem.
• Sync data that lives in the cloud. If your data lives in the cloud, rich clients can sync it, keeping multiple devices up to date. In my case, I prefer to use a laptop or desktop PC to read blogs and mail when I can because, not surprisingly, a big screen is better for reading (or scanning) lots of text.
• Bulletproof installations rock. Would anyone disagree it’s better to have bullet-ridden installation?
• Making it easy to buy apps makes it easy to make money. The App Store had “over 1 billion downloads in just nine months” and “1.5 billion in First Year.” Naturally, with so many free and almost-free apps in the App Store, it doesn’t necessarily follow that we’re talking about a lot of money, depending on your definition of “a lot,” as estimates put the revenue at $2.4 billion a year. But imagine extending the App Store experience to more expensive apps, say on your PC.
• Making it easy to service apps makes it easy to keep customers happy. Servicing deliverables themselves aren’t too hard to get right but making users aware of them and getting them to the user still is. It’s led to way too many auto-start local-system updater services one vulnerability away from total system p0wnage.

Best of both worlds

One of the big reasons Web apps became so popular, for both consumers and the enterprise, is that they don’t suffer from the reliability problems common to installing client apps. Naturally, these aren’t inherent problems with client app installation but are complexities that easily turn into problems—especially without engineering attention to setup.

Web apps avoid the problem by not installing on the client. (Note that I’m skipping the complexities of setting up Web servers and the pseudo-installation provided by Silverlight and Flash.)

iPhone/iPod touch apps avoid the problem by:

• Working in a limited number of well-known environments. (Though the iPhone 3GS adds a second hardware base and there are many rumors about a so-called “Apple tablet.”)
• Working in a locked-down environment.
• Requiring a particular deployment model.
• Supporting a simple update model.
• Requiring review and approval before getting published.

These might seem pretty limiting to most Windows developers. But it’s hard to argue against the success the App Store has achieved because of—probably not in spite of—those limitations.

• Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package ATL Security Update, which contains upgrades for the Visual C++ runtime assemblies. There are three, one for each platform (x86, x64, and IA64), each under 5MB.
• Visual Studio 2008 Service Pack 1 ATL Security Update, which contains a 365MB patch for SP1.
• Wait.
• 365MB? As in megabytes?
• Oh yes.

I’m downloading this once and sharing it on my network rather than downloading it from Microsoft Update n times.

Long story short: Later this week, I join the Microsoft Application Virtualization team. App-V, as it’s known, provides an alternative to traditional setup and servicing by isolating applications inside a "virtual bubble."

For apps that fit in an App-V bubble, delivering a ready-to-run package with no "setup step" is enticing. Add in streaming updates that avoid many of the pains of patching and you can see why I’m convinced that App-V has a big future in application deployment.

Fifty degrees of separation

The App-V team is based in Cambridge, Mass. (How can you not love the New England Research & Development Center name?) Over the next few weeks I’ll be loading up my bag of holding and moving from Redmond to Cambridge. As I used to live in New England, I’m excited to live in the Boston area. It does, however, mean a change in my participation in the WiX community.

The work I routinely do for WiX will continue as before—after all, that needs only a computer and a compiler. But as Rob pointed out, the WiX virtual team has historically been Microsoft developers working together in weekly face-to-face meetings. Those weekly meetings were how volunteers kept engaged, designed features, brainstormed bug fixes, wrote code, scheduled releases, discussed the latest rumors, and generally gelled as a team. Being 3000 miles away and three time zones ahead will make it more difficult for me to participate that way. (I can either stay up really late or get up really early!)

One possibility is setting up a WiX team in miniature for those on the east coast interested in contributing. (We’ve dubbed that theoretical group "WiX East" and are already preparing for the inevitable musical turf wars.)

We’ll see how it goes, pick what works, and drop what doesn’t.

In the meantime, I’m looking forward to starting my new job with an impressive team on an exciting product. And along the way I’m sure we’ll find some interesting intersections between App-V and WiX…

[OSNews, via Coding Horror]

At WiX night, code reviews never include the phrase WTF.

Well, almost never…

My HP 2133 netbook is a great little machine. It’s small but has a keyboard that is exactly as small as it can get and still be usable. WXGA on an 8.9-inch display is tiny but perfectly readable. I even wrote most of the MSI 5.0 features in WiX using it last Thursday.

With 1GB of RAM, the 2133 runs XP just fine, so I was interested to see how well Windows 7 ran on it. I brought it into the office to do a network install but it was taking significantly longer than I had time for. (It turns out Windows 7 is popular inside Microsoft too.)

My external DVD drive wasn’t handy so I went looking for instructions on creating bootable USB installer media. I ended up here, which has instructions that were simple enough to create the image. I used a random 4GB USB flash drive, so I wasn’t expecting blazing performance.

I was surprised, however: Even on a relatively underpowered netbook, installing off USB flash media was significantly faster – and quieter! – than installing from DVD.

Green betas

Another advantage the instructions I used pointed out is that USB media is reusable. Call it eco-friendly beta testing: No more burned DVDs that need to be recycled at the end of the beta.

At the end of the installation, I have a netbook running Windows 7 beta. The beta didn’t come with drivers for the 2133′s integrated video but the Windows Vista drivers work flawlessly and are good enough to support Aero.