Saturday, February 9, 2008

MSI's

Understanding that my work this semester has only been a compilation of documentation, I sat down this week trying to produce some tangible build. Here are some of the problems I'm facing as of right now. I've completed my research, I know how to push a build of Firefox over a network using a .msi file. As of recently I was able to use a .adm file to customize *some* features of the .msi install as well.

The only next thing to do is to create a tool that automates the whole process. A tool like Microsoft's IEAK that allows server admins to create a .MSI file based on fields they enter.

Thinking this was an easy task I began to install Microsoft's SDK kit for installers. Inside there is a tool called Orca. Orca is used to dissect and display the tables inside a .msi file. I decided that I would use Orca to take a peak inside the .msi file from FrontMotion. Inside I found a crazy mess of tables, some registry keys, some directory pointers and some I had no idea about. That is when I realized the true complexity of .msi files. They don't simply execute commands like a .exe, they have tables that indicate registry entries and pointers to directories to install files.

I've spend over eight hours this week trying to figure out this mess and still have very little to show for it. I was able to edit some fields in Frontmotion's .msi and I will be posting it on the wiki. I am hoping that my work will not be wasted and that by documenting this process I might be able to help someone else out that wants to attempt this task.

Pictures posted. 1) My simulated server environment



2) A screenshot of my work with Orca

1 comment:

Unknown said...

MSIs are databases which get read and used by the MS installer tools. The best way to generate one is to use WiX, which is the tool MS uses to create their MSIs, and it's also open source. You can find automated tools (e.g., IDEs) for working with WiX online. Also, you'll note that the bug on MSIs refers to WiX.