Classic Computer Magazine Archive COMPUTE! ISSUE 147 / DECEMBER 1992 / PAGE 64

Init files and extra memory. (initialization files) (Programming Power) (Column)
by Tom Campbell

If you've ever used Windows, you may have noticed several text files that end with the extension ini in your Windows directories. These are simply text files with the following appearance: [SectionName] EntryName=AddString.

Initialization files, usually called init files, let an application know how to select variables on startup. Say you have an application that needs to DIM an array at startup. The more you DIM, the more memory is used before the program even starts. The less you DIM, the poorer performance becomes on a high-ram machine because there's extra memory lying around with no way for you to get at it. The fix is to DIM that array with a variable at startup and to have your program read that value from an init file.

Here's the format of an init file. The text in brackets is called a section. The variable name on the left is called an entry. The value on the right can be changed. It's like assigning to a variable in BASIC: PI=3.14159.

Windows has a routine called WriteProfileString that automatically updates an entry in win.ini and that used to be the preferred place to put your application's configuration variables. Reading a configuration value, which was a text file, meant reading every line of the file until the preferred section and entry could be found. Predictably, system performance on networks and on hard disks of users with lots of programs slowed to a crawl whenever a program started because win. ini could be thousands of lines long.

Beginning with Windows 3.0, Microsoft came to its senses and added the API call WritePrivateProfileString, which takes a filename, a section, an entry, and the string to write to the entry. This column presents a BASIC version of that routine.

WritePrivateProfileString is complicated. If the init file doesn't exist, it's created. That's pretty easy. The tough part is changing the value in an init file and section that already exist, because it requires that these laborious steps be taken: Create a temporary file. Read in each line of the existing init file. If it's not the entry in question, copy the line out to a temporary file. When the entry is found, write out the new value instead of the old one. Copy the rest of the init file to the temporary file. Delete the old file. Then rename the temporary to the name of the old file. And this assumes no errors occur! The working code is even more complicated because it accounts for errors every step of the way and because of the deceptively simple phrase create a temporary file.

Like Windows, this routine first checks for the existence of a temp environment variable, which specifies the drive and directory Windows and some other Microsoft applications use for temporary files. It also checks for tmp, which some other applications create. Since it's possible that neither environment variable has been defined, the routine must check for a hard disk. Then a unique filename is created. It's based on the system time, so it's unlikely that such a file already exists (the function fails if so; call it again in a loop because the time will have changed later). The routine is then appended to the temporary drive and path already created. All of these create a mother lode for you; in all, 12 spanking new routines were necessary for the creation of WritePrivateProfileString!

This Month's Routines

FileExists% Returns nonzero value if the specified file is present or 0 if the file can't be found.

FindFirst% Returns information about the specified file such as size, attributes, and time of creation. If a wildcard specification (like *.txt) is used, it returns information on the first matching file. FindNext is used for each remaining file.

FindNext% Returns information about files matching a wildcard specification such as *.txt. Must be preceded by FindFirst.

GetCurrDir$ Returns the current working directory.

GetCurrDrive$ Returns the currently logged drive.

GetTempDir Returns the name of the temporary directory by checking the temp environment variable.

GetTempDrive (based on Windows routine of the same name) Selects the system hard disk if the parameter is 0 or the letter of the next available hard drive.

GetTempFilename (based on Windows routine of the same name) Calls DOS to determine the name of a file guaranteed to be unique.

IsAlphas% Returns nonzero value if the specified string consists only of letters or 0 if there are characters other than letters.

IsDigits% Returns nonzero value if the specified string consists only of digits or 0 if there are characters other than digits.

NumHardDisks% Returns the number of hard disks installed on the system.

SplitFilename Breaks the input filename into drive, directory, name, and extension.

WritePrivateProfileString% Changes an entry in the specified init file if it exists or creates the file, section, and entry if it does not exist.