This is similar to using the wizards in the Roles and Features applets of Server Manager, but doing it from a script or executable program.

Installing optional components is easy. OCSetup is included in the operating system and all you need to do is give it a package name

Detecting components was surprisingly less straightforward. Windows Server Core includes OCList.exe that will output a tree view of all components (very useful for viewing dependencies among components) and list their installed state. This is pretty close to what I needed but it had 2 small problems:

• OCList is currently unavailable on the non-core versions of Windows Server (it can be copied from a Server Core installation, but I prefer avoiding this kind of external dependency)
• I would have to parse the output from OCList (which I didn’t like either because it can break too easily after an OS upgrade)

I had a quick look at the OCList sources (to see if I could use the same techniques) but it was full of currently undocumented APIs (e.g., using the ICbsPackage interface). For legal reasons if I wanted to call these APIs from my code I would have to wait until they are publicly documented, which I didn’t want to do.

My lead suggested looking in WMI and after some digging I finally found the Win32_OptionalFeature WMI class that provides the info that I need and it can be scripted or accessed programmatically.

For example, listing the currently installed optional components can be done in PowerShell with:

Listing the components that are available and not yet installed can be done by comparing the InstallState to 2 (instead of 1)

Querying the state of specific components is also easy. For example, finding out if .Net 3.0 is installed would be:

and the possible results are:

• Null = Not available (or wrong name)
• 1 = Installed
• 2 = Available but not installed

The reference for WQL (WMI Query Language) is here.

If you need to write managed code or native code to do this type of WMI queries, my recommendation is to experiment with PowerShell first and then implement it in your target language once you have found the best queries.

The first thought that came to my mind is “my machine is infected”. Back in the day when I was still at the University, there were viruses that would play tricks with your text: flipping it upside down, making your sentences “rain down” (random letters start scrolling down until they disappear), showing a little ball bouncing and erasing text as it passed over it, all sort of tricks that the virus authors considered funny (of course it was rarely funny for the victim, as it typically implied losing several hours worth of work, on the other hand it was more innocent than today’s malware).

Then I looked more carefully. It was not a virus, I could select the text and paste it into notepad. Hmm, interesting. I started charmap.exe and looked for upside down letters. Sure enough there they were, letters like U+0279 Latin small letter turned r. Not all letters have turned versions but I did find enough, or I just found letters that looked sufficiently close to the reversed letter that I needed, even though semantically they were something else. For example U+0131, the small dotless latin i is a good choice for a turned i (incidentally, this is a letter that can create very interesting security bugs that are locale-dependent, but that is a story for some other time).

The next day I indulged myself in silly fun sending emails to my friends, uıʌəʞ and ןəɯɐʞ, signed as oıqəsnə

11 Languages MUI out of the box

Forefront Protection 2010 for Exchange Server 14 and RBAC

These articles summarize the end result, but the process for getting to the corresponding design is full of options and passionate discussions. I am very curious about your reactions to these features. After reading about the features and getting a little more insight about them, do you feel we made the right choices? Is it important that all these scenarios get consideration and we dedicate the necessary time and effort? Do you think that we are just wasting our time in fine points that don’t really make a difference? Would you have preferred a different solution? I will be very glad to hear your opinions (yes, even if some of them imply that I was mistaken).

Disclaimer: Your opinions and ideas are always welcome but please do not forget that the terms of service do apply.

For the pronunciation, I brought a japanese spelling toy (oshaberi machine). I'm not a native Japanese speaker and even though my accent is ok, I wanted to show accurate pronunciation, accent-free. My 2-year old daughter was protesting this morning when she saw me taking it :(

WiX (and MSI) require specifying a codepage for the project. I tried using codepage 1200 (UTF-16 LE) in my project and WiX produced error LGHT0040: Codepage "1200" is not a valid codepage.

After some digging, I found this information indicating that Unicode support in MSI is "unofficial" and seems to include only UTF-8 (65001) and UTF-7 (65000). I wonder why 1200, 1201, 12000 and 12001 are not in the list.

Anyway, 65001 is a nice number. It reminds me of the CPU where I learnt assembly programming :)

Installation began very smoothly. I didn't want to bother burning a DVD so I copied the files locally (to the 2nd hard drive), booted from a Windows PE CD, ran the installation program, selected to format the hard drive (I was running a 32-bit version of the OS previously so I had to do a clean install anyway) and let the installation proceed.

It finished copying, uncompressing, doing some configuration, rebooted, the startup screen came up and then... nothing! The screen was blank (actually the monitor went into power saving mode). In the past, I have had good success with the usual setup recovery (power off, power on and let setup detect what went wrong and then continue), but I tried it a couple of times and it didn't help this time. Safe mode wasn't useful either (I could get to a screen but I couldn't do anything because setup hadn't completed). It looked like a video driver problem, somehow the rest of the installation seemed fine but it just couldn't output to the monitor. I contacted helpdesk to see if there was a known issue but no luck.

Thinking about what could be confusing to the video driver, I decided to unplug the second monitor. I rebooted and that was it! The welcome screen came up normally, I could configure a user account, log in, plug back in the second monitor, configure it and everything was fine.

I know that we are lucky to run multiple monitors and it is not a configuration that majority of users will have however, if you're having installation problems and have a multi-monitor setup, try unplugging one of them, it may help you get past the problem.

I felt that this problem is a good example of a classic chicken-and-egg problem with setup programs: at install time some configuration items are not yet ready and related features cannot work as expected. In this case the driver was probably trying to determine which output was primary and which one was secondary but it often happens with other seemingly simple things. All those support libraries and frameworks that are extensively used at program runtime are not that simple to use from setup routines, because at the beginning they have not been configured yet.

Regardless of this issue with multi-monitor setups, I have thought for a long time that the Windows Setup was an impressive piece of engineering. I'm not just referring to the software but also to all the work "behind the scenes" with the hardware vendors. It is not easy to succeed in detecting and configuring all the huge variety of hardware as it does. The Vista installer may seem deceptively simple to many people but system-level software that is "invisible" (as in "it just works") can actually be a sign of excellence :)

<?xml version="1.0" encoding="utf-8"?>

<Wix xmlns="https://schemas.microsoft.com/wix/2003/01/wi">

<Product

         …(attributes)...

>

<Package

…(attributes)...

/>

<?include Media.wxs>

<?include Property.wxs?>

<?include Directory.wxs?>

</Product>

</Wix>

Directory.wxs is going to be too big if I put everything in a single file so in turn I will use one file that nests the others, with a structure like this:

<?xml version="1.0" encoding="utf-8"?>

<Include xmlns="https://schemas.microsoft.com/wix/2003/01/wi">

<!--Root of Directory/Component/File Table-->

<!--This file only contains the entries for the root folders-->

<!--The actual contents of each folder are ?include?d -->

<Directory

…(attributes)...

>

<Directory

…(attributes)...

>

<?include Dir1.wxs?>

</Directory>

<Directory

…(attributes)...

>

<?include Dir2.wxs?>

</Directory>

...

</Directory>

</Include>

Each ?include?d Directory would corresponds to a root folder in the "old" Installscript-based project.

If I were writing C/C++ I would certainly not create a file that #includes every file in the project. I'm probably overusing ?include? and I should look into producing separate object files instead, but I'll leave that for another day.

On other news, our product was part of today's Ready for a New Day announcement. Yeah!

Thinking about why I was concerned with churn, my favorite Open Source project used to be Debian and I used to run the unstable version. It was a lot of fun to play with and my interest on the issues related to installer packages owes much to them ':) however, it did change very, very often and is not something I'd suggest for production. The stable version was meant for that but then the updates were too slow for my liking. In fairness, I've read that they have improved in the past few years but I haven't used it for a while.

I am now creating a "staging" area, a local folder that mirrors the folder structure as it will be installed on the target machine. It is not strictly necessary but I find it makes it easier to troubleshoot certain problems. We use Binplace for generating symbols, and  the "class" in the place file provides a convenient way for specifying the target path under the root of the output folders. If taking advantage of the binplace step sounds too complicated, you may be right, a simple batch file containing a few copy commands could do the job. On a large project however, it is very easy to end up with a long build process. Skipping unnecessary massive file copying does help in making that shorter.

The first decision is what tool to use. Because of the Installscript heritage in our installer, Installshield is one candidate. Other choice being considered is WiX, the project led by Rob Mensching. A third choice is scripting the Windows Installer API directly. Something important to mention is that choosing one doesn't necessarily exclude the others, we want to find out what we can get from each tool. If the most effective solution is combining them, that is a good choice too (as long as it is cost effective, but the Windows Installer API and WiX are free and we already have Installshield licenses, so it is easy to make the case)

For evaluating the tools, I already have experience with MSI-based Installshield projects, a fresh look from another team member will be more effective. I will focus on WiX myself.

Regarding WiX, the question in front of me at this time is: what version of WiX? We want to target MSI 4.0 so it should be WiX 3.x but, are all 3.x sufficiently stable for production? Where to find info on which versions are "good"? For individual development, the typical "get the latest and then upgrade" may be a good solution but one internal goal we'd like to achieve is that tools required for building  should be checked in the source control tree. I don't want to be upgrading often and causing a lot of churn.

How good is the WiX project with regards to the balance between "stability" and "release often"? That is what I have to find out.

[edited: Corrected Rob's name]