Deciphering the MSI Directory table, part 2.

  • 發行項

Last time I left off with a quick story about how I first got started with the Directory table as an intern on the Windows Installer. I suppose that blog entry was really more of a teaser than a real story and it was certainly light on technical details. So, let's pick up with some of the data that I scrounged together before sitting down in Ben's office.

Here's an example of the simplest (non-empty) Directory.idt file that I could find as an intern:

 
Directory       Directory_Parent      DefaultDir
s72             S72                   l255
Directory       Directory
TARGETDIR                             SourceDir

First, let's decipher all of the data provided so far. This is an IDT file (a text file form of an MSI table, intended for use as an archival mechanism). IDT files have a very particular format. On the first line, we have the names of each of the columns separated by tabs. Thus this table has three columns called Directory, Directory_Parent, and DefaultDir. Easy enough but there is a lot of contextual data stored in those names that I'll revisit later.

The second line contains the data definitions for each of the columns. The letters specify that data type; "s" is string, "l" is localizable string, "i" is numeric and "v" is data stream. The numbers specify the size of the column which hopefully is self-explanatory, except that 0 means "unbounded". Finally, the case of the letter specifies whether the column is nullable or not; lowercase letters mean not nullable and uppercase letters mean nullable. In this case, only the Directory_Parent column is nullable.

The third line first specifies the name of the table (finally, we know this is the "Directory" table). The rest of the strings specify the primary keys of the table. Thus our Directory table has only one primary key column which happens to be the Directory column. If you are database illiterate like I was as an intern then know that the primary key columns in a database serve two roles. First, the data in the primary key columns of every row of a table must be unique. Second, primary key columns can be referenced from other columns (they are called foreign keys) in different tables or even the same table. If you stop and think about it the fact that primary keys are unique makes them perfect identities to be referenced by other columns. I explicitly remember the night that connection connected in my head.

I thought I was so smart. I obviously had so much to learn.

[to be continued]

Comments

  • Anonymous
    June 27, 2005
    Rob,

    A while ago you mentioned you were going to use Monday nights for to blog. I remember thinking that you must have been having problems keeping up with that idea as not much materialised. It looks like you're getting there now though ;-)

    Personally, I find the shorter blogs, more often, a good idea. This one I feel was better (from a readers perspective) than the last, as it had some tech "meat" in it. I'm sure as you keep going you'll find a good balance!

    I didn't know too much about databases before playing with MSI, it's also the reason I learnt VBS.

    Glad we don't have to spend too much time with IDT's these days though <g>.

    Looking forwards to the next installment next week mate!

    Cheers

    Adam
  • Anonymous
    June 28, 2005
    Oh the agony of waiting. Keep it coming Rob! Glad to see you're getting a chance for more blogging.

    And wait til I tell the WiX skeptics here at work that you're the guy who wrote Orca. They love that tool already (and HATE W*** for Windows Installer)!

    - DMac
  • Anonymous
    June 28, 2005
    Yeah, Adam, I thought I could make "Monday nights" work but so many of those nights I would sit down and start a blog entry but not quite finish it. Now I have several partial blog entries that are structured to be 10 to 12 paragraphs each. That just wasn't working. So last week in the middle of this craziness at work, I decided to just write as much as I felt like writing then post it. That was fun and relaxing at the same time.

    So this is working far better for me. Even last night, I wrote these paragraphs and started the "next" paragraph. Suddenly, I realized that it was going to take me three or four more paragraphs to finish that and I wasn't prepared for that (I started writing about 23:00 to begin with).

    So I stopped and posted what I had. Again it was a really good feeling. Of course, I realize I haven't quite touched on anything that is specifically about the Directory table but we're getting there. <grin/>

    Personally, I think it is important to frame the content with history so that you can understand where it all came from. That is really what I want this blog to be about... telling the story about why things came to be the way they are.
  • Anonymous
    June 28, 2005
    DMac, tell your skeptics that the WiX toolset is just getting started publicly. I recently posted a proposal for the WiX toolset "Roadmap" a couple weeks ago to the wix-users at lists.sourceforge.net. We have a lot of cool stuff on the horizon.

    And I'll keep the blogs coming... even if I disappear for a while I'll be back eventually. <smile/>
  • Anonymous
    June 29, 2005
    I like this post much better than the previous. It gave me some facts to chew on and while it left me hanging, I have some things to mull over before the next post. :-)

    To all the WiX skeptics, I am an employee of one the software companies that makes one of the more popular tools for installation dev and packaging and I love WiX.

    WiX is great if you're not ig'nant. I kid, I kid!!
  • Anonymous
    June 30, 2005
    I can't believe you didn't even have some basic relational database knowledge when you started at Microsoft. They taught that stuff in my first year at Computing Science. Was it that easy to get an internship?

    Anyway, nice blog. Waiting for the next one... ;-)
  • Anonymous
    June 30, 2005
    Leon, at my university the database classes were a 3rd/4th year thing and I had my internship before then. Actually, I took the database course the semester after I finished at Microsoft and the class was terribly boring because of my time on the MSI team.

    Also, good entry level interviews don't test the candidates knowledge of a specialized domain (like databases, or networking, or graphics) but their ability to learn a specialized domain. Hopefully, when I reach the end of this story, I will have demonstrated why it wasn't a complete mistake to hire me as an intern when I didn't know anything about databases. <smile/>
  • Anonymous
    June 30, 2005
    I must admit that you thoroughly rule. WiX is great stuff, and this blog is truly a haven for those of us without true installation peers at our own companies.

    I learn a little something new just about every time I come back to this blog. Thanks.
  • Anonymous
    July 01, 2005
    I was just joking, Rob <BigSmile />
  • Anonymous
    July 03, 2005
    A possible future topic related to the directory table:

    A co-worker asked me once, why can't an MSI install a file from some directory tree above the folder that contains the MSI? Example:
    X:programsmyappsetup.msi
    Why can't that MSI install a file that is stored under X:programsanotherappfoofoo.dat

    All I could say was it wasn't supported. Why wasn’t the directory table designed to accommodate this? A type 35 CA wouldn’t solve this as it sets the target path, but doesn’t change the source path. Or is there a way to do this?

    Thank you.
  • Anonymous
    July 04, 2005
    Imagine a blog entry where I talk about the table conventions demonstrated by the Directory table.
  • Anonymous
    July 04, 2005
    Mike, I will definitely cover that topic soon. If I forget, drop me another comment to remind me and I'll put that topic right on top of my queue.
  • Anonymous
    September 18, 2005
    .. ping ..

    Rob, is your series of posts on the Directory table complete? Maybe I missed it, but did you cover the scenario/question I had in an comment above?