-The Installation Builder
-The Installation Application
-The Installation File
The Installation Builder
The Installation Builder application is the tool used by the author of an installation package to build the Installation for deployment. Using this tool, the user can choose the platforms they wish to target, build the dictionary of files for each platform, create the initial settings (if they so choose - some programmers seem to prefer to allow the application itself to create the initial settings on first execution).
This application is currently being written in Java.
The Installation Application
The Installation Application is program the end user will have to install on their computer in order to run the installation files. While the general base for each platform will be the same, different platforms will require forks on certain aspects of the application due to different architecture.
This application is responsible for translating the data sent in the installation file into a working application on the end users computer. This includes decompressing the file data, writing the setting values to the system, registering the application with the system. It also creates the interface that the user uses to install the application, if applicable (silent installations use default data and do not prompt the user at all).
These applications will be written in C++, and will be offered with the Installation Builder application to developers.
The Installation File
The format of the Installation File borrows heavily in someways from the Linux RPM and DEB formats, although there are some key differences.
The Installation File is broken into two seperate components:
The Image file is the file that contains all the data regarding the application. The Installer file is a wrapper that sits around the Image file. There may be multiple Image files in an Installer file, allowing developers to bundle additional applications that the core, installed application may be dependant on. All Installers will contain at least one Image.
The reasoning for seperating Image and Installer, is that having a standalone Image format allows for the simple packaging and deployment of third party components within the same installation process, saving on the overhead of having to start a secondary process to install required dependencies, or optional secondary applications.
Both Installer and Image files are simply archive files in the 7z format. The default compression method used to compact the data inside the files the LZMA algorithm, though another supported method may be chosen if preferred.
The dictionaries for both file types are in XML format, and hold all the information relating to the product, files, platform specific options, custom settings, contact details, etc.
The Installer File Structure
At the root of the archive is the dictionary.xml file.
Inside in the archive is a single folder called "images". Inside here the Image file(s) are kept.
The Image File Structure
Identical to the Installer File, at the root of the archive is the dictionary.xml file.
Inside the archive is a single folder called "files". In here is where the compressed files belonging to the application are kept.
As I still have some things I want to sort out about the XML file structure (mainly on the Installer side at the minute), I'm not going to go into too much detail about that yet. I can, however, show you a peek at an example Image dictionary I have been messing about with. Its not complete yet, and it will change, but here is the current version anyway. I know its still a little [sic] messy, especially in the file entry.
"" version="" uuid="">
"Test resource" version="x.y" />
"" location="" value="" />
"" location="" length="" hashcode="" uuid="">
"" hive="" key="" valuename="" value="" delete="" />