#$+KValidation of Target Directories
As a part of the CostFinalize action, all target directories (as authored in the Directory table) are validated to ensure that each represents a writable location. If there is any target directory for which the Installer does not have write-access, a substitute location must be selected by the user if the install is to continue.  If the author wishes to accommodate this (highly recommended), do the following: 
1) Author a Browse dialog (a special dialog type that allows the user to specify a directory location).  The name of this dialog must be "BrowseDialog" (i.e. this name must be specified in the "Dialog" column of the Dialog table).
2) The name of the directory property that is to be modified by this Browse dialog must be "_BrowseProperty" (see the Browse dialog topic to determine how to author this property name).
If an unwritable target directory is located during the above-mentioned validation, AND a Browse dialog as specified above is available, the CostFinalize action will display that dialog, prompting the user to select an alternate location for the directory.  However, also note that only those directories that are authored as "configurable" (i.e. that directory's property name is specified in the "Directory_" column of any row in the Feature table) can result in a Browse dialog.  If any unwritable directory is non-configurable, an error will eventually result if and when the Installer attempts to write a file to that directory.
#$+KReinstalling and Removing Installed Features
There are several ways of reinstalling and removing features once they have been installed.  A reinstall might be required if any files or registry entries associated with any feature have become corrupted or are missing for any reason.  And of course at any time, the user might want or need to remove a particular feature, or the whole product.

Reinstalling Features
Once an installation for a particular product has been performed once (with some or all of the product's features installed), one way to perform a reinstallation is to specify the REINSTALL and REINSTALLMODE properties on the command line.  These properties allow the user to reinstall any or all of the product's features.  In addition, the 'type' of reinstallation can be specified; for instance, you could specify that only those files that are totally missing should be reinstalled, or that only corrupted files (i.e. any executable file whose checksum doesn't match the actual file contents) be replaced.  Alternatively, you could specify that the fitness of the current install be only verified, without actually repairing any broken or missing files/registry entries.  In this case, for all installed features, the Installer would report (typically in a log file) the results of any verification that you specify, such as whether there are any missing or corrupt files,  any files of the wrong version, or any missing or incorrect registry entries.  At any later time, you could then run the install again to repair any or all of the detected problems. 
 A reinstall can also authored to be performed via the Installer user interface, at the click of a button.  To add a "Reinstall" button to any dialog, follow these steps:
 
1) Add a pushbutton to the desired dialog by adding an entry to the Control table.
2) Add a "ReinstallMode" event to the ControlEvent table, with the "Dialog_" and "Control_" fields referencing the pushbutton control you created in step 1.  In the "Argument" field, enter a string containing the letters corresponding to the reinstall mode(s) you want (the acceptable values for this field are identical to those accepted for the REINSTALLMODE property).  The value in the "Ordering" column for this event should be "1".
3) Add a "Reinstall" event to the ControlEvent table, again referencing the same pushbutton control.  The  "Argument" field for this event will normally be "ALL", to force the reinstall of all features, but you could place the name of a specific feature here.  The value in the "Ordering" column for this event should be "2".
4) Finally, add one more event tied to the same pushbutton control, to actually initiate the reinstallation. This could be an "EndDialog" dialog event (with an argument of "Return"), but more typically a "NewDialog" event would be used here, to jump to an "Are you sure you want to reinstall?" confirmation dialog.  The value in the "Ordering" column for this event should be "3".

If desired, several "Reinstall" buttons can be provided on one dialog, to give the user the option of selecting the type of reinstall to perform.  In this case, each button would be authored as outlined in the above steps, with only the argument provided for the "ReinstallMode" control event being different for each button.
Removing Features
To remove any or all features, you can specify the REMOVE property on the command line. Alternatively, as with a reinstall, a removal of the entire product can be authored to be performed via the Installer user interface, with one button.  To add a "Remove All" button to any dialog, follow these steps:

1) Add a pushbutton to the desired dialog by adding an entry to the Control table.
2) Add a "Remove" event to the ControlEvent table, with the "Dialog_" and "Control_" fields referencing the pushbutton control you created in step 1.  The "Argument" field for this event will normally be "ALL", to force the removal of all features, although could place the name of a specific feature here.  The value in the "Ordering" column for this event should be "1".
4) Add another event tied to the same pushbutton control, to actually initiate the removal. This could be an "EndDialog" dialog event (with an argument of "Return"), but more typically a "NewDialog" event would be used here, to jump to an "Are you sure you want to remove the entire product?" confirmation dialog.  The value in the "Ordering" column for this event should be "2".

#$+KDarwin Advertisement
Advertisement is the mechanism in Darwin whereby information about the product and discretely installable features of the product are provided to the system, without actually installing the features. Advertisement in Darwin is initiated by the ADVERTISE action.
The information regarding the feature is provided by specifying a Darwin Descriptor. The Darwin Descriptor holds product, feature and the Key Component information that is used for installing the components that are required. The key component is the component of the feature whose KeyPath (see Component ) is the entry into using the feature.
The following information is advertised by Darwin:
1. The feature to components mapping.
This is the information that enumerates the individual components of a feature of a product. Whenever a feature is requested to be made available by the application or the system using   the Installer API, the system ensures that all the components composing the feature are installed.
Registry structure for the information -
Tables queried - FeatureComponents
2. Any component that needs to be available for use across processes via the MsiProvideComponentIndirect API.
Tables queried - PublishComponent
3. COM Servers.
This is the information regarding COM servers. The system faults in a COM server on request using the darwin descriptor that represents the COM server.

Registry structure for the information -
HKCR\CLSID\<Class.Context> default=<Class.Description> (created if Class.Description not null)
HKCR\CLSID\<Class.Context> <Class.Context>=<darwindescriptor for Class.Feature_, Class.Component_>
HKCR\CLSID\<Class.Context>\ProgID default=<Class.ProgId> (created if Class.ProgId not null)
HKCR\<Class.ProgId> default=<Class.Description> (created if Class.ProgId not null)
HKCR\CLSID\<Class.Context>\Insertable default="" (created if Class.Insertable not null)
HKCR\CLSID\<Class.Context>\InprocHandler32 default=<server-name> (depends on Class.DefInprocHandler).
HKCR\CLSID\<Class.Context>\DefaultIcon default=<full path to Class.Icon > (created if Class.Icon_ not null).
HKCR\FileType\<Class.Context>\1 default=type mask 1
HKCR\FileType\<Class.Context>\2 default=type mask 2
HKCR\FileType\<Class.Context>\3 default=type mask 2
...
...
...
when Class.FileTypeMask is a non null ";" delimited list of type masks.
Tables queried - Class

4. COM Type Libraries.
This is the information regarding COM type libraries. This is used by the system to allow the user to browse installable type libraries. The system faults in a COM type library on request using the darwin descriptor that represents the COM type library.
Registry structure for the information -
HKCR\TypeLib\<TypeLib.LibID>\<TypeLib.Version> default=TypeLib.Description
HKCR\TypeLib\<TypeLib.LibID>\<TypeLib.Version>\<Locale ID from TypeLib.Language>\win32 win32=<darwindescriptor for TypeLib.Feature_, TypeLib.Component_>
Tables queried - TypeLib
5. Extension servers.
This is the information regarding extension servers. This is used by the system to default in servers using the darwin descriptor for opening/editing/printing documents by file extension.
Registry structure for the information -
HKCR\<Extension.Extension>\<Extension.ProgId> default = ""
HKCR\<Extension.Extension>\<Extension.ProgId>\ShellNew <Extension.ShellNew>=<Extension.ShellNewValue>
HKCR\<Extension.ProgId>\shell\<Verb.Verb> default=<Verb.Command>
HKCR\<Extension.ProgId>\shell\<Verb.Verb>\command command=<darwindescriptor for Extension.Feature_, Extension.Component_> <Verb.Arguments>
when Extension.ProgId not null - else
HKCR\<Extension.Extension> default = ""
HKCR\<Extension.Extension>\ShellNew <Extension.ShellNew>=<Extension.ShellNewValue>
HKCR\<Extension.Extension>\shell\<Verb.Verb> default=<Verb.Command>
HKCR\<Extension.Extension>\shell\<Verb.Verb>\command command=<darwindescriptor for Extension.Feature_, Extension.Component_> <Verb.Arguments>
Tables queried - Extension, Verb
6. MIME information.
This is the MIME information placed in the registry.
Registry structure for the information -
HKCR\MIME\Database\Content Type\<MIME.ContentType> default=""
HKCR\MIME\Database\Content Type\<MIME.ContentType> Extension=<MIME.Extension>
HKCR\MIME\Database\Content Type\<MIME.ContentType> CLSID=<MIME.CLSID> (if MIME.CLSID is not null)
HKCR\Extension Content Type=<MIME.ContentType>
Tables queried - MIME
7. Shortcuts under Shell Folders.
Darwin creates shortcuts under Shell Folders, containing the darwin descriptor that represents the application. The system installs the application referred to by the darwin descriptor when the user clicks on the shortcut.
Tables queried - Shortcut
NOTE: This is the only advertisement entity that needs to be created only if there is GPT support on the system. (Else we do not advertise and use the filename in place of the Darwin Descriptor at installation time).Currently we determine "GPTSupport" by detecting the presence of the HKCR\GPTSupport key.
8. Icons under the <userprofile directory> folder for the shortcuts and the COM servers that are advertised.
Tables queried - Icon

Explicit advertisement occurs on a system when - 
1. The installer is activated with the ACTION property set to ADVERTISE.
2. Through the MsiAdvertiseProduct API with the scriptfile argument set to null.
3. Through the MsiAdvertiseScript or the MsiProcessAdvertiseScript API with the scriptfile argument set to to script file generated by the MsiAdvertiseProduct API.
NOTE:Since these APIs return the key file of the component referred to in the Darwin Descriptor, any file that is  pointed to by a shortcut, or is a COM server, an extension server, or a type library is to be the key file of a component. In other words no two such files can share the same component.
Darwin removes any advertised information for a feature during the uninstall of the feature. This implies that the feature then cannot be faulted in by the system. However on a ZAW enabled client this is pushed back onto the client via the advertise script.

#$+KDarwin Components
A Darwin component is a set of files, shorcuts, .ini entries, registry entries and other installable entities and associated Darwin actions to be performed on the installation/ uninstallation of the set. A Darwin component has a globally unique id, Component.ComponentId (see Component table). Two components (from two different products) may have the same ComponentId only if they have the same set of files and other installable entities with the same set of associated Darwin actions to be performed on the installation/ uninstallation of the set. Using the same ComponentId implies that the products share the component as regards installation, uninstallation and application usage. The objective here is to use a single install that is shared by more than one product. The abovementioned restrictions ensure that a component installed by one product can be shared by another product and uninstalled, if it is the last client of that component. The file versions between different installs of the same product may be different. In this case the file copy logic will kick in when installing a component over an existing installation. Also a component is associated with one and only one directory. i.e. all the files of a component go to the same folder.
Each component has a KeyPath (see Component table) associated with it. This is the file or folder that represents the component. The KeyPath serves two purposes. First, it is used to determine the presence of the component in the MSI APIs. If it is a folder it is also used as the key file for the component. This is what is passed back to the user in the MsiLocateComponent, MsiLocateLanguageComponent, MsiProvideComponent, MsiProvideComponentFromDescriptor, and MsiProvideComponentIndirect MSI APIs.
Management of Components 
Here are the set of rules that govern the management of components by Darwin:
1. Each installed component has a key path registered with it. The component is in the installed state if it is registered with the configuration manager and its key path exists (the configuration manager physically checks for the existence of the file/ folder that is the key path). 
2. Each installed component has a set of clients registered with it. These are the products that wished the component to be installed. Additionally we associate the state (local/ source) that the client wished the state to the component to be.
3. A component can be installed only at one location on the system. This restriction is because products today register hard coded path references to the component in the registry, shortcuts, etc.
4. If a product is not as yet a client of the component and wishes to install the component locally we always install (there is no existing install, there is an existing source install, there is an existing local install). If there is a local install we set the directory of install to be the same as the existing local install.
5. If a product is not as yet a client of the component and wishes to install the component as run from source we install only if there is no valid local install. In this case we always install (there is no existing install, there is an existing source install, there is an existing local install). If there is a local install we set the directory of install to be the same as the existing local install.
6. A local installation is uninstalled when the last local client wishes it to be uninstalled. This will leave the component in an invalid state for any clients that wished the component as run from source.
7. If a product is a client of the component and the installation is not valid we (silently) reinstall the component in the desired state when Darwin runs (either explicitely during maintenance or implicitely through the APIs) in the context of that product.
Component Redirection
Components can register that the configuration manager redirect requests for one or more other component to them. This is done by use of the RedirectComponent table. All requests for the older component(s) through the MSI API will be redirected to the newer component. However the clients of the older components cannot prevent the newer component from going away when its last client uninstalls it.  When this happens the older redirected component appear "broken" and are reinstalled as per rule 7. above.
Component Publishing and Qualified Components
Products can publish "component factories" by advertising the Darwin Descriptors for installing components. This is done by using the PublishComponent table (see Advertisement). Products can use the MsiProvideComponentIndirect API to get these components.
Also there may be another level of heirarchy (further qualification) between the GUID and the Darwin Descriptor.This is the  to be used with a generic GUID to get a specific Darwin Descriptors.
#$+KManaging proofing tools using Darwin
Proofing tools is a term applied to a set of tools such as the speller and the thesaurus which can be characterised as having a pair of files that serve the task. The first file is the lex file. It is the data file for the tool. The second file is the engine file which provides the tool function and is driven by the lex file. Proofing tools are catagorised by their function, sub-type and language (example - a dictionary of the sub-type medical and language english).
Darwin manages proofing tools by use of the Qualified Components mechanism (see Darwin Components). Each (type of) proofing tool is associated with a universally recognised GUID. So Spelling will have its own GUID separate from the thesaurus. All the speller lex files will hang off this GUID. The proofing tools subtype and language will form the Qualifier. Thus the Qualifier may be - "1033-Medical". The Darwin Descriptor associated with the Qualifier will be the feature that denotes the proofing tool (lex + engine components). The component passed back by the Darwin Descriptor will be the lex component.
Similarly each (type of) proofing tool engine is associated with a universally recognised GUID. So Spelling will have its own GUID separate from the thesaurus. All the speller engine files will hang off this GUID. The proofing tools subtype and language will form the Qualifier. Thus the Qualifier may be - "1033-Medical". The Darwin Descriptor associated with the Qualifier will be the feature that denotes the proofing tool (lex + engine components). The component passed back by the Darwin Descriptor will be the engine component.
When an application wants a particular proofing tool it will ask Darwin to provide the lex file and the engine for the proofing tools by calling MsiProvideComponentIndirect for both the engine and the corresponding lex file.