|Who Is Online?|
|We have 149 guests online|
|Unix-style configuration files with Inno Setup|
|Source Code - Inno Setup|
|Written by Thomas|
|Saturday, 30 May 2009 16:17|
Page 1 of 3
Inno Setup is a Windows application, and therefore it is easy to create or modify Windows-style configuration files with it. Windows configuration files are sometimes referred to as ini files because of their filename extension '.ini'. Unix-style configuration files don't have section names, but that does not mean they can't be handled with Inno Setup.
Windows ini files can be created or modified with entries in Inno Setup's [Ini] section. An Inno Setup [Ini] section entry must specify a filename (the configiuration file), a section name (ini files are split up in sections), a key name (which turns up as 'key=...' in the file), and a value (everything on the right side of the '=' character). Inno Setup [Ini] section entries are basically wrappers for Windows' WritePrivateProfileString () API function.
Here's an example for a Windows configuration file (ini file):
Wikipedia explains ini files in more detail: Ini file on Wikipedia
This configuration file format has been with Windows at least since Windows 3.1, and other operating systems like OS/2 supported it too. It was the standard way of preserving settings on Windows systems before Microsoft introduced the Windows registry. Ini files are still more compact than for example XML files.
The hassle starts with software that does not use standard ini files.
More and more software for Windows has its roots on Unix/Linux. Since the ini file format is more or less native to Windows, most Unix software uses slightly different configuration files. Inno Setup does by default not support the Unix-style config file format.
The files look pretty much like Windows ini files but don't have sections. They usually only consist of configuration entries and comments:
There are several possible methods to handle Unix-style configuration files with Inno Setup, and they are all quite valuable for their purposes.
Writing an external DLL just to read and write some configuration settings for a particular file format seems overkill at first. A closer look reveals that there can very well be good reasons for this approach. For example, if a helper DLL exists already, the effort of squeezing a few more functions in to handle configurations might be worth a few lines of code.
|Last Updated on Wednesday, 03 June 2009 09:52|
You need to login or register to post comments.
Discuss this item on the forums. (0 posts)