Файлы system.ini и win.ini: назначение, структура, описание разделов

Раздел [mci]. MCI обозначает Media Control Interface (интерфейс управления носителями информации). Это название дано набору функций внутри Windows, которые обобщают интерфейс между программами и аппаратурой мультимедиа. Например, для воспроизведения дорожки на аудиоCD, прикладная программа DOS должна произвести обращение на очень низком уровне, анализируя содержание CD и посылая загадочные (и не всегда документированные) команды драйверу устройства, который управляет накопителем CD-ROM. В то же время прикладная программа Windows, может вызвать MCI-команду, которая даст указания накопителю начать воспроизведение определенной дорожки. Более того, одна и та же MCI-команда воспроизведения работает с разнообразными устройствами от накопителей CD-ROM до проигрывателей видеодисков. Прикладные программы мультимедиа, основанные на MCI, способны работать с несколькими устройствами почти столь же легко, как и с одним.

В разделе [mci] файла SYSTEM.INI перечисляются драйверы, которые обеспечивают возможности MCI для разнообразных устройств мультимедиа. Строка CDAudio, например, определяет драйвер (обычно MCICDA.DRV), который обеспечивает возможность работы через MCI с аудиоCD в накопителях CD-ROM. AVIVideo идентифицирует драйвер AVI-видео. Число и тип записей, размещенных в этом разделе, зависит от того, какие устройства мультимедиа и драйверы установлены. Не изменяйте эти строки самостоятельно. За вас об этом позаботится модуль Drivers (Драйверы) в модуле Control Panel.

Раздел [NonWindowsApp]. Здесь Windows хранит глобальные параметры для прикладных программ DOS. Три из наиболее интересных параметров — это CommandEnvSize, устанавливающий размер контекста среды для DOS-программ; LocalTSRs, идентифицирующий резидентные программы (TSR), которые требуют специальных операций, и ScreenLines, определяющий число строк, отображаемых на экране для DOS-программ текстового режима. Если вы хотите поменять любой из параметров этого раздела, вам придется сделать это самостоятельно. Ни Windows Setup, ни Control Panel не обеспечивают автоматизированного управления записями в разделе [NonWindowsApp].

CommandEnvSize служит для увеличения контекстной области среды, доступной для командных файлов. Если вы запускаете командный файл под управлением Windows и получаете сообщение об ошибке, указывающее на недостаточный размер параметра среды, одним из решений будет добавление оператора CommandEnvSize, увеличивающего размер среды, в файл SYSTEM.INI. Если директива SHELL в CONFIG.SYS изначально устанавливала размер параметра среды 256 байт, можно, например, добавить предложение CommandEnvSize=512 в файл SYSTEM.INI.

Директиву LocalTSRs применяйте в случаях, когда до запуска Windows вы загружаете резидентные программы для раздельной обработки информации каждой виртуальной машиной (VM). Windows выполняет свои прикладные программы на одной VM, а прикладные программы DOS на отдельных — по одной на каждую программу. По умолчанию, TSR-программы, загруженные до запуска Windows, используются сразу всеми активными VM. При использовании некоторых утилит, таких, как редакторы командной строки, это может приводить к возникновению проблем и даже к аварийным отказам системы.

Если добавить имя файла  резидентной программы (без расширения) в список LocalTSRs, Windows будет загружать отдельную копию, или экземпляр, этой TSR-программы для каждой VM. В итоге, если резидентная программа представляет собой редактор командной строки, фиксирующий введенные команды, с тем чтобы позднее их можно было вызвать еще раз, набранное в одном окне DOS не повлияет на то, что набирается в другом. Каждый экземпляр программы будет обрабатывать свою собственную независимую копию набранных команд. Если ваша любимая резидентная программа не работает в Windows, есть неплохой шанс сделать ее совместимой с Windows, поместив ее имя в строке LocalTSRs. Оборотная сторона локализации TSR-программ состоит в больших затратах памяти. Если по экземпляру такой резидентной программы запущено на четырех VM, то в этом случае потребуется в четыре раза больше памяти.

Параметр ScreenLines используется для размещения большего объема информации на экране. По умолчанию, Windows выводит 25 строк в окне DOS. Добавьте оператор ScreenLines=50 в раздел [NonWindowsApp] файла SYSTEM.INI, и вы увеличите это число до 50 строк, как показано на рис. 2. ScreenLines=50 — максимальное значение параметра, с которым может работать большинство видеоадаптеров, но некоторые допускают и большие величины. Чаще всего прикладные программы DOS автоматически адаптируются к увеличившемуся числу строк, однако некоторые приходится конфигурировать специально. Немногие — в первую очередь очень старые программы, предназначенные для EGA-мониторов, — несмотря ни на что, будут упорно использовать 25 строк.

Раздел [standard]. В этом разделе хранятся параметры, которые применимы только для стандартного режима Windows. По мере того как все большее число ПК оснащается процессорами 386 и более мощными, стандартный режим используется все реже и реже. Следовательно, этот раздел мы больше не будем обсуждать. Если вы все еще работаете в стандартном режиме, то отказываетесь от наиболее важных преимуществ Windows.

Раздел [386Enh]. Это наверняка  самый сложный их всех разделов файла SYSTEM.INI. Применяемый только в режиме 386 Enhanced, он может содержать более 100 различных ключей. Некоторые из них весьма полезны. Другие столь экзотичны, что применяются лишь редкими из пользователей. Вместо того чтобы попытаться охватить их все, я перечислю некоторые из наиболее полезных и расскажу вам, когда они могут пригодиться. Если вы захотите изменить любой из описанных параметров, это придется сделать вручную.

При каждом обращении к  жесткому диску генерируются от одного до нескольких сотен аппаратных прерываний, уведомляющих BIOS жесткого диска о том, что считываются или записываются отдельные секторы. Для минимизации воздействия этих прерываний на производительность системы среда Windows в 386-Enhanced режиме перехватывает их до того, как они достигнут BIOS, и обрабатывает в защищенном режиме. Если вы не можете обратиться к жесткому диску в Enhanced-режиме, но без труда взаимодействуете с ним вне Windows, попробуйте запустить Windows с ключом ID:V. Если это устранит проблему, найдите выражение VirtualHDIrq в файле SYSTEM.INI (или внесите его, если оно отсутствует) и присвойте ему значение Off. VirtualHDIrq=Off отключает перехват прерываний жесткого диска средой Windows и позволяет BIOS «увидеть» эти прерывания. (Этот параметр необходим для PLUS HardCards и некоторых накопителей IDE и SCSI.) Аналогично, параметр Irq9Global=On из раздела [386Enh] устраняет некоторые проблемы доступа к накопителю на гибких дисках.

Другой параметр [386Enh], который  иногда вызывает трудности у пользователей  Windows, — это SystemROMBreakPoint. Чтобы позволить 16-разрядным программам, работающим в режиме Virtual 86, обращаться к программам, запущенным в 32-разрядном защищенном режиме, в Windows используется весьма интересный прием: она предоставляет 16-разрядной программе адрес запрещенной команды, или точки прерывания. Когда 16-разрядная программа отправляет вызов по этому адресу, генерируется ошибка неверного кода операции и ЦП переключается в защищенный режим. Обработчик ошибок защищенного режима затем выбирает адрес процедуры защищенного режима, по которому пыталась обратиться 16-разрядная программа, и выполняет вызов.

Если параметр SystemROMBreakPoint=On (по умолчанию это так), то запрещенная команда, представляющая собой в действительности лишь байт с шестнадцатеричным значением 63, размещается в ПЗУ, в противном случае она располагается в ОЗУ. (Для использования точки прерывания, находящейся в ПЗУ, Windows просто сканирует ПЗУ до тех пор, пока не найдет байт с шестнадцатеричным значением 63. С учетом того, что байт может принять одно значение из 256 возможных и обычный ПК содержит тысячи байт ПЗУ, поиск чаще всего оказывается успешным.) Windows предпочитает использовать контрольную точку из ПЗУ, потому содержимое это памяти всегда одно и то же. Но блоки управления памятью процессоров 386 могут косвенно искажать содержимое ПЗУ, используя таблицы страниц процессора для размещения ОЗУ в том же адресном пространстве, и некоторые из них не будут работать, если только параметр SystemROMBreakPoint не имеет значения Off. Если вы применяете диспетчер памяти независимого производителя, например QEMM-386, и среда Windows не запускается, то здесь может быть скрыта первопричина проблем.

Связанный с этим параметр MaxBPs (Maximum Breakpoints) определяет максимальное число точек прерывания в ПЗУ. Как описывал в серии статей в начале 1994 г. публицист журнала InfoWorld Брайан Ливингстон, простая установка значения параметра MaxBPs=786 часто повышает устойчивость Windows.

Некоторые из параметров, встречающиеся  в разделе [386Enh], не документированы. Возможно, самый полезный из этих параметров (и, несомненно, один из тех, о которых  я знаю мало) — это DebugLocalReboot=On. Он позволяет завершить исполнение прикладной программы, набрав Ctrl-Alt-Del, даже если Windows не считает, что эта программа «зависла». Другими словами, DebugLocalReboot выдает сообщение: «Although you can use CTRL+ALT+DEL to quit an application that has stopped responding to the system, there is currently no application in this state…» («Хотя для завершения программы, переставшей отвечать системе, можно нажать CTRL+ALT+DEL, программ в таком состоянии нет…»). Очевидно, проектировщики Windows собирались сделать параметр Debughocal Reboot-On значением по умолчанию, пока не осознали, что приглашение на ввод пароля в программе сбережения экрана можно обойти нажатием Ctrl-Alt-Del и прерыванием работы этой программы. Если вы вообще не используете парольную защиту в программе сбережения экрана, то DebugLocalReboot не имеет для вас значения. Единственное, что следует иметь в виду при использовании данного приема, — это то, что имя программы, которое Windows выводит вверху после нажатия Ctrl-Alt-Del при активизированном DebugLocalReboot, не всегда соответствует имени активной программы. Будьте бдительны, чтобы по ошибке не прервать не ту прикладную программу.

Кроме того, можно изменять экранные цвета, которые использует Windows для вывода сообщений при переключении в полноэкранный режим, с помощью MessageBackColor и MessageTextColor. Для изменения цветов с устанавливаемых по умолчанию белого на синем фоне на желтый на красном фоне введите предложения 
MessageBackColor=4 
MessageTextColor=E 
в раздел [386Enh] файла SYSTEM.INI. Значения от 0 до 7 соответствуют черному, синему, зеленому, голубому, красному, пурпурному, желтому и белому цветам соответственно. Для получения более яркого оттенка цвета добавьте 8. Символ E в строке MessageTextColor=E — шестнадцатеричное представление числа 14, соответствующего ярко-желтому цвету.

Можно до некоторой степени  «пришпорить» Windows, установив значение FileSysChange=Off. Значение этого параметра по умолчанию для режима Enhanced-386 — On, поэтому вы должны настраивать эту опцию исключительно в том случае, когда хотите отключить ее. Параметр Off освобождает Windows от необходимости уведомлять File Manager всякий раз, когда прикладная программа DOS, запущенная на другой VM, создает, удаляет или переименовывает файл. Влияние этого параметра можно увидеть, если одновременно открыть File Manager и окно DOS и с помощью команды DEL в окне DOS удалить файл, отображаемый в окне File Manager. Если FileSysChange=On, этот файл немедленно исчезнет и из окна File Manager. Если FileSysChange=Off, файл не исчезнет до тех пор, пока вы не переключитесь на другой каталог и не вернетесь обратно или не нажмете F5 для обновления изображения в окне File Manager.

Иногда может быть полезен  другой связанный с файлами параметр этого раздела — PerVMFiles. Если DOS- или Windows-программа сообщает, что она не может открыть файл, поскольку больше нет доступных обработчиков файлов, отредактируйте SYSTEM.INI и увеличьте данный параметр. По умолчанию, Windows предоставляет каждой VM число обработчиков файлов, эквивалентное параметру FILES в файле CONFIG.SYS плюс значение параметра PerVMFiles. Значение по умолчанию PerVMFiles=10. На моем ПК, где в файле CONFIG.SYS имеется предложение FILES=40 и используется значение PerVMFiles по умолчанию, для каждой VM доступно 50 обработчиков файлов. Это означает, что ни одна программа не может одновременно открыть больше 50 файлов. Если потребность возрастает, я могу увеличить их число, задав большее значение PerVMFiles. Замечу, что этот параметр игнорируется при загруженной утилите SHARE и директива PerVMFiles бессильна превысить предел в 255 одновременно открытых файлов, накладываемый на Windows файловой системой DOS.

Наконец, что можно сказать  о предписаниях, начинающихся с device, в разделе [386Enh] файла SYSTEM.INI? Они загружают VxD — 32-разрядные драйверы виртуальных устройств, работающие на наиболее привилегированном уровне Windows. Директивы device со звездочками справа от знака равенства обозначают многочисленные VxD, которые загружаются диспетчером виртуальных машин (VMM) Windows и представляют собой часть самой операционной системы. Например, директивы

device=*vdmad  
device=*v86mngr  
device=*pageswap 

загружают виртуальные устройства прямого доступа к памяти (VDMAD), диспетчера памяти режима 86 (V86MNGR) и  страничного обмена (PAGESWAP) соответственно. Другие предписания device типа

device=c:\dos\vfintd.386

загружают драйверы VxD независимых поставщиков, в данном случае специальный VxD, устанавливаемый программой настройки DOS 6.x. Драйверы виртуальных устройств — VxD — это «сердце» Windows, поэтому неудивительно, что с помощью SYSTEM.INI их загружается так много. «Device» — одно из весьма немногих ключевых слов, которое многократно встречается в файле SYSTEM.INI. Для большинства других ключевых слов, если вы используете их несколько раз, то первое значение, присваиваемое ключу, обычно будет переопределяться любым из последующих присваиваемых значений.

Заключение

В Windows 3.1 использовались шесть .ini-файлов для загрузки и управления средой Windows (control.ini, progman.ini, protocol.ini, system.ini, win.ini и winfile.ini).

Файл win.ini был основным местом хранения информации, относящейся к конфигурации ПО этой операционной системы, а также специальной информации для всей системы, добавляемой приложениями. Поскольку каждое приложение вносило изменения в файл win.ini (не принимая во внимание все остальные приложения), этот файл разрастался очень быстро. Это вызывало проблемы, когда размер файла превышал 64 Кб. В операционной системе разрешался рост этого файла сверх 64 Кб (без уведомления пользователя, что превышен этот предел), хотя любая запись, выходящая за границу 64 Кб, игнорировалась. Если приложения добавляли записи в верхние разделы файла win.ini, то информация внизу файла выталкивалась за границу инициализации, и эта информация не реализовалась. Приложения, которым требовались эти потерянные записи инициализации, переставали работать полностью или утрачивали определенные функции. Пытаясь воспрепятствовать этой проблеме, Microsoft рекомендовала разработчикам приложений сохранять информацию приложений в частных .ini-файлах, которые бы относились только к их приложению. Хотя это помогло, большинство разработчиков приложений продолжали размещать большое количество информации в файле win.ini.

Файл system.ini использовался  как основное хранилище системной  информации об оборудовании, установленном  на компьютере, чтобы указывать операционной системе на оборудование и связанные  с ним программные компоненты (драйверы устройств, оболочки и т.д.).

Файл progman.ini содержал настройки инициализации для Windows Program Manager, и файл winfile.ini содержал настройки инициализации для Windows File Manager. Отсутствие этих файлов не препятствовало работе Windows (в отличие от файлов system.ini и win.ini), но загружалась конфигурация по умолчанию для приложений, которыми они управляли, без каких-либо настроек, внесенных пользователем.