RobMensching.com /Blog
when setup isn't just xcopy

Back on the crystal meth... and oh so happy.

On Wednesday night over pizza and code, K mentioned that The Crystal Method had a new album out. At first I didn't believe him. How could I have missed that The Crystal Method had a new album? However, low and behold K was correct. Right on the front page of their website the new album "Legion of Boom" was out and on shelves now!

I first heard The Crystal Method after I randomly picked up their first album "Vegas" at the Fred Meyer not far from Microsoft. That was the summer I was an intern on the Windows Installer team. Now there are very few things I'll do more than once, but I swear I had that CD on repeat at work for the whole summer. You could hear "Busy Child" blaring out of my office over the Building 17 atrium every Thursday night, our team's Bug Night. That album even converted a couple of the other team members over to techno.

I did a bit of research Thursday at work and a couple reviews here and here basically told me that The Crystal Method didn't stray far from their Big Beat sound. While that seems to be a bad thing to the reviewers, I was ecstatic. So I swung by Best Buy this morning and picked up the new album (as well as a remix disc by DJ Baby Anne). After three or four full times through the album, I think "Legion of Boom" is a better album than "Tweekend" although "Vegas" still easily rules over them all.

The upswing of all this is that I now have music on my phone to listen to while chilling at the airport. For this weekend is Valentines Day weekend and I'm off to New York City to take Jenny to ice skate in Rockefeller Center and see Rent. In fact, it's time to get this blog entry posted and jump in Peter's car so we make the flight.

Oh, if you're in the Seattle area in a few weeks, The Crystal Method is playing at the Showbox on March 2nd. I'll see you there.

Have a Happy Valentines Day, and keep coding for me, I'm taking the long weekend off!

 

Inside the MSI file format, again.

Far and away the most popular blog entry I have written to date is the entry where I discussed some of the inner details of the MSI file format. I find this slightly amusing since there is so little actionable information in that blog entry. I consider the blog entries about Windows Installer Components and the Component Rules far more useful to people working with setup.

In any case, that blog entry about peeking under the hood of the MSI file also got the attention of a couple of the Windows Installer developers. The first developer was very concerned about me discussing the undocumented file format. His primary concern was that more information on the file format would encourage people to try to access MSI files in strange and unusual ways that would in turn create application compatibility issues for the Windows Installer team. You would not believe the kind of hacks that exist in the Windows Installer right now that try to work around bad application installations. For a small taste check out Raymond Chen's blog where he discusses a few of interesting application compatibility issues (not related to the Windows Installer, but should give you an idea). Ultimately, if you are working on something that depends on knowledge about undocumented features or file formats to succeed (and no, my blog does not count as documentation) then please stop right now.

The other Windows Installer developer, Carolyn, reminded me of a couple details that I had forgotten since leaving the team. I thought that errata would make for a decent follow up to what turned out to be an overly popular blog entry. Besides, just like last time, my girlfriend is once again working on her homework so I thought I'd try to be productive too.

[Note: If you haven't read my previous blog entry you should do that now.]

First, my comment about the way structured storage files became the base format for MSI files was admittedly a bit flippant. As Carolyn reminded me, the Windows Installer was originally going to ship (in 1998 or so) on three different architectures: Intel x86, Alpha axp64, and Macintosh PowerPC. Since structured storage files were a native part of the Windows 95 and NT operating systems and the Mac Office team had already ported over support for them (to interoperate with the Microsoft Office file formats) it made a lot of sense to start with structured storage files. At least somebody had already done the cross-platform testing.

Okay, so that explains the why structured storage files were chosen for the base file format, but why use a relational database format in the first place? On this point, my memory was better. Relational databases were just the "in" thing at the time. Picking a relational database file format in the mid-1990s would be kinda' like picking XML as your file format today. I have to wonder if, in five year's time, anybody will be questioning why the heck so many developers picked a verbose, text based file format for so many of their applications.

Two more things of note, then I'm going to bed. I noted that the stream names in structured storage files can only be about 63 characters long. This is technically incorrect. As per the spec, structured storage file stream and sub-storage names can only be 31 characters long (32, actually, but the last must be the null terminator so I don't count that one). The Windows Installer actually compresses the stream names to double the space available to 62 or 63 characters (plus one extra for the null terminator, but again, who's counting?). That compression is why if you open a MSI file with dfview.exe you'll see a bunch of gobbledygook names. That compression algorithm is not documented so I can't comment on it. Note, even if I could comment on the algorithm, the Windows Installer team is free to change the way they compress those names at any time since nothing about the details of the MSI file format is documented.

Finally, Carolyn pointed out that while the original version of msival.exe has been deprecated and pulled from the MSI SDK string pool validation lives on. While I hope you never need it, you can verify the string pool in your MSI file by finding msiinfo.exe and passing the "-b" and "-d" options. For those of you building MSI files, the "-d" option is particularly useful when trying to validate that you finally got the codepage correct when building your MSI file.

So there we go. A bit more information and a whole lot of validation for my previous blog entry about the inside of an MSI file. I'm sure that Jenny has given up studying and gone to sleep by now so it is time for me to follow.

Until next time.

 

"expensive install tools" vs. "less expensive install tools"

Philip asked a very good questions in a previous blog entry about the yet to be released “toolset” (he also asked a very good question about DSI which I’ll try to address later). He asked, “Will the toolset make it possible to get rid of some ‘expensive install tools’ if I don’t need their sophisticated user interfaces but want to automate all?” I thought this was a question lots of people might start asking so here’s a response “on the main page” (instead of hidden away in a comment).

You always have the option to "get rid of some 'expensive install tools'". I've seen mention of lots of small tools all over the Internet for building MSIs and, of course, you could just build your own tool to call the MSI APIs directly. The real question is what type of support do you need when the tool goes awry or the documentation is found lacking?

Those "expensive install tools" usually come with a 1-800 number (or at least an email address) to contact if you need help. There is usually some sort of contract (implicit or not) that says questions about the “expensive install tools” will be answered by the people you bought the tools from with some degree of promptness. “Less expensive install tools” also usually have an email address that you can send your questions too but there is rarely any guarantee what type of response time you will get or if you will get a response at all. So, if you are willing to spend days tracking down bugs in the "less expensive install tools" or are willing play around with the tool for a couple weeks since the documentation isn't all that clear then "less expensive install tools" may work great for you.

Oh, and those "expensive install tools" usually have some sort of quality assurance process that finds the most egregious bugs before they ever ship their tools. That’s because the company’s name and reputation is on the line. If they don’t maintain a certain quality bar across the tools they release it is unlikely the company will stay in business long. Those “less expensive install tools” are usually written by guys and gals in their free time (i.e. they don’t spend a lot of time trying to find all of their bugs) and who have different levels of commitment to maintaining their reputation via a “less expensive install tool” (i.e. if you don't like it, don't use it).

Now, personally, I like to think I have an above average quality bar and a very high commitment bar to projects that I work on. I say “above average quality bar” because bugs and regressions do slip passed me that if I was a bit more careful I would probably catch. However, my very high commitment bar means that when I find a bug later or someone else finds a bug that I missed I work very hard to kill it. Hopefully, this blog entry provides one demonstration and I am sure I will have plenty of other opportunities to demonstrate my commitment to quality when you find bugs in the “toolset”.

Now all I need to do is release this "toolset" (just one more meeting with legal, hopefully next week).

 

Gibson speaks... I relate.

This afternoon I'm running over to the research buildings to hear William Gibson speak about something. Anything. Really, I don't care, anything. Gibson is easily my favorite author since my English teacher introduced me to Neuromancer back in high school. My teacher noted that my writing style was about as dense and cryptic as Gibson’s (not exactly a compliment, but whatever).He also mentioned that I’d probably enjoy the themes in the book as well. Was he ever right (he was also right about my writing style, but whatever).

Since then I’ve read all of Gibson’s books at least twice (except the latest which I just read a couple months ago) which is quite impressive since there are very few books (or movies for that matter) that I’ll bother reading more than once. I even tried to give a nod in Gibson’s direction with a previous blog entry.

Anyway, in the invite to this lecture today that was circulated internally at Microsoft there was a link to this story about Gibson. At the bottom there is a quote from Gibson about his last talk at Microsoft (which I also attended):

“At the podium, I couldn't help but wish I had known people like this when I was 19. They would have understood me. Life wouldn't have been so hard."

I know exactly what he’s saying. High school sucked (save the time I spent reading Neuromancer for the first time).