• Aucun résultat trouvé

Why, Oh Why, Are There system.ini and win.ini Files?

Dans le document Mastering Windows XP Registry (Page 138-142)

Part II: Advanced Registry Stuff

Chapter 7: Why, Oh Why, Are There system.ini and win.ini Files?

Overview

Even with Windows XP, Microsoft's latest operating system, we still see, as a remnant dragged kicking and screaming, both system.ini and win.ini files. These files do serve a purpose (as I describe below), so we have to live with them.

Okay, so now we have a registry, and that registry was supposed to replace the system.ini and win.ini files that the first 16-bit versions of Windows were plagued with. However, some legacy applications still depend on system.ini and win.ini to run, and Microsoft has wisely retained support for these files in Windows XP.

The Evolution of System and Configuration Files

If you have been a Windows user for more than a few years, you're probably well aware of the issues that have evolved concerning the win.ini and system.ini files. These files contained almost all of the information used to configure earlier versions of Windows; other

configuration files, such as protocol.ini (no, there is no protocol.ini file in Windows XP, so don't bother trying to look for it!), were used to store network information as well. When the time to design Windows NT arrived, those wonderful software guys at Microsoft decided that there were some problems with using .ini files. Several problems were apparent:

Users would edit these files, often without regard for the consequences of making changes. Sometimes these changes were totally inadvertent.

Some editors (typically those used to doing word processing) would add, remove, or even change some characters without explicitly telling the user. An example is quotes used around strings, for which the editor would stick in stylized quotes.

The system.ini and win.ini files were growing at an alarming rate. As users added software, fonts, and system components, these files grew. The result was that the primitive search routines employed in the early versions of Windows could not efficiently search for entries in the files.

Applications were able to modify system entries in the win.ini and system.ini files with impunity. A rogue application could butcher these files and no one would be the wiser until the damage caused a failure in the operating system—no protection or security was available.

These problems with win.ini and system.ini prompted Microsoft to move to a more efficient method of storing information that both Windows and user applications could access easily and efficiently. The registry—a binary, tree-oriented database—is quick and easy to work with. Changes to existing products as they were migrated to 32-bit environments, such as Windows NT versions (including Windows 2000 and Windows XP) and Windows 95/98/Me,

presented a few problems for programmers to resolve. Moving to the registry-based model also presented a few problems for legacy applications, applications that already exist either on the user's computer(s) or as products that are being sold but will not be updated. These

problems include:

Existing 16-bit applications must be supported in executable form. That is, an

application that expects win.ini and system.ini files to exist must be able to use them.

Some 16-bit applications do not have access to registry manipulation APIs. These applications must be supported using the preexisting win.ini and system.ini files also.

Note Today, there are still many 16-bit applications being sold on the Windows platform.

This is over three years after the introduction of Windows 95, a 32-bit platform that supports 32-bit applications very well. In the foreseeable future, there will always be at least one 16-bit application being sold or used somewhere. Old habits, and old software, die hard.

To handle these problems, Microsoft decided to retain support for both win.ini and system.ini.

Windows would no longer use these files, but they would be available to any applications that chose to access or utilize them.

In this chapter, we'll look at the system.ini and win.ini files that Windows XP provides. The default files are not too large, although the win.ini file might become larger when the user installs more 16-bit applications. The system.ini file might also grow as the user adds items that are not designed to work with Windows.

When Windows applications write to the win.ini or system.ini file, and those applications use the Windows XP registry-updating APIs, the information that would have been stored in the .ini file will be stored in the registry. This is subject to the exclusions discussed next.

Any file listed in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows

NT\CurrentVersion\IniFileMapping section (that is, an .ini file or registry entries) will also be updated using the Windows XP registry-updating APIs. Windows will search the

IniFileMapping section for the application's section. If the section is found, it is used. If no application section is found, Windows will search for an .ini file to use.

Note Any application that directly opens an .ini file, perhaps using the 16-bit .ini file-processing APIs or direct file I/O, will bypass the registry file manipulation entirely.

system.ini

Located in the system.ini file are a few entries that the Windows XP Setup program supplies by default. Here is a typical, basic system.ini file:

; for 16-bit app support [drivers]

wave=mmdrv.dll timer=timer.drv

[mci]

[driver32]

[386enh]

woafont=dosapp.FON

EGA80WOA.FON=EGA80WOA.FON EGA40WOA.FON=EGA40WOA.FON CGA80WOA.FON=CGA80WOA.FON CGA40WOA.FON=CGA40WOA.FON

This file contains four sections—[drivers], [mci], [driver32], and [386enh]—and only a few entries in these sections. Entries are primarily for fonts (in the [386enh] section), as well as two drivers used with Windows XP:

mmdrv.dll A driver that is used for multimedia (sound) support timer.drv A driver that is used to provide timer support

In addition, your system.ini file may contain other entries and other sections if you are using 16-bit-incompatible applications. These applications would use the win.ini file to write application-specific information, typically in sections created for the application.

Most of the Windows XP system entries were moved from the system.ini file to the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WOW.

This key contains many entries that would be found in a Windows 3.1x installation.

Note Windows XP cannot use any 16-bit screen savers because they do not perform correctly when used in the Windows NT environment. Any entry found in the [BOOT] section of the system.ini file will never be migrated to Windows XP.

win.ini

Few entries are located in the win.ini file, except for computers that have been used for some time and have had additional software or components installed.

The default win.ini file contains four sections with no entries and two sections—[Mail] and [MAPI]—containing entries:

; for 16-bit app support [fonts]

mpe=MPEGVideo

A computer with a few more miles on it might have additional entries, like these:

[WinZip]

Note-1=This section is required only to install the optional WinZip Internet

Browser Support build 0231.

Note-2=Removing this section of the win.ini will have no effect except preventing

installation of WinZip Internet Browser Support build 0231.

win32_version=6.3-7.0 [SciCalc]

layout=0

This computer has some additional applications installed. These applications are a mixture of system components and added-on programs from a variety of sources:

Mail The entries in the [Mail] section describe the mail interface that is installed on this computer.

WinZip WinZip is an enhancement to the very popular DOS-based PKZIP program. WinZip adds both a Windows interface and the ability to handle long filenames.

The first application, Mail, is most certainly part of the 32-bit e-mail system. Why does it have entries in the win.ini file? This allows 16-bit applications to know something about the already-installed e-mail interface. Remember: 32-bit applications can use .ini files, including win.ini, although it is strongly recommended that they do not.

The win.ini system-based settings are stored in the registry in a number of subkeys. Table 7.1 shows some of these settings and their locations. This is mostly of interest to users who are using dual environments, such as Windows NT and Windows XP.

Table 7.1: Sections Found in win.ini

Section in win.ini Registry Path Description

[extensions] HKEY_CURRENT_USER\

Table 7.1: Sections Found in win.ini

Section in win.ini Registry Path Description [fontsubstitutes] HKEY_CURRENT_USER\

Software\Microsoft\Windows NT\CurrentVersion\

FontSubstitutes

Fonts used by Windows

[mci extensions.bak] HKEY_CURRENT_USER\

Software\Microsoft\Windows NT\CurrentVersion\ MCI Extensions

The Media Control Interface settings and extensions

[mci extensions] HKEY_CURRENT_USER\

Software\Microsoft\Windows NT\CurrentVersion\ MCI Extensions

The Media Control Interface settings and extensions

Some items are never migrated in a dual-environment system. These items are usually not moved to the registry either due to their complexity or for other reasons. Other items are migrated, but not used. Such items include:

[Ports], [Devices], and [PrinterPorts] that are migrated during the migration process as part of installation; these settings are not used for any purpose.

Persistent shares and users as used by Windows for Workgroups, but not Windows 3.1x.

The default domain and user ID from Windows for Workgroups or the LANMAN.ini.

Individual user profiles that are maintained by WinLogin.

Changes that users make in their copies of the Main, Startup, Games, and Accessories Program Manager groups.

MS-DOS drive letters, which are managed using the Windows Disk Administrator.

(Drive letters usually vary between Windows 3.1x, Windows 2000, and Windows XP due to how drives are detected and the possible presence of Windows 3.1x–

incompatible drive formatting, such as NTFS drives.)

Auto Arrange, Minimize on Run, and Save Settings on Exit options for Program Manager. These settings are not type compatible. (Program Manager uses strings, while Windows XP uses DWORD values for these settings.)

DOS command window font details.

Dans le document Mastering Windows XP Registry (Page 138-142)