UAC in MSI Notes: The "Saw Tooth" Diagram

This is the seventh in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries

1. Introduced...
   1. ...the UAC in MSI Notes series
   2. ...my view of the root problem
   3. ...the conflicting per-user definition
   4. ...it'll be just like Managed Installs
   5. ...the jagged edge to user
   6. ...my relief providing framework

This entry will change gears start a set of common explanations I provide to customers with UAC in MSI questions. For this specific entry, I'll talk about the "Saw Tooth" diagram I draw almost every time I explain the underlying architecture.

My Saw Tooth Diagram

When talking about UAC in MSI, I need to lay the foundation of how the Windows Installer architecture works.  Given most programmers haven't worked with the type of technology and architecture underlying the Windows Installer, I start with drawing the following diagram.

In the earlier review in trying to publish my notes, I've received feedback that this is not a customer ready diagram.  Fair feedback I said but I'm not a graphic artist and I've been able to use this as a tool to explain things in person.  I don't know that this will play to a blog any better than it played in the early review document but it's the best I've got.  I apologize in advance if I loose you here as it was suggested.

Framing the "Saw Tooth" Diagram

There are three regions of the drawing

• The Violet Region represents the client experience authored via the InstallUISequence Table.
• The Orange Region represents the service experience authored via the InstallExecuteSequence Table
• The Teal Region represents the deferred transaction script generated between the InstallInitialize Action on and InstallFinalize Action

The workflow starts in the upper left hand corner and proceeds to the lower left hand corner of the diagram.

• The first vertical segment starts from the upper left hand corner is typically the InstallUISequence. 
• The control transfer from InstallUISequence table to InstallExecuteSequence table is represented by the upward diagonal dashed line between the Violet and Orange region.  This transition is authored with the ExeuctionAction Actionn in the InstallUISequence table.
• The first vertical segment in the Orange region is the script generation process that occurs during the InstallExecuteSequence between InstallInitialize Action and InstallFinalize Action.  The tasks queued into the script is represented by the numerous dotted lines that fan out from the vertical Generate line to the vertical Script line.
• The control transfer from the generation of script to processing of script is represented by the upward diagonal dashed line between the vertical Generate and Script lines.  Generally this control transition is triggered by the InstallFinalize Action in the InstallExecuteSequence  table.
• The first vertical segment in the Teal region is install script execution.  This script is not directly written by the author rather it was generated from the data in the package.  This script is the part of the install that actually performs system changes.  Create of the rollback script that makes the Windows Installer transaction possible is represented by the horizontal dotted lines from the left to the right vertical segments in the Teal region.
• If the install fails, control is transferred from the install script to the rollback script.  This rollback script will restore the system to the state we started from.
• After script processing, control returns control back to the caller in the service which then returns control back to the client.

Did I loose you there?

If I lost you there, sorry, it's because of the gap in communication formats. 

On the whiteboard, I can look at the person's reaction to tailor down the "saw tooth" to the problem they are interested in.  If the trajectory of the customer concern was small and problem specific, I'd cut to the chase and draw the red circle in this diagram to represent their actual problem.  If the trajectory of the customer concern was broad or involved integration, I'd talk through each of these lines and their relationships to the Windows Installer architecture. 

The next set of blog entries in this series will talk to customers concerns that are small and problem specific.  If your a customer with a passion to understand more about the Windows Installer architecture, I'm trusting you'll find these instances interesting cases and hang in there until I get to the next architectural bucket.