Поддержка файлов инициализации


Содержание

Поддержка файлов инициализации

Утилита загрузчика VisualDSP++ (loader utility [3]) предоставляет для процессоров Blackfin ADSP-BF531, ADSP-BF532, ADSP-BF533, ADSP-BF534, ADSP-BF536, ADSP-BF537 генерацию файла образа загрузки (boot stream), сжатого механизмом компрессии на основе библиотеки zLib [2]. Компрессия zLib поддерживается сторонней динамически связываемой библиотекой zLib1.dll. Дополнительная информация по этой библиотеке доступна на сайте zlib.net. Здесь приведен перевод раздела «ADSP-BF531/BF532/BF533/BF534/BF536/BF537 Processor Compression Support» из документации [1] компании Analog Devices.

DLL-файл zLib1.dll входит в комплект поставки среды разработки VisualDSP++ (находится в папке System каталога установки VisualDSP++). Библиотечные функции выполняют процедуры компрессии и декомпрессии потока загрузки (boot stream), когда при запуске утилиты загрузчика выбраны соответствующие опции. Исполняемые файлы инициализации со встроенным механизмом декомпрессии в процессе загрузки должны выполнить распаковку сжатого boot stream. Исполняемые файлы по умолчанию с функциями декомпрессии поставляются совместно с VisualDSP++.

Опция командной строки -compression указывает утилите загрузчика [3] выполнить компрессию boot stream. VisualDSP++ также предоставляет управление этой опцией в разделе Load окна настройки свойств проекта (пример см. рис. 3-27).

Рис. 3-27. Страничка Project: Load: Compression свойств проекта процессоров ADSP-BF537.

Утилита загрузки выполняет 2 шага для компрессии boot stream. Сначала утилита генерирует boot stream обычным способом (собирает блоки данных загрузки, подробное описание см. в [4, 5]), после чего применяет компрессию полученного boot stream. Инициализация с декомпрессией выполняется в обратном порядке: сначала загрузчик распаковывает сжатый boot stream, после чего загружает код и данные в сегменты памяти как обычно из распакованного образа загрузки.

Утилита загрузчика сжимает boot stream по принципу .dxe-за-.dxe. Для каждого входного файла .dxe утилита сжимает код и данные вместе, включая весь код и данные из любых связанных файлов оверлея (.ovl) и файлов общей памяти (shared memory, .sm).

[Сжатые потоки]

Рис. 3-21 иллюстрирует базовую структуру файла загрузки с сжатыми потоками.

INITIALIZATION CODE
(код инициализации, ядро с поддержкой декомпрессии)
1-й .dxe COMPRESSED STREAM (поток со сжатым кодом/данными)
1-й .dxe UNCOMPRESSED STREAM (поток с несжатым кодом/данными)
2-й .dxe COMPRESSED STREAM (поток со сжатым кодом/данными)
2-й .dxe UNCOMPRESSED STREAM (поток с несжатым кодом/данными)
.
.

Рис. 3-21. Файл загрузки со сжатыми потоками.

Код инициализации находится наверху этого файла загрузки. Когда запускается процесс загрузки сначала в процессор загружается и запускается код инициализации. Как только выполнился код инициализации, остальная часть потока будет распакована процессором. Код инициализации вызовет подпрограмму декомпрессии, чтобы выполнить распаковку потока загрузки, и затем записывает распакованный поток в память процессора таким же способом, как это делает обычное ядро загрузки (boot kernel), когда оно встречается со сжатым потоком. На последнем шаге код инициализации запускает Boot ROM, указывая ему место нахождения распакованного boot stream, и загрузка продолжается обычным образом.

На рис. 3-22 показана структура сжатого блока.

COMPRESSED BLOCK HEADER (заголовок сжатого блока)
COMPRESSED STREAM (сжатый код/данные)

Рис. 3-22. Compressed Block.

[Заголовки сжатого блока]

Сжатый поток всегда имеет заголовок, за которым идет полезная нагрузка — сжатый поток данных загрузки. Рис. 3-23 показывает структуру заголовка сжатого блока загрузки.

16 бит: PADDED BYTE COUNT
(счетчик количества байт дополнения)
16 бит: SIZE COMPRESSION WINDOW
(размер окна компрессии)
32 бита: общий размер COMPRESSED STREAM
(включая байты дополнения)
16 бит: COMPRESSED BLOCK FLAG WORD
(слово флагов, показывающее сжатый блок)

Рис. 3-23. Compressed Block Header.

Первые 16 бит заголовка сжатого блока содержит счетчик дополнения байт сжатого потока загрузки. «Дополненный поток» означает, что утилита загрузки всегда дополняет количество байт результирующего потока загрузки, полученного на выходе системы компрессии, до четного количества байт. Т. е. утилита загрузки округляет вверх счетчик байт выходного сжатого потока до следующего большего четного числа. Эта 16-битная ячейка содержит счетчик дополнения, т. е. здесь будет либо 0x0000, либо 0x0001.

Следующие 16 бит заголовка сжатого блока содержат размер окна компрессии, используемого алгоритмом компрессии. Это значение показателя степени двойки в диапазоне 8..15, со значением по умолчанию 9, т. е. если 2 возвести в степень этого числа, то получится размер окна компрессии.

Как упоминалось ранее, механизм компрессии/декомпрессии для процессоров Blackfin использует открытую библиотеку сжатия без потерь zLib. Алгоритм сжатия zLib (deflate algorithm) в свою очередь использует комбинацию алгоритмов кодирования Хаффмана и компрессии LZ77.

Компрессия LZ77 работает путем поиска последовательностей данных, которые повторяются в скользящем окне. Следовательно, чем больше размер скользящего окна, тем у алгоритм сжатия может найти больше повторяющихся последовательностей данных, в результате чего коэффициент сжатия повышается. Однако технические ограничения алгоритма декомпрессии zLib диктуют, чтобы размер окна декомпрессора было такое же, как и у компрессора, и окно сжатия нельзя сделать слишком большим из-за ограничений по памяти. Подробнее про реализацию техники компрессии/декомпрессии для процессора Blackfin см. в файле readme.txt, который находится в папке Blackfin\ldr\zlib\src каталога установки VisualDSP++.

В этом файле readme раскрываются разные моменты, связанные со сменой окна компрессии zlib (слайдер «Compression Window Size» на закладке Compression раздела Load настройки свойств проекта Project Options).

Что здесь рассматривается:

1. Окно компрессии. Описываются некоторые технические детали библиотеки zlib, и почему должны соответствовать друг другу размеры кона компрессии и окна декомпрессии.

2. Как работает загрузчик. Здесь рассматривается, как загрузчик вычисляет наложение друг на друга приложения пользователя и ядра инициализации (INIT kernel), и как INIT перезаписывается по окончании процесса декомпрессии.

3. Компромисс при выборе размера окна загрузки.

4. Как перекомпилировать ADSP-BF5xx_zlib_init. Описывается процесс пересборки ADSP-BF5xx_zlib_init, чтобы можно было использовать другой, не по умолчанию размер окна компрессии-декомпрессии, и как подключить новую сборку как INIT kernel.

[1. Окно компрессии]

Поддержка компрессии образа загрузки процессоров Blackfin реализована благодаря алгоритмам сжатия библиотеки zLib [2] (в VisualDSP++ используется версия zLib 1.2.3). Дополнительную информацию по библиотеке zlib можно получить на сайте проекта zlib.net.

Чтобы понять, требуется ли пересборка кода инициализации с поддержкой библиотеки zLib, следует рассмотреть работу её алгоритма сжатия (deflate). Алгоритм deflate работает как комбинация варианта кодирования Хаффмана и компрессии LZ77. Полное описание этих алгоритмов можно найти на страничке [3], здесь будет сделан только краткий обзор.

В документе [3] написано следующее: «Компрессия LZ77 работает путем поиска повторяющихся последовательностей данных. При этом используется понятие ‘скользящее окно’, или ‘окно компрессии’; в реальности это означает для любой точки в данных запись о том, какие символы проходили ранее. Скользящее окно размером 32K означает, что компрессор (и декомпрессора) имеет запись о том, какими были последние 32768 (32 * 1024) символов. Когда следующая последовательность сжимаемых символов идентична одной, которую можно найти в скользящем окне, то последовательность символов заменяется двумя числами: дистанцией (distance) для обозначения, как далеко начинается последовательность в скользящем окне, и длиной (length), представляющей количество символов, для которых последовательность одинакова.»

Таким образом, как упомянуто выше, это ‘скользящее окно’ должно быть одинакового размера для компрессора и декомпрессора, потому что декомпрессор потенциально должен иметь возможность «оглянуться назад» до размера окна. Иначе если размеры окна для компрессии и декомпрессии будут отличаться, то декомпрессор будет работать с другой историей, чем у компрессора, и в результате получатся ошибки в декомпрессии.

В текущей реализации поддержки компрессии кода для Blackfin размеры окна компрессии/декомпрессии выбираются в разных местах сборки проекта, что может привести к проблеме и потребует пересборки проекта ADSP-BF5xx_zlib_init.

1. Окно компрессии выбирается слайдером «Compression Window Size» на закладке Compression в разделе Load свойств проекта (окно диалога Project Options). Этот выбор делается на этапе сборки «сжатого» проекта.

2. Однако размер окна декомпрессии определяется константой ZLIB_WSIZE в файле blkfin_zlib_init.h как часть ядра инициализации с применением библиотеки декомпрессии (zlib INIT kernel). Это было определено при сборке инструментария VisualDSP++, что может отличаться от выбора на шаге 1.

Таким образом, когда пользователь выбирает слайдером «Compression Window Size» размер окна компрессии, которое отличается от размера по умолчанию 9, проект декомпрессии zlib должен быть обновлен (изменением ZLIB_WSIZE) и заново собран, чтобы окно декомпрессии совпадало с окном компрессии.

[2. Как работает загрузчик]

Проект ADSP-BF5xx_zlib_init (код инициализации + ядро декомпрессии zlib) подключается как INIT-секция в поток загрузки LDR «сжатого» проекта приложения пользователя (для дополнительной информации по секциям INIT обратитесь к руководству VisualDSP++ Loader Reference Manual, также см. [4, 5]).

Ядро декомпрессии работает из памяти L1, окно декомпрессии может быть расположено либо в L1, либо в L3 SDRAM (см. файл .ldf проекта ADSP-BF5xx_zlib_init для получения дополнительной информации о том, где размещен код и данные этого проекта). Однако наверняка есть шанс, что сжатое приложение после распаковки должно размещаться области в памяти L1, откуда выполняется ядро распаковки. Таким образом, должна быть обеспечена возможность, что эти области памяти должны быть перезаписаны распакованным приложением пользователя.

Это то место, где загрузчик VisualDSP++ немного помогает решить проблему. Когда пользователь выбирает компрессию, то подходящий DXE-файл ADSP-BF5xx_zlib_init подключается как INIT kernel (либо по умолчанию утилитой загрузчика, либо с помощью опции командной строки -init filename ). Затем утилита загрузчика проверяет карту памяти этого DXE (она определяется ldf-файлом проекта ADSP-BF5xx_zlib_init), чтобы вычислить части приложения пользователя, которые накладываются на INIT kernel. Секции с наложением остаются не сжатыми. По окончании процесса декомпрессии, ядро декомпрессии передает управление загрузкой обратно в код Boot ROM (встроенный в кристалл процессора код обработки потока загрузки), чтобы загрузка продолжилась из не запакованных секций. Эти не сжатые секции затем перезапишут области памяти L1, которые были ранее были заняты выполнением кода INIT kernel.

Таким образом важно обеспечить, чтобы LDF-файл проекта ADSP-BF5xx_zlib_init был максимально консервативен при выделении памяти, насколько это возможно. Если LDF проекта ADSP-BF5xx_zlib_init выделит больше памяти, чем это необходимо для другого кода/данных, то загрузчик вычислит, что слишком много перекрытий приложения пользователя на код INIT kernel, и поскольку перекрывающиеся секции не сжимаются, то это снижает общую эффективность сжатия для приложения пользователя.

По этим причинам, когда осуществляется сборка с новым размером окна декомпрессии, пользователь должен вычислить требования к размеру данных INIT kernel, и увеличить область code/memory в файле LDF в при необходимости.

Например, если для окна декомпрессии выбрано значение 9, что соответствует размеру окна компрессии 0x200 байт (используется по умолчанию), то приблизительные потребности в памяти следующие (все размеры указаны в байтах):

Назначение Размер
Библиотека zlib (обычные данные) 0xB24
Библиотека zlib (данные, инициированные нулем) 0x0
Библиотека malloc (_heap_table) 0x18
Библиотека malloc (данные, инициированные нулем) 0x64
Данные для обработки окна декомпрессии (данные, инициированные нулем), из них 0x200 используется непосредственно под окно декомпрессии 0x28c
Другие структуры данных 0x162
Всего 0xF8E

Выделения памяти по умолчанию следующие:

Это транслируется в приблизительно 0xFFF байт памяти для данных. Это только на 0x71 байт больше, чем требуется для хранения этих данных.

Таким образом, для нового размера окна пользователь должен выполнить подобные вычисления, чтобы достичь наиболее консервативного LDF для этого размера окна. Рекомендуется начать перераспределять память путем просмотра карты памяти линкера, или карты отображения на память (генерация файла карты памяти включается галочкой ‘Generate Symbol Map’ раздела настроек Link диалога свойств проекта Project Options ADSP-BF5xx_zlib_init), и после этого вычислить требования к памяти. Затем в соответствии с этими вычислениями следует уменьшить выделение памяти в файле LDF.

Хотя верно, что большее окно компрессии означает лучшее сжатие, пользователю следует иметь в виду, что чем больше будет перекрытие кодом приложения кода INIT kernel, тем меньше секций кода будет сжато, что в результате снизит общую эффективность сжатия приложения пользователя. Для дополнительной информации см. ниже «3. Компромисс при выборе размера окна загрузки.».

Размещение ядер INIT kernel в памяти кэша L1. Обратите внимание, что INIT kernel может выполнится из памяти L1, которая будет использоваться как кэш в приложении пользователя (это в случае выделения памяти в LDF по умолчанию). Запуск INIT kernel в L1, которая будет использоваться впоследствии как кэш, будет означать, что ни одна часть кода распакованного приложения не будет перекрывать INIT, так что не нужно перезаписывать INIT kernel после завершения декомпрессии, потому что память L1, используемая кодом декомпрессии, будет потом использоваться как кэш. Ни одна из распакованных секций не перезапишут код INIT kernel, что улучшает общий коэффициент сжатия приложения пользователя. Как упоминалось выше, конфигурация по умолчанию zlib INIT kernel выполняется из памяти, которая могла быть сконфигурирована как кэш (как для кода, так и для данных).

[3. Компромисс при выборе размера окна загрузки]

Как упоминалось выше, хотя чем больше окно сжатия, тем лучше коэффициент компрессии, из-за необходимости перекрытия кода INIT kernel декомпрессии кодом распакованного приложения некоторые части кода будут несжатыми. Увеличение размер окна соответственно повышает вероятность такого перекрытия, что снизит общую эффективность компрессии приложения. В общем, из-за наличия ограничений по ресурсам памяти процессора Blackfin, слишком большое окно компрессии может не увеличить, а снизить эффективность сжатия.

К примеру предположим, что показанные ниже коэффициенты сжатия относятся к обычному приложению Blackfin. Коэффициент сжатия, полученный увеличением размера окна компрессии, не линеен по отношению к изменению размера окна компрессии от 9 до 15 (размер окна от 512 байт до 32 килобайт) дает прирост компрессии примерно на

Оригинальное приложение: 117180 байт. Размер окна 512 байт дает сжатый поток 55755 байт (47.58% от оригинального размера). Размер окна 32 килобайт дает сжатый поток 43416 байт (37.05% от оригинального размера).

Однако с другой стороны, любая часть приложения, которая перекроет в памяти области, используемые кодом zlib INIT, не могут быть сжаты (потому что они перезапишут код декомпрессии, см. выше «2. Как работает загрузчик»). Таким образом, в случае окна компрессии 32K это может добавить 32K к образу загрузки, что увеличит общий размер образа ldr в памяти flash. Обратите внимание, что если INIT kernel запускается из памяти L1, сконфигурированной под кэш в приложении пользователя, то в образе ldr не будет несжатых секций.

В соответствии с вышесказанным, когда приложение реально большое, увеличение размера окна до максимума может иметь значение, как например 10% от выигрыша сжатого кода 1 мегабайт составит 100 килобайт. Если вычесть 32 килобайта увеличенного размера окна из выигрыша, то получим результат всего лишь в 68 килобайт — отсюда можно видеть, что самое большое окно может быть полезно только для очень больших приложений.

[4. Как перекомпилировать ADSP-BF5xx_zlib_init]

Здесь объясняется, как перекомпилировать проект ADSP-BF5xx_zlib_init для нового значения ZLIB_WSIZE .

Проект ADSP-BF5xx_zlib_init (ядро инициализации с поддержкой декомпрессии zlib) подключается как секция INIT в поток загрузки LDR сжатого проекта приложения пользователя (подробнее про секции INIT см. руководство VisualDSP++ Loader Reference Manual, также см. [4, 5]).

Когда пользователь выбирает слайдером «Compression Window Size» размер окна сжатия, отличающееся от выбора по умолчанию 9, проект ADSP-BF5xx_zlib_init должен быть обновлен и пересобран с окном декомпрессии того же самого размера, какое было выбрано для компрессии. Это делается определением нового значения для ZLIB_WSIZE .

1. Обновите значение макроса ZLIB_WSIZE в заголовочном файле blkfin_zlib_init.h новым выбранным размером окна.
2. Пересоберите проект ADSP-BF5xx_zlib_init либо в конфигурации ‘SDRAM’, либо в конфигурации ‘L1’ (конфигурация ‘SDRAM’ использует SDRAM для распаковки приложения, т. е. окно декомпрессии размещается в SDRAM. Конфигурация ‘L1’ использует память L1 для декомпрессии приложения пользователя).

Возможны случаи, когда линкер VisualDSP++ будет выдавать ошибки из-за нехватки памяти ‘Out of memory in output section . ‘. Это означает, что были сделаны неправильные вычисления при выборе размера окна декомпрессии.

Причина такой ошибки в том, что LDF-файл по умолчанию выделяет «минимально достаточный» объем памяти, чтобы снизить вероятность перекрытия кодом приложения кода декомпрессии INIT kernel. Таким образом ожидается, что если выбран размер окна больше 9 (512 байт), то линкер выйдет за пределы предоставленной памяти при размещении данных. Чтобы исправить эту проблему, измените blkfin_zlib_init.ldf, чтобы добавить место для увеличенного окна декомпрессии (см. «2. Как работает загрузчик»).

После необходимых изменений в файле LDF пересоберите проект ADSP-BF5xx_zlib_init, чтобы создать новый INIT dxe. Этот новый dxe должен быть подключен как ядро инициализации для сжатого приложения пользователя — либо через страницу настройки свойств загрузки Load диалога Project Options, либо через опцию командной строки -init filename.dxe утилиты загрузчика [4].

В реализации Blackfin декомпрессор является частью инициализационных файлов (см. ниже «Декомпрессия файлов инициализации»). Эти файлы по умолчанию содержать сборку декомпрессора с размером окна 9 (512 байт). Таким образом, если Вы выбираете размер окна компрессии не по умолчанию (слайдером «Compression Window Size» закладки Compression в разделе настроек Load диалога Project Options сжимаемого приложения), то декомпрессор должен быть пересобран с новым выбранным размером окна (как это делается, см. врезку выше).

Последние 16 бит заголовка сжатого блока содержат слово флагов. Единственное возможное назначение флага компрессии показано на рис. 3-24.

Рис. 3-24. Слово флагов (Flag Word) заголовка сжатого блока (Compressed Block Header).

[Не сжатые потоки]

Сжатый поток (показанный на рис. 3-21) файла загрузки включает не сжатые потоки. Не сжатые потоки включают коды приложения, которые конфликтовали в областях памяти с блоками инициализации, и последний блок. Не сжатый поток находится только в последнем блоке, если в сжимаемом приложении не было конфликтующего кода. Последний блок может иметь нулевой счетчик байт, он показывает коду инициализации конец приложения пользователя.

[Загрузка сжатых потоков]

На рис. 3-25 показана последовательность загрузки образа со сжатыми потоками. Файл образа загрузки предварительно сохраняется в памяти FLASH.

1. Boot ROM начинает обрабатывать образ загрузки, находящийся начале FLASH. Код Boot ROM прочитает заголовок кода инициализации и загрузит его.

2. Boot ROM запустит на выполнение загруженный код инициализации.

3. (A) Код инициализации сканирует заголовок на наличие любых сжатых потоков (см. структуру флага компрессии на рис. 3-24). Код распаковывает потоки в окно декомпрессии (по частям) и запускает ядро инициализации в распакованных данных.

(B) Ядро инициализации загрузит данные в различные области памяти точно так же, как это делает Boot ROM.


4. Код инициализации настраивает запуск Boot ROM, чтобы загрузить не сжатые блоки и последний блок (в котором установлен флаг FINAL в слове флага заголовка блока). Код Boot ROM загружает последние полезные данные, перезаписывая при этом любые области, которые использовались кодом инициализации. Из-за установленного флага FINAL в заголовке код Boot ROM делает прыжок на EVT1 (0xFFA0 0000 для процессоров ADSP-BF533/BF534/BF536/BF537/BF538 и ADSP-BF539, 0xFFA0 8000 для процессоров ADSP-BF531/BF532), чтобы запустить на выполнение код приложения пользователя.

[Декомпрессия файлов инициализации]

Как указывалось выше, файл инициализации .dxe с поддержкой декомпрессии должен использоваться, когда генерируется файл образа загрузки со сжатыми потоками. Этот файл .dxe содержит в себе встроенную систему декомпрессии для распаковки сжатых потоков из этого образа загрузки.

Рис. 3-25. Последовательность загрузки с обработкой сжатого потока загрузки ADSP-BF531/BF532/BF533/BF534/BF536/BF537.

Состав программного обеспечения инициализация системы

Лабораторная работа № 1

Тема: ОПЕРАЦИОННАЯ СИСТЕМА MS DOS. ОСНОВНЫЕ КОМАНДЫ СИСТЕМЫ

Цель:

— изучить назначение и состав операционной системы MS-DOS;

— изучить основные внутренние и внешние команды;

— научиться выполнять внутренние и внешние команды MS-DOS.

Теоретические сведения

Общие сведения по операционной системе MS DOS

Совокупность управляющих и обрабатывающих программ называют операционной системой. Иногда говорят, что операционная система – это программная оболочка аппаратных средств ЭВМ. С точки зрения пользователя, операционная система предназначена для оказания ему помощи в организации процесса решения задачи. В настоящее время разработано несколько десятков операционных систем, основные из которых CP/M, MS DOS, MSX DOS, UNIX и др.

MS DOS представляет собой совокупность программных средств, предназначенных для:

1) организации работы (взаимодействия отдельных блоков) и управления ресурсами персонального компьютера;

2) поддержки файловой системы;

3) создания необходимой среды при решении прикладных задач;

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

Загрузка MS DOS производится автоматически при включении питания компьютера. Важным достоинством операционной системы MS DOS является возможность подключения пользователем дополнительных внешних устройств путем написания специальных программ обслуживания (драйверов) этих устройств, а также возможность расширения сервисных функций ОС путем разработки дополнительных утилит (служебных программ), т. е. ОС MS DOS является открытой системой.

Состав программного обеспечения инициализация системы

Важной особенностью MS DOS является ее модульность, т. е. определенные логически связанные группы функций, собранные в отдельные модули. В состав операционной системы MS DOS входят шесть следующих основных модулей:

1) BIOS– базовая система ввода-вывода. Находится в постоянном запоминающем устройстве (ПЗУ) системного блока компьютера.

— автоматическое тестирование программных средств;

— вызов блока начальной загрузки (Boot Record) и передача ему управления;

— обслуживание прерываний нижнего уровня (аппаратных прерываний – этот материал подробно будет изучен в последующих работах).

Этот модуль может быть, скорее, отнесен к аппаратным средствам компьютера.

2) Boot Record – блок начальной загрузки (загрузчик). Находится на нулевой стороне (0) в 1-м секторе нулевой (00) дорожки системного диска и занимает 512 байт.

Boot Record автоматически заносится на диск при его разметке (форматировании).

— проверка наличия в первых двух позициях системного диска основных модулей (файлов) операционной системы io.sys и msdos.sys (в зависимости от фирмы-поставщика файлы могут иметь другие названия, например, ibmbio.com и ibmdos.com);

— загрузка указанных файлов в оперативное запоминающее устройство (ОЗУ) персонального компьютера и передача им управления либо вывод на экран сообщения об ошибке в случае отсутствия этих файлов.

3) io.sys – модуль расширения базовой системы ввода-вывода. Находится в первой позиции корневого каталога системного диска, после загрузки располагается в младших адресах ОЗУ.

— настройка прерываний в соответствии с конкретной конфигурацией компьютера;

— подключение драйверов нестандартных устройств и нестандартного командного процессора (см. ниже);

— запуск модуля обработки прерываний msdos.sys и завершение загрузки ОС путем запуска командного процессора command.com.

4) msdos.sys – модуль обработки прерываний ОС (основной модуль). Находится во второй позиции каталога системного диска.

— обработка логических и программных прерываний;

— обслуживание прикладных программ и обработка ошибок.

5) command.com – командный процессор. Находится на системном диске, при загрузке распадается на две части: резидентную (постоянно находящуюся в ОЗУ), которая располагается в младших адресах ОЗУ, и нерезидентную, которая располагается в старших адресах ОЗУ и при выполнении прикладных программ может быть частично или полностью уничтожена. Это делается в целях экономии памяти, занимаемой ОС.

— прием и анализ команд, введенных с клавиатуры или полученных при выполнении командного файла;

— исполнение встроенных (внутренних) команд ОС;

— загрузка и исполнение внешних команд ОС и прикладных программ;

— исполнение файла autoexec.bat для начальной настройки ОС при ее запуске;

— загрузка (в случае уничтожения) нерезидентной части командного процессора в ОЗУ его резидентной частью.

6) Утилиты MS DOS – внешние (нерезидентные) команды, представляющие собой программы, входящие в стандартный комплекс ОС в виде отдельных загрузочных файлов и выполняющие сервисные функции.

Находятся обычно на системном диске в отдельном каталоге.

Ядро MS DOS составляют модули со 2-го по 5-й, которые занимают в ОЗУ около 60 К байт.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Как то на паре, один преподаватель сказал, когда лекция заканчивалась — это был конец пары: «Что-то тут концом пахнет». 8379 — | 8008 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Файлы инициализации

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

Формат файла

Файлы с расширением *.ini широко распространены не только в мире Windows, но и в других системах, например, php.ini. Формат ini‐файла очень прост: файл разделён на секции (или разделы), в каждой секции может находиться произвольное число записей вида «параметр=значение». Секции указываются в квадратных скобках. Имена параметров в разных секциях могут совпадать.

В ini‐файлах предусмотрены комментарии — это строки, начинающиеся с точки с запятой.

Код INI‐файл
[секция_1]
параметр1 = значение1
; это комментарий
параметр2 = значение2

[секция_2]
параметр1 = значение1
параметр2 = значение2

Функции для работы с ini‐файлами

Существуют специальные функции, предназначенные для чтения и записи INI-файлов, они лежат в библиотеке kernel32.dll:

  • GetPrivateProfileString — считывает строковое значение указанного параметра из указанного раздела;
  • GetPrivateProfileInt — считывает целочисленное значение указанного параметра из указанного раздела;
  • WritePrivateProfileString — записывает значение указанного параметра в указанный раздел указанного ini‐файла. Если указанного раздела или параметра не существует, то он будет создан. Если указанного ini-файла не существует, то он также будет создан.

Эти функции работают со строками и существуют в двух вариантах: в ANSI‐версии и в юникодной версии, однако запись и чтение ini‐файлов в юникоде будет работать только если файл уже был ранее создан в юникоде (кодировка UTF-16 LE). То есть создать юникодный ini‐файл функцией WritePrivateProfileString нельзя, но можно создать сторонними программами, например, блокнотом.

GetPrivateProfileString

Получает строковое значение из INI‐файла.

Код FreeBASIC
Declare Function GetPrivateProfileString Alias «GetPrivateProfileStringW» ( _
&t; ByVal lpAppName As LPCWSTR , _
&t; ByVal lpKeyName As LPCWSTR , _
&t; ByVal lpDefault As LPCWSTR , _
&t; ByVal lpReturnedString As LPWSTR , _
&t; ByVal nSize As DWORD , _
&t; ByVal lpFileName As LPCWSTR _
) As DWORD

Параметры

Возвращаемое значение

Функция возвращает количество скопированных символов в строку не включая нулевой символ. Для получения дополнительных сведений об ошибке можно вызвать функцию GetLastError.

GetPrivateProfileInt

Если значение в файле инициализации представлено числом, то его проще получить функцией GetPrivateProfileInt. Вот её определение из заголовочных файлов:

Код FreeBASIC
Declare Function GetPrivateProfileInt Alias «GetPrivateProfileIntW» ( _
&t; ByVal lpAppName As LPCWSTR , _
&t; ByVal lpKeyName As LPCWSTR , _
&t; ByVal lpDefault As INT_ , _
&t; ByVal lpFileName As LPCWSTR _
) As UINT

Параметры

Возвращаемое значение

Функция возвращает число, представленное в INI‐файле.

WritePrivateProfileString


Записывает значение в ini‐файл, а если такового не было, то создаёт его.

Код FreeBASIC
Declare Function WritePrivateProfileString Alias «WritePrivateProfileStringW» ( _
&t; ByVal lpAppName As LPCWSTR , _
&t; ByVal lpKeyName As LPCWSTR , _
&t; ByVal lpString As LPCWSTR , _
&t; ByVal lpFileName As LPCWSTR _
) As WINBOOL

Параметры

Возвращаемое значение

Если функция выполнилась успешно, то возвращаемое значение не ноль. При ошибке возвращаемое значение — ноль. Для получения дополнительных сведений об ошибке можно вызвать функцию GetLastError.

Примеры

Далее будут примеры использования с учётом юникода, а значит, программа будет корректно читать и записывать русские буквы.

Чтение файла

Создай в блокноте текстовый файл «configuration.ini» и сохрани его в кодировке Unicode (UTF-16):

Код INI‐файл
[Окно]
; Ширина и высота окна
W >= 640
Height = 480

; Параметры пользователя
[Пользователь]
Имя = Алексей

А теперь исходный код для чтения файла. Всё очень просто:

Код FreeBASIC
‘ Чтобы работать с юникодом
#define unicode
#include once «windows.bi»

‘ Полный путь к файлу
Const FileName = «E:\Programming\FreeBASIC Projects\INI\configuration.ini»
‘ Размер буфера
Const BufferSize As Integer = 255
Const SectionWindow = «Окно»
Const KeyW >»Width»
Const KeyHeight = «Height»
Const DefaultValue = «Значение по умолчанию»

‘ Значение из ini‐файла, которое мы получим
Dim Value As WString * (BufferSize + 1) ‘ Один символ под нулевой

‘ Функция GetPrivateProfileString возвращает количество символов, скопированных в буфер (Value)
‘ Если раздел или ключ не будут найдены, то в Value будет записано содержимое DefaultValue
Dim Result2 As DWORD = GetPrivateProfileString(SectionWindow, KeyWidth, DefaultValue, Value, BufferSize, FileName)
If Result2 > 0 Then
&t; Print KeyWidth, Value
End If
Result2 = GetPrivateProfileString(SectionWindow, KeyHeight, DefaultValue, Value, BufferSize, FileName)
If Result2 > 0 Then
&t; Print KeyHeight, Value
End If

Получение всех секций и ключей

Чтобы получить список всех секций, нужно в GetPrivateProfileString вместо имени секции передать Null. Функция заполнит возвращаемое значение Value строкой из всех разделов, разделённых символом с кодом 0. Аналогично для списка всех параметров в разделе: вместо имени требуемого параметра передать Null.

Илон Маск рекомендует:  optgroup в HTML

Код FreeBASIC
‘ Получение всех секций
Dim Result2 As DWORD = GetPrivateProfileString(Null, Null, DefaultValue, Value, BufferSize, FileName)
PrintResult(Value, Result2)

‘ Получение всех ключей
Result2 = GetPrivateProfileString(SectionWindow, Null, DefaultValue, Value, BufferSize, FileName)
PrintResult(Value, Result2)

‘ Печать результата
Sub PrintResult( ByRef Value As WString , ByVal ValueLength As Integer )
&t; Dim Start As Integer = 0
&t; Dim w As WString Ptr = Any
&t; Do While Start ‘ Получить указатель на начало строки
&t;&t;w = @Value[Start]
&t;&t; ‘ Распечатать
&t;&t; Print *w
&t;&t; ‘ Измерить длину строки, прибавить это к указателю + 1
&t;&t;Start += Len (*w) + 1
&t; Loop
End Sub

Запись в файл

Попробуем сменить имя пользователя:

Код FreeBASIC
Const SectionUser = «Пользователь»
Const KeyUser = «Имя»
Const UserName = «Саша»

‘ Функция возращает значение WinBool
Dim Result As WinBool = WritePrivateProfileString(SectionUser, KeyUser, UserName, FileName)
If Result Then
&t; Print «Запись удалась»
End If

Удаление раздела или параметра

Удаление — это запись NULL в ключ или раздел.

Удалим параметр «Имя» из раздела «Пользователь»:

Код FreeBASIC
Result = WritePrivateProfileString(SectionUser, KeyUser, NULL, FileName)
If Result Then
&t; Print «Удаление параметра успешно»
End If

Точно также можно удалять целые секции из ini‐файлов:

Код FreeBASIC
Result = WritePrivateProfileString(SectionUser, NULL, NULL, FileName)
If Result Then
&t; Print «Удаление секции успешно»
End If

Не забываем сохранять исходный код в кодировке UTF-8 или UTF-16, а сам ini‐файл в юникоде (UTF-16).

Ссылки

  • Описание функции GetPrivateProfileString на сайте MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs.85%29.aspx
  • Описание функции WritePrivateProfileString на сайте MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms725501%28v=vs.85%29.aspx
  • Недостатки INI‐файлов http://www.transl-gunsmoker.ru/2010/05/ini.html

Поделись ссылочкой в социальных сетях

«Пакетные файлы» создали этот сайт по технологии XHTML 11 марта 2020 года

Глава 10. Инициализация приложений

Теперь вы знаете, как разрабатывать приложения MIDP и выполнять их с помощью эмулятора. Однако на самом деле вам нужно установить ваши приложения на реальные мобильные устройства. Мобильные устройства должны поддерживать установку приложений пользователями. Процесс, который поддерживает этот вид динамической установки приложений на портативные устройства, называется инициализацией приложений. Системы, которые поддерживают этот процесс, называются системами инициализации.

В контексте данной главы или книги термин инициализация относится к поставке программных приложений на мобильные устройства. Для беспроводных транспортировщиков и фирм-производителей (называемых OpCos), инициализация имеет совершенно другое значение, а именно, настройка атрибутов устройства и модуля идентификации станции (station identification module (SIM)) для голоса, данных и других традиционных служб.

Эта глава знакомит вас с системами инициализации приложений. Ее цель — познакомить разработчиков с понятиями, связанными с инициализацией приложений, и описать вопросы, связанные с подготовкой приложений к размещению на системах инициализации.

В этой главе вы не узнаете, как создавать или проектировать системы инициализации приложений. Системы инициализации являются комплексными корпоративными приложениями, и описание их разработки или создания лежит за пределами темы данной книги.

Производители обычно устанавливают программное обеспечение, которое вы видите на мобильных устройствах, перед тем как устройства покидают завод. Но предварительная заводская установка всего этого программного обеспечения становится все менее и менее осуществимой для производителей. Устройства не имеют достаточно ресурсов памяти для хранения и увеличения количества разнообразных приложений, которые могут потребоваться пользователям. Более того, предварительно установленные приложения никогда не смогут удовлетворить требования всех пользователей. Поэтому пользователям необходимо иметь возможность устанавливать программное обеспечение на свои мобильные устройства, как они делают это на персональных компьютерах. Эта возможность позволяет пользователям изменять имеющийся у них набор приложений в любое время, удаляя некоторые приложения и устанавливая новые для того, чтобы обойти ограниченные возможности хранения устройства.

Для того чтобы инициализировать приложения на своих устройствах, пользователям нужна возможность обнаружения, выбора, покупки, загрузки и установки приложений с помощью своих мобильных устройств. Поскольку мобильные устройства не всегда имеют возможность соединения с какой-либо сетью или другим устройством посредством каких-либо способов, за исключением радиоинтерфейса, поддерживаемого беспроводной сетью, транспортировщики должны поддерживать установку приложений MIDP «по воздуху» (over-the-air (OTA)). Во время написания данной книги инициализация ОТА являлась краеугольным камнем инициализации приложений для мобильных устройств.

В настоящее время, однако, многие беспроводные устройства стали способны загружать приложения посредством некоторых других механизмов, отличных от ОТА, таких, как использование инфракрасных портов, модулей флэш-памяти и так далее. Тем не менее, возможно, что некоторые мобильные устройства по-прежнему будут иметь только беспроводную связь через радиоинтерфейс беспроводной сети в течение еще некоторого времени.

Беспроводные транспортировщики и другие поставщики услуг, поддерживающие инициализацию приложений для своих пользователей, предоставляют системы инициализации, с которыми их пользователи могут взаимодействовать. Эти системы инициализации поддерживают инициализацию ОТА для М9бильных устройств, связанную с беспроводной сетью транспортировщика и шлюзом беспроводного Интернета (wireless Internet gateway (WIG)). На рисунке 10.1 показана одна из возможных схематичных логических диаграмм, которая отражает роль системы инициализации в сетевой инфраструктуре транспортировщика.

Инициализация ОТА требует установления «телефонного звонка», или соединения для передачи данных в сетях передачи данных, таких, как 2.5G или 3G — для соединения мобильного устройства, которое является клиентом, с инициализирующим сервером. Со стороны сервера диспетчер инициализации теоретически представляет основной компонент системы инициализации, который управляет различными стадиями процесса инициализации. Эти стадии включают динамическое обнаружение, представление описаний содержимого, поставку, фиксацию транзакции и создание счета.

На устройстве программное обеспечение агента пользователя взаимодействует с диспетчером инициализации. Программное обеспечение агента пользователя должно быть совместимо с механизмом взаимодействия, определяемым диспетчером инициализации. Возможны две схемы: обнаружение протокола Wireless Application Protocol (WAP) с HTTP-пересылкой и обнаружение WAP с сегментацией и повторным ассемблированием (SAR) WAP. Беспроводные транспортировщики на определенных рынках, особенно в Японии, создают инфраструктуры, которые поддерживают TCP/IP к телефонной трубке. Эти инфраструктуры способны поддерживать передачу HTML (XHTML) телефонной трубке посредством HTTP-транспортировки, перемещая WAP. Когда эта модель станет более распространенной в реализациях сетей 2.5G и 3G, интерфейсы диспетчера инициализации изменятся соответственно.

Рисунок 10.1. Система инициализации приложений связывается со шлюзом беспроводного Интернета транспортировщика для того, чтобы иметь возможность взаимодействовать с мобильными устройствами, которые она обслуживает

AMS устройства может иметь возможность действовать в качестве программного обеспечения агента пользователя, или, по крайней мере, быть близко связанной с микробраузером устройства. В качестве альтернативы устройства могут содержать специализированное программное обеспечение обнаружения приложений (discovery application (DA)), чья работа заключается в идентификации наборов MID-летов для пользовательской загрузки. Помимо других обязанностей, программное обеспечение DA должно быть способно размещать инициализированные приложения в месте, доступном AMS. Термин диспетчер приложения Java (Java application manager (JAM)) используется для описания AMS системам, которые поддерживают инициализацию приложений Java.

Программное обеспечение агента пользователя на устройствах-клиентах должно работать совместно с системой инициализации, чтобы иметь возможность взаимодействовать с помощью четко определенных интерфейсов через общедоступный механизм взаимодействия. Обычно беспроводные сети используют HTTP через некоторый транспортный протокол для того, чтобы устанавливать коммуникации уровня приложений с мобильными устройствами. В действительности документ «Over The Air User Initiated Provisioning Recommended Practice, Addendum to the Mobile Information Device Profile» требует, чтобы инициализация OTA поддерживала протокол HTTP. HTTP является единственным протоколом, который должен поддерживаться обязательно. Вы можете найти эту спецификацию по адресу http://java.sun.com/products/midp/. Между прочим, возможно, что рекомендации данного документа станут частью спецификации MIDP-NG (следующее поколение).

Существует три причины инициализации приложений:

для автоматизации процесса определения совместимости приложений и сред, в которые они загружаются, для предоставления возможности доставки приложений на устройства, для поддержки микромодели работы со счетами, привлекательной для разработчиков приложений MIDP при продаже ими своих продуктов.

Хотя системы инициализации и программное обеспечение агента пользователя помогают автоматизировать процесс инициализации, пользователям приходится выполнять этапы, которые требуют вмешательства человеческого интеллекта, такие, как указание критериев поиска приложений, выбор приложений, одобрение покупки программного обеспечения и подтверждение загрузки программного обеспечения.

Процесс инициализации основан на обмене информацией между клиентом и сервером. Программное обеспечение клиентского агента получает доступ к информации о среде клиента и передает ее диспетчеру инициализации. Программное обеспечение диспетчера инициализации представляет информацию о зарегистрированных приложениях на мобильном устройстве. Оно получает эту информацию из своего хранилища зарегистрированных приложений. Система инициализации получает доступ к определяемой приложением информации, такой, как информация, содержащаяся в файле JAD приложения или файле манифеста. Вместе клиент и сервер обмениваются информацией, договариваются о правах, привилегиях и обязанностях и сотрудничают для доставки приложений на мобильные устройства. Диспетчеры инициализации, которые контролируются OpCos, также имеют доступ к пользовательской информации, такой, как профили и настройки пользователя.

Приложения могут быть отдельными клиентскими приложениями, распределенными приложениями или приложениями клиент-сервер, которые требуют клиентской части и серверной части (компонент сетевой службы). Например, приложение может состоять из компонента, который выполняется на мобильном устройстве и взаимодействует с серверным, который запущен на сервере в сети транспортировщика или в сети поставщика услуг (например, сеть корпоративного покупателя). Дескриптором приложения может оговариваться, что серверный компонент должен быть установлен до того, как клиентский компонент будет инициализирован на устройствах. Система инициализации может определять, способна ли сетевая среда поддерживать требования приложения. Другие задачи включают определение того, как и где серверные компоненты должны быть установлены или запущены, или может ли сеть поддерживать постоянную доступность компонентов.

Приложения инициализации также включают анализ времени жизни приложения и реверсирование процесса инициализации. Некоторые приложения могут оговаривать выполнение пользователем заданное число раз или использование в течение определенного периода времени. Это может применяться для пробного программного обеспечения или для определенных типов лицензий на программное обеспечение. Приложения могут также оговаривать то, что они не должны находиться на устройствах постоянно, а вместо этого загружаться каждый раз с сервера инициализации. Сервер может проверять истечение срока использования определенными пользователями или даже определенными устройствами.

Процесс инициализации может включать выборочное удаление приложений для освобождения места под новые приложения. Поддержка этого свойства требует согласования программного обеспечения агента пользователя устройства и программного обеспечения диспетчера инициализации. Удаление приложений потребует извещения пользователя.

В настоящее время системы инициализации приложений предлагают несколько коммерческих производителей. Многие из их свойств созданы специально для поддержки инициализации приложений J2ME. То есть многие из свойств этих систем связаны с проблемами инициализации в беспроводных средах.

На практике процесс инициализации включает две основных фазы:

— инициализация зарегистрированных приложений на устройствах.

Первый этап, регистрация, делает приложение доступным для инициализации. Второй этап, инициализирующий зарегистрированные приложения, состоит из всех этапов, которые требуются для осуществления установки приложения на мобильном устройстве. Задачи, формирующие вторую фазу, иногда группируются в следующие три категории:

обнаружение — поиск приложения; посредничество — предоставление пользователям информации о приложении, согласование лицензии программного обеспечения, подтверждение покупки, выполнение обязательств по покупке;

загрузка — аутентификация использования, загрузка приложения, установка приложения на устройстве, подтверждение установки, удаление установленных приложений, установка ресурсов сервера, операции по выдаче счетов.

В остальной части данного раздела я просто познакомлю вас с отдельными задачами без ссылки на эти три категории.

Перед тем как приложения получат возможность инициализации на устройствах, они должны быть зарегистрированы в системе инициализации. Зарегистрированное приложение — это то, что известно системе инициализации и может быть переслано на устройство.

Процесс регистрации приложения обычно инициирует человек или организация, которая разрабатывает приложение. Однако прежде, чем разработчик сможет зарегистрировать приложение, он или она должен обычно зарегистрироваться в качестве пользователя системы инициализации транспортировщика или члена программы разработчиков транспортировщика. Система инициализации может поддерживать регистрацию разработчиков через Web с использованием Web-интерфейса, основанного на HTML. После пользовательской регистрации разработчик может загружать приложения в систему.

Обычно системы инициализации поддерживают два основных механизма управления зарегистрированными приложениями. С помощью первого подхода разработчик загружает файлы JAR, JAD и манифеста приложения, как указано системой инициализации. Система инициализации физически содержит эти элементы в своем хранилище. С помощью второго подхода разработчик просто регистрирует URL и файл JAD (или метаданные, необходимые для создания файла JAD), которые показывают местонахождение, из которого диспетчер инициализации может извлекать приложение, необходимое во время инициализации. Разработчик или даже другой поставщик может фактически хранить файл JAR приложения.

Не все системы инициализации могут поддерживать как возможность внутреннего постоянного хранения файлов JAR, так и возможность ссылки на внешние файлы JAR. Как разработчик, вы должны предусмотреть, какие схемы приемлемы и какие, по вашему мнению, соответствуют сценариям использования ваших приложений. Возникают вопросы нетехнического плана — такие, как правовые вопросы обеспечения защиты от несанкционированного доступа к вашему приложению, которое может содержать ценную интеллектуальную собственность, или соглашения служебного уровня (service-level agreement (SLA)) с покупателем или транспортировщиком.

В обязанности разработчика входит поставка всей информации в форме, требуемой системой инициализации. Во время регистрации разработчик должен предоставить всю информацию, которая необходима во время процесса инициализации. По самой меньшей мере вам нужно предоставить JAD приложения и файлы манифеста, которые содержат информацию о платформе приложения, устройстве и требованиях ресурсов исполнения. Кроме того, система инициализации может поддерживать загрузку одного или нескольких собственных файлов с целью предоставления дополнительной информации о приложении. Например, вы имеете возможность предоставить файл XML, который описывает ваши предпочтения в лицензировании, оплате покупки, методах подтверждения покупки и так далее. Можно, конечно, определить атрибуты в файле JAD приложения, который описывает эти области. Это хороший пример, который демонстрирует, почему разработчики должны знать о возможностях системы инициализации или систем, которые они используют.

Поиск приложений — это процесс, с помощью которого пользователи обнаруживают интересующие их приложения. Это первый этап процесса инициализации, в который вовлечен конечный пользователь. Большинство систем инициализации обычно предоставляют пользователям какой-либо WML-интерфейс (или XHTML) для обнаружения приложений с помощью мобильных устройств. Мобильные устройства, которые предназначены для загрузки ОТА, имеют НТТР-микробраузер, который, наиболее вероятно, будет интегрирован до некоторой степени в программное ббеспечение пользовательского агента устройства.

Реальная работа пользователя с системами инициализации варьируется в зависимости от характеристик и поведения определенного продукта. Некоторые системы инициализации также предоставляют HTML-интерфейсы, которые ориентированы на персональные компьютеры. Пользователи могут выполнять этапы обнаружения и посредничества с помощью своих персональных компьютеров, а затем использовать свои мобильные устройства только для выполнения загрузки.


Как вы узнали в предыдущем разделе, одной из основных целей инициализации является содействие обнаружению приложений, которые совместимы со средой мобильного устройства. Диспетчер инициализации сравнивает атрибуты среды устройства с набором атрибутов приложения. Он может гарантировать, что несовместимые приложения никогда не загрузятся на устройство. При определении совместимости сред приложений и устройств среда мобильного устройства делится на следующие четыре контекста:

— контекст среды платформы J2ME;

Процесс инициализации должен принимать во внимание права и привилегии пользователя мобильного устройства. Пользователи могут быть классифицированы в соответствии с различными категориями, которые определяют их привилегии, такие, как план обслуживания или статус учетной записи. Не все пользователи обязательно имеют одинаковые привилегии. В результате не все пользователи имеют возможность просматривать все приложения, зарегистрированные на сервере. Многие из этих классификаций нетехнические по своей природе.

При анализе контекста устройства, однако, более важно должное техническое функционирование приложений. Системы инициализации требуют информации о контексте устройства, например, о том, как много у него памяти, каковы его рабочие ресурсы и так далее. Например, если в устройстве недостаточно общей памяти для хранения набора приложений, диспетчер инициализации должен запрещать его загрузку. Если недостаточно свободного места, AMS (JAM) уведомит пользователей, что они должны освободить место для приложения, удалив какое-либо другое содержимое.

Анализ контекста устройства связан с контекстом приложения. Приложения имеют определенные минимальные требования, соблюдение которых необходимо для их нормального выполнения. Например, приложению может потребоваться определенный размер и разрешение экрана или способность к воспроизведению цветов для эффективной работы. В связи с этим могут потребоваться определяемые производителем библиотеки, минимальные уровни рабочей памяти, определенный минимальный размер хранилища данных RMS и так далее.

Анализ среды J2ME, необходимой приложению, так же важен, как и анализ родной среды устройства. Приложения, возможно, потребуют, чтобы устройство поддерживало определенную версию MIDP или CLDC. Обычно это MIDP и CLDC, под которыми приложение было разработано. Какими бы ни были определенные характеристики клиентской среды, они переносятся на сервер инициализации, чтобы использоваться в качестве параметров поиска. Система инициализации сопоставляет эти характеристики с поисковыми категориями, которые она поддерживает. Системы инициализации варьируются в своей сложности и в своей возможности использовать определенные поисковые категории.

Результаты поиска представляют собой отфильтрованное подмножество приложений, зарегистрированных в системе инициализации. Они должны содержать только те приложения, которые совместимы с контекстом клиента. По самой меньшей мере системы инициализации будут ограничивать результаты поиска в соответствии с критериями пользователя, устройства и платформы J2ME. Некоторые системы инициализации могут также поддерживать более продвинутый поиск, такой, как возможность соотносить информацию о местоположении устройства с приложениями, которые подходят для этого региона, основываясь на выполняемых функциях, наличии локализации и так далее.

Информация о среде клиента обычно посылается как HTTP-заголовки HTTP-запроса из браузера устройства диспетчеру инициализации. Агент пользователя и браузер взаимодействуют для создания HTTP-запроса, который связывается с поисковой функцией инициализирующего сервера.

В менее автоматизированных системах инициализации пользователям может понадобиться ввести значения для поисковых категорий в браузере их устройства. Система инициализации может предоставлять HTTP-интерфейс, который позволяет пользователям указывать характеристики поиска.

В более автоматизированных системах система инициализации извлекает информацию о предпочтениях пользователя из сети транспортировщика. Агент пользователя может пересылать идентификационный номер мобильной станции (MSISDN или MSN) на сервер инициализации. Если сервер инициализации поддерживает интеграцию с внешними системами, такими, как серверы каталогов, он может получать пользовательскую информацию с сервера каталогов транспортировщика. Для того чтобы этот подход работал, транспортировщик должен предоставлять пользователям возможность вносить в пользовательские записи свои предпочтения при поиске для инициализации.

Чем выше уровень автоматизации, тем более эффективным становится процесс поиска, и тем менее вероятно, что он сделает ошибку. Это важно учитывать как пользователям, так и транспортировщикам. Просмотр вручную занимает много времени и часто приводит к появлению ошибок. Вероятно, можно с уверенностью сказать, что навигация вручную и серфинг по WML-страницам (или XHTML в развивающихся в настоящее время системах) требует длительных соединений. Это следует из больших затрат на время передачи в сетях с коммутацией каналов (сети 2G) и высоких издержек при передаче пакетов в сетях с коммутацией пакетов (сети 2.5G и 3G), которые нежелательны для пользователей. Это также занимает полосу пропускания, что нежелательно для транспортировщиков.

В процессе поиска система инициализации выводит результаты поиска в список для пользователя. Система может систематизировать результаты по группам, типам устройств, поддерживаемой платформе J2ME, типу лицензии программного обеспечения, цене покупки программного обеспечения или некоторым другим категориям. Некоторые системы могут поддерживать многоуровневую сортировку, так что пользователи могут проранжировать приложения и задать организацию результатов поиска в соответствии с несколькими критериями.

В общем, важно, чтобы разработчики приложений знали о свойствах, поддерживаемых системой инициализации. Знакомство с возможностями систем инициализации дает разработчикам возможность извлекать выгоду из свойств системы.

Поиск приложений является хорошим примером получаемых преимуществ. Например, если разработчик может предоставлять метаинформацию для поисковых категорий и типов поиска, поддерживаемых инициализирующим программным обеспечением, обнаружение подходящих приложений пользователями будет более успешным и точным. Количество заявок, полученных на приложение, может положительно повлиять на его коммерческий успех. Знакомство со свойствами и возможностями систем инициализации дает разработчикам возможность подготовить файлы дескриптора своих приложений и метаинформацию для более эффективного и плодотворного использования в системе инициализации.

Подтверждение совместимости — это процесс подтверждения совместимости приложения на основе контекстов устройства, пользователя и платформы J2ME. Все инициализирующие системы не должны позволять загрузку или даже обнаружение несовместимых приложений.

Диспетчер инициализации может проверять совместимость приложения с указанным устройством, сравнивая метаинформацию устройства и приложения. Все системы инициализации должны запрещать загрузку наборов приложений, которые несовместимы со средой указанного устройства.

В действительности проблема подтверждения совместимости является одной из причин, по которым атрибутам MicroEdition-Configuration и MicroEdition-Profile требуются атрибуты файла JAD. Система инициализации использует эту информацию при поиске совместимых приложений.

Подтверждение пoкyпки и соблюдение обязательных условий

Подтверждение покупки — это процесс удостоверения в том, что пользователи оплатили приобретенное программное обеспечение, которое требует платы за покупку, и что они оплатили только программное обеспечение, которое они приобрели. Соблюдение обязательных условий включает в себя процессы подтверждения того, что пользователь действительно сделал выбор по приобретению программного обеспечения, которое он должен оплатить, и безошибочного отказа признания любой попытки пользователя отказаться от осуществленных транзакций.

Системы инициализации выполняют эти этапы до генерирования события создания счета. Они должны поддерживать подтверждение покупки и соблюдение обязательных условий для того, чтобы обеспечивать полноту охвата финансовых и коммерческих транзакций. Все системы инициализации должны поддерживать защищенные коммуникации для денежных транзакций, передачи информации о покупке и информации о соблюдении обязательных условий.

Аутентификация пользователей — это просто процесс подтверждения через агента пользователя того, что пользователь является тем, кем себя заявляет. Аутентификация пользователя требует, чтобы агент пользователя передавал информацию о пользователе диспетчеру инициализации. Обычно агент пользователя передает эту информацию диспетчеру инициализации в форме HTTP-заголовков HTTP-запроса браузера устройства. Запрос скорее всего также использует поле заголовка HTTP-запроса агента пользователя для идентификации агента пользователя.

Существуют некоторые беспроводные системы, которые не хранят много пользовательской информации на мобильных устройствах. В таких случаях сервер должен связывать пользовательскую информацию с информацией устройства — MSN устройства, например. Как описывалось ранее, системы инициализации могут взаимодействовать с другими системами транспортировщика, такими, как серверы аутентификации, серверами облегченного протокола службы каталогов (Lightweight Directory Access Protocol (LDAP)) или серверами шлюза беспроводного Интернета (WIG) для получения остальной необходимой пользовательской информации.

Согласование лицензии на программное обеспечение

Процесс согласования лицензии на программное обеспечение включает предоставление пользователю условий лицензирования и подтверждение пользователем его принятия условий. Этот этап осуществляется перед загрузкой приложения. Этот этап может быть выполнен на персональном компьютере вместо мобильного устройства.

Приложения, которые оговаривают требование покупки лицензии, должны предоставлять всю информацию, требуемую для процесса согласования лицензии. Эта информация должна быть доступна системе инициализации. Зависящая от приложения информация, такая, как тип лицензии, условия лицензирования и так далее, должна быть включена в файл JAD приложения.

Загрузка приложения — это процесс физической отправки приложения на мобильное устройство. Обычно этот процесс использует HTTP-механизм загрузки и браузер устройства для получения программного обеспечения.

Более совершенные системы будут поддерживать возможность контроля загрузки пользователем. Одним из примеров пользовательского контроля является возможность перезапуска прерванной загрузки пользователем. Прерывание загрузки может случиться, например, если вызов или данные соединения не прошли. Во время написания данной книги лучшим, на что мы могли надеяться, было то, что устройство выполняет частичные загрузки.

Некоторые системы поддерживают лишь возможность перезапустить загрузку с начала. Даже в этом случае пользователю не придется проходить вновь через весь цикл обнаружения, аутентификации и покупки. Система инициализации должна поддерживать достаточную информацию о состоянии операции, чтобы позволить пользователю перейти непосредственно к этапу загрузки.

Более совершенные системы дадут пользователю возможность перезапускать загрузку из точки, на которой произошло прерывание. Это свойство предпочтительно, поскольку оно сокращает продолжительность передачи и уменьшает использование полосы пропускания. Более совершенные системы также поддерживают как небезопасную (HTTP), так и безопасную (HTTPS/SSL) загрузку приложений.

Установка приложения и подтверждение установки

Установка приложения — это процесс установки программного обеспечения, которое уже находится на устройстве. После загрузки приложения браузер должен начать взаимодействие с AMS устройства, которая является компонентом, сохраняющим приложение на устройстве. AMS отвечает за установку программного обеспечения. Пользователь, однако, инициирует установку программного обеспечения посредством взаимодействия с AMS. AMS хранит приложения в определяемом устройством месте, но не в RMS MIDP, о которой вы узнали в главе 7.

Спецификация CLDC не требует того, чтобы AMS устройства хранила приложения MIDP, поскольку не все мобильные устройства поддерживают механизм постоянного хранения, такой, как файловая система. Альтернативным механизмом для AMS будет поддержка загрузки классификационных файлов с системы инициализации, необходимых для выполнения приложения. Виртуальная машина Java просто загружает классификационные файлы Java по мере их пересылки, выполняет приложение, а затем отбрасывает классификационные файлы, когда процесс установки завершен.

Приложения могут состоять из серверных компонентов и ресурсов, таких, как демоны сервера, базы данных и так далее. В таких случаях установка приложения должна включать установку этих серверных компонентов, а также компонентов клиента. Не все инициализирующие системы будут поддерживать эту возможность.

Информация дескриптора приложения должна включать информацию о том, как и когда должны быть установлены серверные компоненты. Например, дескриптор приложения должен показывать, должны ли серверные компоненты устанавливаться при первом использовании клиентского приложения или во время первой загрузки клиентских ресурсов. На сегодняшний день реальность заключается в том, что серверные компоненты должны быть установлены, сконфигурированы и протестированы до того, как клиенты начнут попытки получения доступа к ним.

Подтверждение установки включает информирование диспетчера инициализации об успешной установке. Уведомление об установке важно, поскольку пользователи обычно получают счета после того, как они установили приложение. Атрибут MIDlet-Install-Notify предоставляет способ для разработчиков приложений указывать URL, к которому должна быть послана HTTP-команда POST при успешной установке. Разработчики могут задавать значение этого атрибута. Иногда это значение будет задавать инициализирующее программное обеспечение, поскольку диспетчер инициализации лучше знает URL, который он установил для отслеживания установок.

Успешная установка подразумевает успешную загрузку. Когда установка завершена, пользователи могут выполнить приложение. Поэтому уместно потребовать оплату с пользователей за программное обеспечение при подтверждении установки. Конечно, некоторые приложения могут оплачиваться пользователями после первого использования, независимо от того, когда приложение было загружено. Здесь важно отметить, что устройство, а не приложение, чаще всего должно выполнять подобное подтверждение.

После уведомления система инициализации может генерировать событие создания счета. Обратите внимание, что подтверждение установки отличается от подтверждения покупки.

Генерирование события оплаты

Пользователи должны оплачивать использование услуг. Счет — это список всех расходов, который представляется потребителю к оплате. Событие выдачи счета — это уведомление о необходимости произведения оплаты.

Успешная загрузка может представлять собой событие, подлежащее оплате за программное обеспечение, которое необходимо купить за плату. При выполнении и уведомлении об успешной загрузке приложения пользователем система инициализации генерирует событие выдачи счета. Событие выдачи счета пересылается системой организации счетов. Система организации счетов обычно представляет собой независимую систему, управляемую транспортировщиком, с которым взаимодействует система инициализации.

Системы инициализации поддерживают различные модели формирования счетов. Разнообразные модели генерируют различные типы информации о событиях выдачи счетов, которая представляет собой разные схемы оплаты. В следующем списке представлены некоторые возможные схемы оплаты:

— оплата за загрузку приложения; оплата за установку;

— оплата за запуск приложения; оплата за определенное время использования;

— оплата за определенное количество раз использования.

Как разработчик вы должны предусмотреть, какие схемы оплаты предпочтительнее для вас — и какие из них представлены на рынке. Информация дескриптора вашего приложения должна отражать ваши предпочтения в формировании счетов и оплате в виде информации, которую вы поставляете во время регистрации приложения.

Системы инициализации используют различные схемы для пересылки информации о событии выдачи счета системам организации счетов. Одна из схем заключается в пересылке каждого события при его осуществлении. Другой метод — сбор групп событий выдачи счетов и пересылки их как пакета для групповой обработки системой организации счетов. Групповая обработка счетов может выполняться периодически тем же образом, как обычно поставщики услуг осуществляют работу со счетами.

Обновление приложения — это процесс обновления приложения, которое уже находится на устройстве, на более новую версию. В соответствии с приложением «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated

Provisioning) спецификации MIDP для поддерживания обновлений уже установленных на устройства приложений требуется система инициализации ОТА. Вы найдете ссылку на этот документ в разделе «Ссылки» в конце данной книги.

Программное обеспечение пользовательского агента устройства и программное обеспечение диспетчера инициализации использует обязательный атрибут MIDlet-Version файла JAD приложения для согласования обновления приложения. Кроме того, дескриптор приложения должен однозначно идентифицировать набор МГО-летов, который должен быть загружен, так чтобы устройство могло определять, должно ли оно выполнять обновление или новую установку. Разработчики должны убедиться, что они поставляют правильную информацию о версии MID-лета и идентификации набора MID-летов.

С точки зрения диспетчера инициализации, удаление приложения — это процесс получения уведомления о том, что приложение было удалено с устройства. AMS устройства заботится о самом удалении наборов приложений с устройства самостоятельно.

Разработчикам не нужно предусматривать уведомление сервера об удалении приложения. В этот процесс вовлечены только агент пользователя и сервер. Разработчики должны, однако, предусмотреть вероятность необходимого удаления приложения на клиенте при подготовке файла JAD приложения. Атрибут MIDlet-Delete-Conf irm является необязательным атрибутом файла JAD. Цель — предоставить AMS текстовое сообщение, предоставляемое пользователю для подтверждения удаления связанного набора MID-летов.

Диспетчеры инициализации, которые получают и сохраняют информацию об удалении приложений, могут предложить более гибкие сценарии инициализации. Например, пользователь. может захотеть удалить приложение с устройства, чтобы освободить память для другого приложения. Однако пользователь, возможно, захочет сохранить лицензию для первого приложения. Если диспетчер инициализации отслеживает эту информацию, он может проигнорировать этапы приобретения лицензии, оплаты и подтверждения в следующий раз, когда пользователь будет загружать первоначальное приложение.

Илон Маск рекомендует:  Что такое код asp getlistindex

Подготовка приложений к системам инициализации

Подготовка приложений к использованию в системах инициализации заключается в предоставлении всех обязательных файлов приложения и обеспечении того, что они содержат информацию, требуемую в процессе инициализации. Основная задача этой подготовки — этв правильное создание файла дескриптора приложения (JAD) и файла приложения JAR.

Файл JAD является основным механизмом предоставления определяемой приложением информации как клиенту, так и серверу. Файл JAD может сопровождать каждый файл JAR приложения. Система инициализации извлекает и использует информацию из этого файла во время различных этапов процесса инициализации. Файл JAD может быть сохранен как часть файла JAR приложения, или он может быть сохранен отдельно для более легкого извлечения. Одно основное преимущество поставки файла JAD отдельно от файла JAR заключается в том, что диспетчер инициализации может получать атрибуты приложения без открытия файла JAR. В таблице 10.1 перечислены все атрибуты MID-лета, относящиеся к инициализации.

Таблица 10.1. Атрибуты MID-лета, связанные с инициализацией приложения

Название атрибута MID-лета — Описание — Наличие

MIDiet- Delete-Confirm — Определяет текстовое сообщение, которое должно быть представлено пользователю для подтверждения удаления набора MID-летов. Используется для уведомления пользователей во время работы AMS с приложением для того, чтобы освободить место для установки MID-лета — Необязателен

MIDlet-Description — Определяет текстовое описание набора MID-летов. Используется для представления описания пользователю во время обнаружения — Необязателен

MIDlet-Install-Notify — Определяет LJRL, на который пересылается отчет о состоянии установки MID-лета через HTTP-запрос POST — Необязателен

MIDlet-Jar-Size — Показывает размер (в байтах) файла JAR MID-лета. Используется AMS для определения того, содержит ли устройство достаточно общей памяти для установки набора MID-летов — Обязателен

MIDlet-Name — Определяет название набора MID-летов. Используется для предоставления названия набора MID-летов пользователям — Обязателен

MIDlet-Vendor — Определяет название поставщика набора MID-летов — Обязателен

MIDlet-Version — Используется для перемещения приложения — Обязателен

Как среда клиента, так и среда сервера используют файл JAD. Диспетчер инициализации использует его во время инициализации, а клиент использует во время установки и исполнения приложения. Во время инициализации сервер инициализации посылает файл JAD на устройство, где программное обеспечение агента пользователя использует его для подтверждения того, что набор MID-летов совместим с устройством, до загрузки файла JAR всего набора MID-летов. Во время исполнения, как вы узнали из главы 3, AMS использует информацию, представленную в файле JAD, для управления жизненным циклом приложения. Кроме того, AMS делает информацию файла JAD доступной MID-летам набора MID-летов для использования во время выполнения МЮ-лета.

Атрибут MIDlet-Install-Notify является необязательным атрибутом файлов JAD и manifest, который используется для инициализации. Его цель — дать программному обеспечению агента пользователя стандартный механизм передачи состояния установки в службу, предоставляющую набор MID-летов.

Значение атрибута MIDlet-Install-Notify должно описывать URL, на который агент пользователя посылает HTTP-запрос POST, содержащий информацию о состоянии установки. Посылать полный запрос POST в соответствии с рекомендациями приложения «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated Provisioning) спецификации MIDP входит в обязанности агента пользователя. То есть агенту пользователя необходимо получить некоторую информацию о приложении от AMS и включить ее — возможно, как параметры HTTP, — в запрос POST.

URL предоставляют некоторые программы систем инициализации, за исключением URL для определяемых приложением параметров, которые может предоставлять только AMS. Основная причина такой политики заключается в том, что программное обеспечение инициализации знает URL, который оно использует для сбора информации об установке, и оно может облегчить ношу разработчика, которому приходится разыскивать и предоставлять строку URL в каждом файле JAD. Разработчики должны знать о том, записывает ли система инициализации этот атрибут в файл JAD набора MID-летов. Если нет, разработчик должен включить этот атрибут в файл JAD.

Хорошей идеей является обеспечение того, что дескрипторы вашего приложения определяют значение атрибута MIDlet-Install-Notify, чтобы агент пользователя мог выдать состояние установки даже в случаях, когда набор MID-летов не был извлечен. Например, возможно, что URL, который определяет местоположение файла JAR и является значением атрибута MIDlet-Jar-URL, неправилен.

Инициализация приложений — это процесс поставки программного обеспечения на устройства. Инициализация не ограничивается беспроводными сетями, J2ME или даже приложениями Java. Тем не менее, системы инициализации стали важным компонентом, поддерживающим установку приложений J2ME, особенно в сфере инициализации ОТА приложений MIDP.

Процесс инициализации включает много этапов, среди которых регистрация приложений в системе инициализации и обнаружение, выбор, покупка, загрузка, установка и подтверждение установки программного обеспечения. Цель систем инициализации заключается в облегчении прохождения этих этапов и автоматизации процесса настолько, насколько это возможно для предоставления более совершенных возможностей и безошибочной работы.

Поскольку системы инициализации автоматизируют большую часть процесса инициализации, они хорошо подходят для беспроводных сетей. Они смягчают многие трудности и автоматизируют многие этапы, включенные в инициализацию приложений на устройствах с ограниченными пользовательскими интерфейсами через беспроводные соединения.

Системы инициализации являются комплексными корпоративными приложениями, которые обычно интегрируются в сеть беспроводного транспортировщика. Они предоставляют услуги инициализации для беспроводных подписчиков. Ключевым моментом для разработчиков приложений является подготовка своих приложений MIDP для использования в системах инициализации, поддерживаемых транспортировщиками, у которых их приложения будут зарегистрированы. Понимание сущности интерфейсов, свойств и возможностей системы инициализации, с которой вы будете взаимодействовать, важно. Как разработчик приложения, вы должны быть способны предоставить всю информацию, необходимую системе инициализации, для того чтобы вы могли извлечь из нее максимально возможные преимущества.

Системы инициализации поддерживают многие другие свойства, которые не были обсуждены в данной главе. Многие из этих свойств прозрачны для разработчика приложений, в том смысле, что разработчику не приходится ничего делать для регулировки этих аспектов работы системы инициализации. Многие из них не влияют на приложение. Или они просто обращаются к функциям, которые не зависят от вопросов разработки, конфигурирования или установки приложения.

Инициализация файла.

Дата добавления: 2013-12-23 ; просмотров: 1283 ; Нарушение авторских прав


End.

Begin

Примеры логические устройства.

End.

Begin

assign (ft, ‘123.dat’); – диск и каталог по умолчанию, установленные до начала работы программы

assign (fi, ‘c:\int\chisla.dat’);

Стандартные аппаратные средства ПК, такие как клавиатура, дисплей, принтер и коммуникационные каналы ввода-вывода, определяются в Турбо Паскале специальными именами, которые называются логическими устройствами. Все они в Турбо Паскале рассматриваются как потенциальные источники или приемники текстовой информации.

CON – логическое имя, которое определяет консоль – клавиатуру или экран дисплея. Турбо Паскаль устанавливает различия между этими физическими устройствами по направлению передачи данных: чтение данных возможно только с клавиатуры, а запись – только на экран. Таким образом, с помощью логического устройства CON нельзя, например, прочитать данные с экрана ПК, хотя такая аппаратная возможность существует.

Ввод с клавиатуры буферируется: символы по мере нажатья на клавиши помещаются в специальный строковый буфер, который передается программе только после нажатия клавиши Enter. Буферизация ввода обеспечивает возможность редактирования вводимой строки стандартными средствами ДОС. При вводе символов осуществляется их эхо-повтор на экране ПК. В Турбо Паскале можно прочитать любой символ клавиатуры, в том числе и символ CR, вырабатываемый клавишей Enter, сразу после нажатия на соответствующую клавишу без эхо-повтора.

PRN– логическое имя принтера. Если к ПК подключено несколько принтеров, доступ к ним осуществляется по логическим именам LPT1, LPT2 и LPT3. Имена PRN и LPT1 первоначально – синонимы. Средствами ДОС можно присвоить имя PRN любому другому логическому устройству, способному принимать информацию.

Стандартный библиотечный модуль PRINTER, входящий в библиотеку TURBO.TPL, объявляет имя файловой переменной LST и связывает его с логическим устройством LPT1. Это дает возможность использовать простое обращение к принтеру. Например, программа

Writeln(Lst, ‘Привет мир!’);

Выведет на принтер фразу «Привет мир!», а все необходимые операции по открытию логического устройства выполнит библиотечный блок PRINTER.

Связь логического устройства с файловой переменной осуществляется процедурой ASSIGN, например:

Var fo:text;

Турбо Паскаль никогда не связывает имена логических устройств с дисковыми файлами, поэтому эти имена можно считать зарезервированными. Иными словами, нельзя, например, обратиться к дисковому файлу с именем PRN, т. к. Турбо Паскаль всегда интерпретирует такой запрос как обращение к принтеру.

Инициализировать файл означает указать для этого файла направление передачи данных. В Турбо Паскале можно открыть файл для чтения, для записи, а так же для чтения и записи одновременно.

RESET ( );

Файловая переменная должна быть связана процедурой ASSIGN с уже существующим файлом или логическим устройством приемником информации.

При выполнении этой процедуры дисковый файл или логическое устройство подготавливается к чтению информации. В результате специальная переменная — указатель, связанная с этим файлом, будет указывать на начало файла, т.е. на компонент с порядковым номером 0.

REWRITE( );

инициирует запись информации в файл или логическое устройство, связанное ранее с файловой переменной. Процедурой REWRITE нельзя инициировать запись информации в ранее существующий дисковый файл: при выполнении этой процедуры стандартный файл уничтожается и никаких сообщений об этом в программу не передается. Новый файл подготавливается к приему информации и его указатель принимает значение 0.

APPEND( );

инициирует запись в ранее существующий текстовый файл для его расширения, при этом указатель файла устанавливается в его конец. Процедура APPEND применима только к текстовым файлам, т.е. их файловая переменная должна быть типа TEXT. Если текстовый файл ранее был открыт с помощью Reset или Rewrite, использование Append приведет к закрытию этого файла и открытию его вновь, но уже для добавления записей.

После работы с файлом необходимо закрыть файл с помощью процедуры

CLOSE ( ); Эта процедура ставит специальную метку конца файла, что в большинстве случаев является просто необходимым.

Система инициализации

(Описание системы и некоторых возможных действий для начинающего линуксоида.)

При запуске компьютера ядро проверяет процессор и память, обнаруживает и отчасти настраивает прочие устройства, монтирует корневую файловую систему, запускает систему инициализации.

«Система инициализАции» в UNIX и Linux — набор программ для управления формированием рабочей среды: текстовое/графическое рабочее окружение или служебный узел вычислительной сети. Традиционное имя основной программы — init («инИт»). Её P >

Для Linux есть три основных системы инициализации (по старшинству): System V Init, Upstart, systemd — и ёще несколько менее распространённых.

Система System V Init (сокращённо Sysvinit) унаследована от UNIX пятой (V) версии. Система Upstart создана для Ubuntu Linux и была ненадолго принята также в Red Hat Enterprise Linux. Система systemd — наиболее новая, набирающая популярность, на основе идей программы launchd из операционной системы Mac OS.

Для операционной системы достаточно одной системы инициализации, но для совместимости (поддержания работоспособности старых программ) в инсталляции может быть одна основная система с элементами другой.

Рабочая среда может состоять из большого числа процессов. Систему инициализации настраивают так, чтобы запустить все необходимые процессы в нужном порядке. Предполагаемый результат называют «уровнем запуска» (runlevel) в Sysvinit и Upstart или «целью» (target) в systemd. Выключение компьютера и перезапуск операционной системы тоже считаются результатами — здесь тоже нужно соблюсти правильную последовательность действий и дать завершаемым процессам возможность сохранить свои данные.

Многие программы, формирующие рабочую среду, специально разработаны или настроены для работы в фоне, например: диспетчер электропитания acpid, диспетчер сети NetworkManager, служба точного времени ntpd, служба наблюдения за исправностью дисков smartd. В сочетании с файлами инициализации эти фоновые программы называют «дЕмонами» (daemon, «дИмон»), «службами» или «сервисами» (service, «сЁрвис»). Часто имя заканчивается на d (от daemon).

Система Sysvinit запускает и останавливает демонов в заданном пользователем/администратором порядке; Upstart — формирует «дерево» откликов на «события» (обнаружение устройства, монтирование, запуск демона — могут быть событиями, требующими реакции в виде запуска другого демона); systemd — при запуске рассчитывает «дерево» зависимостей демонов друг от друга и запускает демонов по возможности параллельно.

Кроме init в системе инициализации есть файлы настройки демонов (файлы инициализации) и управляющие программы самой системы.

Файлы инициализации — текстовые, со специальным синтаксисом (своим для каждой системы). Для Sysvinit они располагаются в каталогах /etc/rc*.d/ (вместо звёздочки — число или ничего), /etc/conf.d/ и ещё есть файл /etc/inittab; для Upstart — /etc/init/ и /etc/init.d/ и файл inittab; для systemd — /lib/systemd/, /run/systemd/ и /etc/systemd/. Какая-то часть файлов является сценариями командной оболочки. Уровень запуска или цель systemd можно воспринимать как набор файлов инициализации, и система должна их выполнить (запустив соответствующие программы). Особенно много файлов — у systemd, отчасти она сама их создаёт.

Традиционный список уровней запуска:

0 — остановка системы (завершение процессов из user space, остановка работы ядра, и, если возможно, отключение электропитания);

1 — однопользовательский режим (доступна командная строка, нет сети, обычно используется как аварийный);

2 — многопользовательский режим (доступна командная строка, нет сети);

3 — многопользовательский режим (доступна командная строка, возможна сеть);

4 — не используется;

5 — многопользовательский режим (доступны и командная строка, и GUI, возможна сеть);

В разных инсталляциях уровни запуска могут быть настроены иначе. В домашней системе обычно автоматически установлен уровень или цель, соответствующий традиционному 5. В Upstart уровень 2 соответствует традиционному 5; дополнительно есть обозначения N — «предыдущий неизвестен» и S — 1 (от single user). В systemd есть цели shutdown (примерно соответствует уровню 0); basic (1); multi-user (3); graphical (5).

Обычно поставляются готовые файлы инициализации, поэтому инсталляция Linux уже предоставляет готовую рабочую среду. Нередко функциональность уровня запуска или цели оказывается немного избыточна, поэтому приходится отключать лишних демонов — просто чтобы сэкономить системные ресурсы.

Типичные действия: посмотреть список работающих демонов; запустить/остановить/перезапустить демона. Запускать демона прямой командой или останавливать его командой kill считается неправильным — есть специальные управляющие программы. Для Sysvinit это chkconfig, service и другие; для Upstart — initctl и другие; для systemd — systemctl. В инсталляциях с элементами других систем инициализации могут работать программы каждой системы. В systemd файлы инициализации имеют особые расширения («.service», «.target», . ), которые в команде указывать не обязательно; здесь они приводятся для уточнения, с чем именно команда имеет дело.

Если указаны только две команды, то первая — для Sysvinit и Upstart. Вместо имени указано слово «daemon».

Узнать, запущен ли определённый демон:

service daemon status

initctl status daemon или initctl —system status daemon

systemctl status daemon.service

Посмотреть список работающих демонов:

initctl list или initctl —system list

systemctl —all или systemctl list-units —all

service daemon start

start daemon или initctl start daemon

systemctl start daemon.service

service daemon stop

stop daemon или initctl stop daemon

systemctl stop daemon.service

service daemon restart или service daemon condrestart

restart daemon или initctl restart daemon

systemctl restart daemon.service или systemctl condrestart daemon.service

Или, если возможно, заставить демона перечитать свои настройки (это быстрее, чем полный перезапуск):

service daemon reload

reload daemon или initctl reload daemon

systemctl reload daemon.service

Если файл настройки демона — сценарий оболочки, то можно запустить в командной строке сам сценарий с аргументом start, stop или иным (изучите содержимое сценария и попробуйте догадаться).

Включить демона (автозапуск):

chkconfig daemon on

вернуть исправления (см. ниже, как отключить демона)

systemctl enable daemon.service

Проверить, отмечен ли демон как включённый:


initctl show-config daemon и см. ниже, как отключить демона

systemctl is-enabled daemon.service

Отключить демона (никогда не запускается):

chkconfig daemon off

убрать расширение «.conf» соответствующего файла или корректно исправить содержимое

systemctl disable daemon.service

Узнать текущий уровень запуска или цель:

systemctl list-units *target

Установить уровень запуска/цель по умолчанию:

во фрагменте id:5:initdefault файла /etc/inittab установить нужный номер

во фрагменте env DEFAULT_RUNLEVEL=2 файла /etc/init/rc-sysinit.conf установить нужный номер

systemctl set-default graphical.target или

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Перейти сейчас на другой уровень запуска/цель:

init 3 или telinit 1

systemctl isolate multi-user.target

В том числе выключить компьютер:

halt, или poweroff, или «shutdown -h now»

systemctl halt или systemctl poweroff

Или перезапустить операционную систему:

reboot или «shutdown -r now»

Выбирать демонов для отключения следует очень осторожно. Ошибка может привести к неработоспособности всей рабочей среды (это обнаружится сразу или при следующем включении компьютера). Относительно безвредно — попробовать для тренировки отключить сервис печати cups, сервис сканирования saned, службу точного времени ntpd.

Программы для GUI: Services Configuration Tool (system-config-services) для Sysvinit, Boot-Up manager (bum) для Sysvinit и Upstart, systemadm для systemd. Псевдографическая ntsysv для Sysvinit.

Процесс init является корневым предком всех процессов, кроме ядерных потоков. Поэтому в задачи init дополнительно входит «усыновление» процессов-сирот (orphan process) и их завершение.

Системы инициализации Linux

В операционной системе Linux и других системах семейства Unix после завершения загрузки ядра начинается инициализация Linux системы, сервисов и других компонентов. За это отвечает процесс инициализации, он запускается ядром сразу после завершения загрузки, имеет PID 1, и будет выполняться пока будет работать система.

Процесс инициализации запускает все другие процессы, которые должны быть запущены, это родительский процесс для всего, что выполняется в системе. Другие процессы могут тоже создавать дочерние процессы, но если родительский процесс завершается, для его дочерних процессов родительским становится процесс инициализации.

За время развития операционных систем были созданы различные системы инициализации Linux. В разных дистрибутивах использовались разные системы. В этой статье мы рассмотрим лучшие системы инициализации, которые вы можете сейчас использовать. Мы начнем с более старых систем с меньшим функционалом, чтобы понять с чего все начиналось, затем подойдем к более новым, созданным в последнее время.

1. System V Init

System V или SysV — это довольно старая, но до сих пор еще популярная система инициализации Linux и Unix подобных операционных систем. Она была основой для создания многих других систем инициализации, а также первой коммерческой системой инициализации разработанной для Unix в AT&T. Она была разработана еще в 1983 году.

Почти все дистрибутивы Linux изначально использовали SysV. Исключением была только Gentoo, в которой использовалась собственная система инициализации и Slackware, с инициализацией в стиле BSD.

Основные возможности SysV:

  • Написание файлов запуска служб на bash;
  • Последовательный запуск служб;
  • Сортировка порядка запуска с помощью номеров в именах файлов;
  • Команды для запуска, остановки и проверки состояния служб.

Никакой параллельной загрузки, системы зависимостей, запуска по требованию и автоматического запуска здесь не было и в помине.

С момента ее разработки прошло много лет и из-за некоторых недостатков были разработаны другие системы для ее замены, они хоть и имели новые функции и были более эффективны, но они были по-прежнему совместимы с SysV.

2. OpenRC

OpenRC — это система инициализации Linux и Unix подобных операционных систем совместимая с Sys V Init и поддерживающая систему зависимостей во время запуска. Она приносит некоторые улучшения в SysV, и как и другие системы инициализации Linux, совместима с ней, но вы должны иметь в виду, что OpenRC не заменяет полностью файл /sbin/init. Эта система инициализации используется в Gentoo и дистрибутивах BSD.

Кроме стандартных возможностей SysV, здесь поддерживается также:

  • Поддержка зависимостей служб;
  • Поддержка параллельного запуска служб;
  • Поддерживает настройку в одном отдельном файле;
  • Работает как демон;

По сравнению с SysV тут появилось много новых возможностей, но все еще не все те, что нужны для оптимальной работы системы.

3. Systemd

Systemd — это новая система инициализации Linux. Она была введена по умолчанию в Fedora 15, а сейчас используется почти во всех популярных Linux дистрибутивах. Это не только инициализирующий процесс, поддерживающий огромное количество возможностей, но и набор инструментов для управления службами и этими возможностями из системы. Основная цель — иметь полный контроль над всеми процессами во время их запуска и на протяжении всего выполнения.

Systemd очень сильно отличается от всех существующих систем инициализации, тем как она работает с сервисами, и даже конфигурационными файлами сервисов. Совместимости со скриптами SysV нет, их нужно преобразовать в linux systemd unit файлы.

Вот ее основные особенности:

  • Понятный, простой и эффективный дизайн;
  • Параллельная загрузка служб на основе зависимостей;
  • Лучший APIv;
  • Поддерживается завершение дополнительных процессов;
  • Поддерживается собственный журнал с помощью journald;
  • Поддерживается планирование заданий с помощью таймеров Systemd;
  • Хранение журналов в бинарных файлах;
  • Сохранение состояния сервисов linux systemd для возможного восстановления;
  • Улучшенная интеграция с Gnome;
  • Запуск сервисов по требованию;

4. Upstart

Upstart — это система инициализации на основе событий, разработанная в Canonical и призванная заменять SysV. Она может запускать системные службы, выполнять над ними различные задачи, инспектировать их во время выполнения, а также выполнять нужные действия в ответ на события в системе.

Это гибридная система инициализации, она использует как SysV скрипты запуска, так и файлы служб Systemd. Вот ее самые заметные особенности:

  • Изначально разработанная для Ubuntu, но может использоваться и в других дистрибутивах;
  • Запуск и остановка служб на основе событий;
  • Генерация событий во время запуска и остановки служб;
  • События могут быть отправлены обычными процессами;
  • Связь с процессом инициализации через DBus;
  • Пользователи могут запускать и останавливать свои процессы;
  • Перезапуск служб, которые неожиданно завершились;
  • Параллельная загрузка сервисов;
  • Автоматический перезапуск служб;

Большинство ее возможностей работают благодаря интеграции с системой инициализации Systemd.

5. Runinit

Runinit — это кроссплатформенная система инициализации, которая может работать в GNU Linux, Solaris, BSD и MacOS. Это отличная альтернатива для SysV с поддержкой мониторинга состояния служб.

Здесь есть некоторые интересные особенности, которых нет в других системах инициализации:

  • Полный контроль сервисов, каждый сервис привязывается к своему каталогу;
  • Надежное средство журналирования и ротации логов;
  • Быстрая система загрузки и выключения;
  • Портативность;
  • Легкое создание файлов конфигурации служб;
  • Небольшое количество кода системы инициализации.

Выводы

Как я уже говорил, система инициализации запускает и управляет всеми другими процессами в системе Linux. SysV до недавнего времени была основной системой инициализации в большинстве дистрибутивов Linux, но из-за некоторых своих недостатков для нее было разработано несколько замен, в том числе Systemd.

Какие системы инициализации Linux используются в вашем дистрибутиве? В списке обозначены не все существующие системы, какую из них нужно добавить в список? Напишите в комментариях!

SystemV и BSD стили. Структура, стартовые сценарии, настройки

Серия контента:

Этот контент является частью # из серии # статей: Программная реализация системы инициализации в Linux

Этот контент является частью серии: Программная реализация системы инициализации в Linux

Следите за выходом новых статей этой серии.

Исторически сложилось так, что традиционно в среде UNIX существуют две системы инициализации – SystemV и BSD. Система инициализации представляет собой набор скриптов (сценариев), которые выполняются при старте системы. Отличие между ними состоит в принципах построения – названии, расположении в файловой системе, назначении и методах конфигурирования. В Linux традиционно получила большее распространение система инициализации SystemV, и она же реализована в большинстве его самых распространенных дистрибутивов.

При старте PC-совместимого компьютера происходит такая последовательность действий. Сначала выполняется программа BIOS компьютера, затем запускается на выполнение системный загрузчик – grub, lilo или любой другой. После этого загружается ядро Linux и запускается на выполнение первый и основной системный процесс init, прародитель всех процессов. Это общее описание того, что происходит в системе при ее старте, а детальный порядок выполнения тех или иных действий во многом зависит от самой системы и конфигурации программы init.

После старта ядро линукс монтирует корневую файловую систему (как правило, в режиме «только для чтения») и именно поэтому программа init может прочитать свой конфигурационный файл и приступить к работе. Ее конфигурационный файл находится в файле /etc/inittab. В связи с необходимостью получения доступа к конфигурационному файлу программы init и стартовым скриптам в самом начале запуска системы, каталог /etc никогда не выполняется в виде отдельного раздела, а располагается на корневом, который первым и монтируется.

Рассмотрим систему инициализации SystemV.

Система инициализации SystemV

Идеология SystemV пронизана понятием уровней исполнения, которых в численном измерении бывает от 0 до 6. Считается, что система в каждый конкретный момент времени может находиться на каком-то определенном уровне исполнения. Поэтому процесс init начинает свою работу, считывая заданный уровень и выстраивая свою дальнейшую последовательность действий в соответствии с ним.

Системный администратор может самостоятельно, при помощи программы init, изменять уровень исполнения, задав его в качестве параметра процессу init. Соответствие между уровнем исполнения и состоянием системы следующее:

  • 0 – выключение системы (halt);
  • 1 или S – однопользовательский режим; служит для решения системных задач администратором;
  • 2 – почти полный аналог третьему уровню, но без поддержки NFS;
  • 3 – многопользовательский режим. Является обычным режимом при работе системы в режиме сервера;
  • 4 – не используется;
  • 5 – система стартует с поддержкой графического режима. Является штатным режимом для рабочих станций;
  • 6 – инициализирует перезагрузку системы (reboot).


Используя init, системный инженер может остановить систему, переведя ее на нулевой уровень, введя init 0 в консоли или перегрузить систему, введя init 6.

Структура файла /etc/inittab

Структура конфигурационного файла inittab в общем виде такова:

  • id – идентификатор, представленный одним или двумя символами;
  • run_level – список уровней исполнения, на которых возможно исполнение программы (может быть пустым);
  • action – определяет нюансы исполнения программы (допускается использование только определенных служебных слов);
  • process – программа, которая будет выполняться.

Некоторые служебные слова, используемые в поле action:

  • Initdefault – определяет уровень исполнения по умолчанию. Будет использоваться именно этот уровень при загрузке системы.
  • Wait – процесс будет запущен один раз. Init будет ожидать завершения этого процесса, а затем начнет выполнение следующих программ по списку.
  • Sysinit – процесс будет выполняться самым первым при запуске системы, и init будет ожидать его завершения, прежде чем начнет выполнение других программ по списку.
  • Once – программа запускается один раз и init не ждет ее завершения.
  • Ctrlaltdel – комбинация нажатых клавиш, определяющая программу, которая будет запущена при нажатии этой комбинации (если эту позицию в файле закомментировать, то эта комбинация вообще работать не будет, и систему нельзя будет перезагрузить таким образом).
  • Powerfail – определяет процесс, который будет запущен при обнаружении процессом init сигнала восстановления питания после его сбоя.
  • Respawn – запускает процесс. Init не ожидает его завершения и обрабатывает следующие по списку строки. Если процесс завершится самостоятельно, то init запустит его вновь.

Рассмотрим отдельные строки из конфигурационного файла /etc/inittab.

id:3:initdefault : говорит о том, что уровень выполнения по умолчанию будет третий, т.е. система стартует в многопользовательском режиме без поддержки графического интерфейса и самое главное, – после чтения этой строки init будет читать и исполнять только те строки, в поле runlevel которых находится цифра 3, а все остальные строки будут игнорироваться.

si::sysinit:/etc/rc.d/rc.sysinit : процесс init запустит программу /etc/rc.d/rc.sysinit потому что в поле runlevel стоит ключевое слово sysinit. Init будет ожидать завершения выполнения этой программы.

Строка 10:0:wait:/etc/rc.d/rc 0 будет игнорироваться, потому что в поле, отвечающем за runlevel, нет цифры 3 (уровня запуска по умолчанию).

13:3:wait:/etc/rc.d/rc 3 будет запущена, потому что в поле runlevel есть цифра 3, и процесс init при этом будет ожидать ее завершения.

ca::ctrlaltdel:/sbin/shudown –t3 –r now : эта строка будет проигнорирована, но после ее прочтения init будет знать, что при получении сигнала от нажатых клавиш altctrldel необходимо будет перезагрузить компьютер.

pf::powerfail:/sbin/shutdown –f –h +2 “Power Failure; System Shutting Down” : эта строка тоже будет проигнорирована, но даст понять процессу init, что в случае сбоя питания необходимо выключить систему.

pr:12345:powerkwait:/sbin/shutdown –c “Power Restored; Shutdown Cancelled” : строка не исполняется процессом init, но дает ему знать о необходимости отменить выключение системы в случае восстановления сбоя питания.

запускают программу /sbin/mingetty, которая в свою очередь инициализирует консоль терминалов tty1-tty6. Процесс init запускает эти программы и не ждет их окончания, переходя к чтению других частей конфигурационного файла.

в этом случае строка игнорируется, так как в поле runlevel нет цифры 3.

Проанализировав конфигурационный файл, становится ясно, что система стартует на третьем уровне исполнения, и при этом процесс init запускает следующие файлы на выполнение:

При этом первые два файла являются shell script программами.

Начало загрузки системы

Как отмечалось, процесс rc.sysinit стартует первым независимо от уровня выполнения системы. Эта программа написана на shell script, и системный инженер может сам контролировать ее, внося свои изменения в ее содержимое. Программа выполняет следующие действия, которые и составляют первоначальную загрузку системы и ее инициализацию:

  • при использовании технологии initrd отключается каталог, используемый initrd, и освобождается память, отводимая изначально под RAM-диск (в оперативной памяти);
  • выводится на исполнение программа sysctl, которая конфигурирует некоторые свойства ядра системы;
  • выставляется системное время;
  • выставляется имя хоста;
  • загружаются модули для поддержки USB- и IEEE-устройств;
  • проверяются файловые системы;
  • проверенные файловые системы подключаются для использования;
  • если были назначены квоты, то они применяются;
  • подсоединяется swap;
  • если имеется, то включается программный RAID;
  • запускается программа hdparm, служащая для конфигурирования IDE-устройств.

После rc.sysinit происходит выполнение конфигурационных файлов каталога /etc/sysconfig, при этом файлы подключаются к основному скрипту при помощи оператора ‘.‘ (точка, заключенная в кавычки). В каталоге хранятся конфигурационные файлы системы инициализации и конфигурационные файлы стартовых скриптов. В этих файлах определяются различные переменные, а сами файлы можно подключать к скриптам с помощью оператора “.” . Важно не путать конфигурационные файлы программ и конфигурационные файлы стартовых скриптов этих программ. Например, для Web-сервера Apache конфигурационный файл находится в /etc/httpd/httpd.conf, а файл, отвечающий за опциональный запуск самого Web-сервера, находится в /etc/rc.d/init.d/httpd и служит для передачи специальных параметров запуска демону httpd. Существующая документация, описывающая файлы в системном каталоге /etc/sysconfig, должна находиться в каталоге /usr/share/doc/initscripts-version. В файле sysconfig.txt описаны переменные и их значения.

Илон Маск рекомендует:  Что такое код bindtextdomain

Имя машины, например, берется из файла /etc/sysconfig/network и определяется через переменную HOSTNAME. Подключение файла network имеет следующий вид:

причем сначала проверяется, имеется ли вообще этот файл в системе, и только если он существует, он подключается. После его подключения в скрипте можно использовать переменные, находящиеся в network. Имя хоста определяется путем вызова функции:

причем все функции, которые могут использоваться в стартовых скриптах, находятся в файле /etc/rc.d/init.d/functions. Файл для hostname подключается так же, как и предыдущий, – путем указания строки

В самих скриптах наличие /etc/rc.d/init.d/functions не проверяется, он должен быть там по определению.

После выполнения первоначальной работы rc.sysinit по загрузке системы, в зависимости от уровня исполнения, запускается программа rc, которой в качестве параметра передается номер уровня исполнения. Ее основная функция – запуск и останов тех служб, которые должны быть запущены или остановлены исходя из требуемого уровня.

В системе инициализации BSD могут присутствовать подобные rc.sysinit скрипты, но аналога файла rc там нет. Файл rc, организация каталогов стартовых скриптов и особенности их написания для запуска и останова служб определяют стиль инициализации SystemV и отличают его от BSD-стиля.

В каталоге /etc/rc.d находятся файлы и другие каталоги, влияющие на порядок запуска тех или иных служб. Задача программы rc заключается в переходе в каталог rc с соответствующим уровнем исполнения и запуске всех файлов, начинающихся на K (с передачей им параметра “stop” ). Затем происходит запуск всех файлов, начинающихся на S с передачей им параметра “start” .

Все файлы, которые находятся в каталоге /etc/rc.d/init.d, являются стартовыми скриптами определенных программ. Эти программы должны поддерживать как минимум два параметра – start и stop , которые определяют их старт и останов.

Администратор может самостоятельно менять программы, предназначенные для старта или останова путем добавления или удаления из каталога этого уровня исполнения ссылок на стартовые скрипты программ.

Применение стартовых скриптов в администрировании системы

Для применения стартового скрипта вручную необходимо в консоли дать команду на запуск этого скрипта и указать полный путь к нему. В этом случае в качестве параметра передаются аргументы start или stop или какие либо другие, определенные в самом скрипте. Например, для запуска поддержки сети необходимо дать на исполнение следующую команду:

а для ее останова команду:

При этом перезапуск сети осуществится командой:

Рассмотрим применение изложенного материала на практике. При работе иногда может быть утрачен (или забыт) пароль суперпользователя. В старых системах его было легко восстановить – достаточно было перейти в однопользовательский режим (уровень исполнения 1 или S), и система уже предоставляла консоль с правами root без запроса пароля. В современных дистрибутивах, как правило, при загрузке в однопользовательский режим сначала требуется ввести пароль суперпользователя, а уж затем предоставляется консоль со всеми правами. Поэтому используются другие подходы для решения этой задачи. Основная задача при смене пароля в современных системах с SystemV – получить возможность выполнять программы с привилегиями суперпользователя. Первый способ получить такую возможность – это загрузиться с внешнего носителя и, подключив файловую систему, в которой находится каталог /etc, удалить вручную файл shadow. После этого, при обычной загрузке, система не будет спрашивать пароль при входе под root (если система изначально не настроена на запрет входа пользователей без паролей).

Второй способ подразумевает использование опций ядра системы. Суть состоит в замене стандартной программы init на любую другую для быстрого старта интерпретатора bash. При этом механизмы, отвечающие за аутентификацию пользователя, включаться не будут, и можно будет сразу получить командную строку с привилегиями root.

Для изменения стартовой программы ядру надо передать нужную опцию в виде: init = /полный маршрут/к нужной программе/. Тогда, после старта, будет смонтирован только корневой каталог (поскольку не выполнялись скрипты инициализации) в режиме «только для чтения». Перемонтировав их в режим «чтения-записи» и вызвав программу passwd на исполнение, можно сменить пароль root.

Для этого в строке загрузчика, соответствующей ядру Linux, нужно добавить опцию:

После загрузки системы запустится интерпретатор bash c правами суперпользователя. Перемонтировав корневую файловую систему в режиме rw, нужно ввести команду passwd, т.е.:

затем сбросить буферы файловой системы на диск для синхронизации внесенных изменений командой sync и перезапустить компьютер командой reboot. После этого пароль для суперпользователя будет изменен.

Выводы

В статье изложены общие принципы систем инициализации SystemV и BSD. В Linux наибольшее распространение получила система SystemV.

BSD отличается от SystemV принципом построения стартовых скриптов, их названием, местоположением в файловой системе, назначением и способом конфигурирования.

Изложен порядок запуска PC-совместимого компьютера – от старта BIOS до запуска процесса init.

Описан процесс назначения и конфигурирования процесса init, его конфигурационного файла /etc/inittab, подробно описаны опции настройки.

Рассмотрена последовательность загрузки стартовых скриптов. Описана структура каталогов их хранения, конфигурационные файлы, способы подключения в основной скрипт, порядок загрузки системных служб.

Рассмотрены методы ручного управления стартовыми скриптами при решении задач администрирования системы.

Основываясь на изложенном материале, рассмотрены способы восстановления пароля суперпользователя системы в случае его утраты.

Как запустить программу без операционной системы: часть 5. Обращение к BIOS из ОС

Немного о прерываниях

Прерывание – это сигнал, сообщающий процессору о возникновении какого-либо события. Прерывания можно разбить на 2 группы:
• внешние прерывания – генерируются устройствами и другими процессорами;
• внутренние прерывания – генерируются процессором при возникновении каких-либо исключительных ситуаций (например, деление на 0 или обращение к недопустимым адресам) или инструкцией int.

В общем случае, после возникновения прерывания процессор должен передать управление обработчику прерывания, из таблицы, на которую указывает специальный регистр IDTR. В зависимости от режима работы процессора формат таблицы может отличаться и при вызове могут происходить дополнительные проверки на корректность прерывания.

После включения питания процессор начинает свою работу в режиме, очень похожим на Real Mode. Одним из этапов инициализации процессора является передача управления BIOS. BIOS настраивает некоторые регистры CPU, инициализирует оперативную память, выполняет проверку устройств POST, инициализацию базового оборудования, копирование загрузчика в память и передачу ему управления. Одним из шагов BIOS является настройка таблицы обработчиков прерываний, адрес которой хранится в IDTR. Обычно это 0x0. В реальном режиме работы процессора (Real Mode) запись в таблице прерываний состоит из пары sel:offset, которая содержит адрес обработчика прерывания. BIOS устанавливает собственные обработчики прерываний, что бы избавить операционную систему от низкоуровневой работы с аппаратурой, которая может отличаться от машины к машине.

Прерывания BIOS выступают в роли интерфейса для работы с оборудованием. К примеру, прерывание 0x13 используется для чтения секторов с дисков, прерывание 0х10 — для настройки видеорежимов. Для вызова прерываний BIOS’а, программа, работающая в Real Mode, может использовать ассемблерную инструкцию int. Например, чтобы прочитать сектор с диска, нужно использовать инструкцию int 0x13, с параметрами в регистрах общего назначения.

В реальном режиме работы процессор не может обращаться к памяти выше мегабайта, и у него отсутствуют механизмы для изоляции выполняющихся задач (кроме сегментации). Поэтому современные операционные системы для платформы x86 выполняются в других режимах работы процессора, таких как защищенный режим (Protected Mode) и длинный режим (Long Mode).

В защищенном режиме (Protected Mode) таблица прерываний выглядит иначе. На нее по-прежнему указывает регистр IDTR, но записью в этой таблице является Gate Descriptor одного из 3х возможных типов (читаем пункт 6.11 мануала Intel). Таблица прерываний должна настраиваться операционной системой, а не BIOS-ом, следовательно, в защищенном режиме нет возможности использовать прерывания BIOS’а. Вся работа с устройствами (HDD, CD-ROM, видеокарта…) ложится на плечи операционной системы, которая использует для этого драйвера. В длинном режиме (Long Mode) ситуация точно такая же, с точностью до размера Gate Descriptor’а.

Способы вызова BIOS’а из защищенного режима

Ну а что делать, если ядру ОС, работающему в защищенном режиме, все же нужно прочитать что-то с диска (например, драйвер жесткого диска), а драйвер еще не загружен? Сделать это можно двумя способами.
1. Настроить VirtualMode86 и выполнять обращения к BIOS’у в Protected Mode.
2. Перейти в RealMode, обратиться к BIOS’у, вернуться в Protected Mode.

Virtual Mode 86(VM86) – это еще один режим работы процессора, в котором сегментная адресация аналогична реальному режиму, но при этом работает страничная адресация (paging) защищенного режима. Мы будем использовать второй способ, так как, применяя подобную технику, можно обращаться к BIOS’у и из 64х битного кода (который выполняется в LongMode, не поддерживающем переход в VM86). Оставим работу с диском на потом, а сейчас определим размер оперативной памяти с помощью BIOS.

Строго говоря, есть еще третий способ вызова BIOS’a из защищенного 32-го режима, и именно его мы применили в третьей части нашей серии для использования VBE. Это выполнение 16-ти битного кода BIOS’a в 32-х битном эмуляторе. Этот способ плох тем, что будет трудно доставлять в эмулятор прерывания, генерируемые внешними устройствами. При определении размера оперативной памяти внешние устройства не используются, так как BIOS уже все определил на этапе своей загрузки, и нам бы подошел этот метод для выполнения поставленной задачи, но все же воспользуемся 2-м способом, так как этот код еще пригодится нам в последующих статьях.

Отдельно нужно отметить, что выбранный нами способ является очень медленным по сравнению с работой драйвера, так как тратит много времени на переключение между режимами CPU и не использует такие технологии, как MMIO и DMA. Помимо этого, векторы прерываний у всех устройств должны быть настроены именно так, как этого ожидает BIOS, что может не выполняться, если в системе для отдельных устройств уже работают драйвера. Уже запущенные драйвера, при подобной передаче управления BIOS’у, будут терять прерывания, что может привести к проблемам. Все это значит, что действовать описанным образом можно только в начале работы ОС.

Разбираемся со вторым способом

Итак, наша цель: определить размер оперативной памяти по таблицам e820, которые мы получим с помощью прерывания BIOS’а int 0x15. Таблицы e820 являются картой физической памяти, которая описывает, какие диапазоны физической памяти доступны для использования операционной системой. В недоступных регионах физической памяти хранится основной BIOS и BIOS видеокарты, таблицы ACPI, некоторые диапазоны физической памяти замаплены в память устройств и их регистров. Если в Windows 7 запустить монитор ресурсов, и открыть вкладку «память», то «зарезервированное оборудование» включает в себя объем физической памяти, перекрытый зарезервированными диапазонами.

Для получения записи из таблицы E820 нужно записать в регистры следующие значения: в EBX значение 0, в EAX значение 0xE820, в ECX – размер буфера (не меньше 20-ти байт), в EDX значение 0x534d4150, в ES:DI нужно записать указатель на буфер. После вызова прерывания int0x15 в буфер будет записана одна запись из таблицы e820, а значение в EBX увеличится на 1. Прерывания нужно повторять, пока EBX снова не станет равным 0, что означает конец таблицы. После этого в буфере окажутся все значения из таблицы. При успешном завершении Carry Flag в регистре Eflags будет сброшен, а в EAX будет записано значение ‘SMAP’. Запись таблицы имеет следующий формат:

Тип равен “1”, если физическую память может использовать менеджер памяти, “2” – если память зарезервирована для устройств или BIOS-а, “3” или “4” – если память используется ACPI. Остальные значения зарезервированы, диапазоны не пересекаются. Пример карты памяти:

Сразу оговоримся, что GRUB, который мы используем в качестве загрузчика, может предоставить уже готовую карту физической памяти, но цель данной статьи – продемонстрировать обращение к BIOS из защищенного режима, а не использование возможностей GRUB.

После запуска компьютера CPU работает в режиме RealMode, в котором и происходит передача управления BIOS’у. BIOS волен работать, как ему заблагорассудится, и может перейти в защищенный режим, как это делает, к примеру, Coreboot. Выполнив свою работу, BIOS загружает в память и передает управление первому сектору наиболее приоритетного устройства в соответствии с порядком загрузки (по крайней мере, если это hdd или устройство эмулируется как hdd). BIOS передает управление, будучи в RM. В нашем случае загрузка происходит с hdd и первым сектором оказывается MBR, передающий управление GRUB’у. GRUB в основном работает в PM, но при необходимости обратиться к оборудованию (например, прочитать сектор с диска) переходит в RM и использует прерывания BIOS’а. GRUB передает управление нашему ядру в PM. На рисунке ниже изображена описанная последовательность переходов CPU между режимами работы в процессе загрузки.

Для продолжения разговора и перехода непосредственно к коду нужно сделать небольшой теоретический отступ в сторону защищенного режима. Тема обширная и хорошо освещена, так что здесь будет описано только то, что чуть позже мы увидим в коде. Основное отличие между RM и PM заключается в механизмах сегментной адресации памяти. А что вообще такое сегментная адресация памяти? В RM для обращения к памяти используются адреса длиной в 20 бит, но длина доступных регистров ограничена 16-ю битами (из-за этого код и называется 16-ти битным). Поэтому для адресации используются пары регистров, один из которых содержит базу сегмента, а второй смещение. Линейный адрес получается путем сложения смещения и базы сегмента, сдвинутой влево на 4. Сегментная адресация в RM продемонстрирована на рисунке ниже.

Смещение может храниться в любом регистре общего назначения. База сегмента хранится в одном из следующих регистров: CS, DS, SS, ES, FS, GS. Эти регистры называются селекторами. Для всех команд определены селекторы по умолчанию. Для команд PUSH, POP это SS (сегмент стека), для JUMP, LOOP это CS (сегмент кода), для MOV это DS (сегмент данных).

В PM тоже используется сегментная адресация памяти, но механизм сильно изменился. Теперь селектор не сам хранит базу сегмента, а ссылается на дескриптор, который хранится в одной из таблиц дескрипторов. Структура селектора показана на рисунке ниже (и взята из мануалов Intel).

• RPL (Requested Privilege Level) –используется для разделения уровня привилегий в сегментном механизме защиты.
• TI – указывает на тип таблицы дескрипторов, в которой находится искомый дескриптор. 1 – LDT (Local Descriptor Table), 0 – GDT (Global Descriptor Table).
• Index – индекс дескриптора в таблице дескрипторов.


Существует 2 типа таблиц дескриптора – GDT и LDT. Таблица GDT одна на всю систему, таблиц LDT может быть много (к примеру, своя на каждый процесс). Мы будем использовать GDT, так как для использования LDT в любом случае пришлось бы настраивать GDT. Дескрипторы можно разбить на 2 группы: системные и пользовательские. Пользовательские дескрипторы отвечают за сегменты. Системные дескрипторы описывают переходы процессора между уровнями привилегий. В нашем коде не будет системных дескрипторов, так что о них говорить не будем. Структура пользовательского дескриптора, представленная ниже (также взята из мануалов Intel), наводит на мысль о том, как давно появилась архитектура x86, и сколько доработок ей пришлось перетерпеть.

Дескриптор сегмента определяет тип сегмента, размер, уровень привилегий, необходимый для доступа к нему, права на чтение, запись и исполнение, базу сегмента. Разберем структуру дескриптора.
• Base Address – это 32-х битный адрес первого байта сегмента, поле разбито на 3 части base_0_15, base_16_23, base_24_31.
• Segment Limit – размер сегмента в байтах, если флаг G = 0, или в блоках по 4Кб, если флаг G = 1.
• G (granularity) – если флаг выставлен, то Segment Limit измеряется в блоках по 4Кб, иначе в байтах.
• S (descriptor type) – если флаг выставлен, то дескриптор пользовательский, иначе системный. В нашем коде у всех дескрипторов этот флаг установлен.
• Type – интерпретация этого поля зависит от флага S. Для пользовательского сегмента возможны 2 основных варианта: сегмент кода и сегмент данных, это определяется старшим битом поля. В таблице ниже представлены все возможные комбинации.

Для сегмента данных определены следующие биты: E (expansion-direction), (W) write-enable, (A) accessed. Бит (W) позволяет писать в сегмент, (E) используется для динамического расширения сегмента стека, (A) – общий бит для сегментов данных и кода, выставляется в 1 при обращении к сегменту, будь то чтение, запись или исполнение. В случае сегмента кода бит (E) интерпретируется как ©, а (W) как ®. Бит © conforming, отменяет часть проверок безопасности при вызове кода этого сегмента из другого сегмента. Бит ® read enable разрешает чтение из сегмента кода. Писать в сегмента кода в защищенном режиме нельзя.

• L (64-bit code segment) – выставляется, если сегмент содержит 64х-битный код. Флаг может быть выставлен в 1 только для сегментов кода.
• AVL (Available and reserved bits) – не используется процессором, может быть использован ОС.
• D/B (default operation size) – определяет разрядность пользовательских сегментов кода и данных. 16 бит, если флаг выставлен в 0 и 32, если в 1 (да, да, 16ти битный код в защищенном режиме тоже бывает).
• DPL (descriptor privilege level) – определяет уровень привилегий сегмента. Может принимать значения от 0 до 3, где 0 – самое привилегированное. Используется для ограничения доступа к сегменту.

Подробнее о структуре дескриптора можно прочитать в Intel System Programming Guide Part 1, в разделе 3.4.5. Там же можно найти описание того, как устроено разделение доступа к сегментам в соответствии с их уровнем привилегий. На Хабре есть хороший перевод на эту тему.
Вспомним, для чего мы все это начали – нам нужно вызывать прерывания BIOS из кода на C. Т.е. понадобится из кода на С перейти к коду в RM на ASM и затем обратно. Код на С выполняется в 32х-битном PM. План перехода будет выглядеть следующим образом:

Помимо прочего нужно передавать аргументы из кода на С коду в RM и результаты из кода в RM коду на С.

! ВАЖНО! Все дальнейшие действия могут успешно осуществляться только после успешного прохождения всех 6-ти шагов из первой части статьи “Как запустить программу без операционной системы”!

Итак, наш план:
1. Настроить собственную таблицу GDT, взамен той, что настроил GRUB.
2. Написать обертку для обращения к BIOS на С.
3. Добавить несколько общих функций.
4. Слепить все вместе и запустить.

Шаг 1. Инициализируем GDT

1. Добавим в папку include файл bitvisor-1.2\core\desc.h, взятый из проекта BitVisor. Код можно скачать тут. В файле содержится объявление структуры пользовательского дескриптора.
2. Добавим файл descriptor.c со следующим содержимым:

Для работы кода на С достаточно 2х пользовательских сегментов: 32х битный сегмент кода и 32х битный сегмент данных. Для перехода в 16ти битный код нам понадобятся два дополнительных сегмента: 16ти битные сегменты кода и данных. Функция SetupDescTables формирует по адресу *GDT_base таблицу GDT с пятью дескрипторами, первый из которых является нулевым, а оставшиеся 4 соответствуют описанным выше сегментам. Все сегменты имеют базу 0 и лимит 4G. Первый дескриптор в GDT всегда должен быть нулевым. Регистр GDTR, который указывает на GDT, инициализируется инструкцией lgdt. Для вызова инструкции применяется ассемблерная вставка со специфичным GCC синтаксисом. Ассемблерные вставки имеют структуру следующего вида:

Использованная asm-вставка превращается в следующий код:

Строго говоря, для того, чтобы таблица GDT начала использоваться, нужно загрузить в регистры CS, SS, DS значения соответствующих селекторов. Но на данном этапе это не так критично.

3. Добавим в kernel.c вызов SetupDescTables и несколько объявлений. В результате получается следующее:

Вызов GetAvalibleRAMSize () возвращает размер оперативной памяти в байтах.

Шаг 2. Добавим несколько общих функций

1. Добавим в папку common файл bitvisor-1.2\core\string.s, в папку include файлы bitvisor-1.2\core\longmode.h и bitvisor-1.2\include\core\string.h из проекта BitVisor. В этих файлах находится реализация нескольких функций общего назначения, таких как memcpy и memset. Содержимое include\types.h заменить на следующее:

Шаг 3. Обращение к BIOS

1. Добавим в include файл segment.h, содержащий значения селекторов для определенных в функции SetupDescTables дескрипторов.

и файл callrealmode.h, с прототипом функции GetRamsize.

2. Добавим в корень нашего проекта файл callrealmode.c со следующим содержимым:

Мы дошли до самого интересного! В данном коде присутствует 2 функции: GetRamsize и callrealmode_Call. Функция GetRamsize формирует структуру callrealmode_Data param для вызова callrealmode_Call. Функция callrealmode_Call непосредственно переходит в 16ти битный код на ассемблер. На ее основе можно написать и другие функции, которые обращаются к BIOS, например, функцию чтения сектора с диска. Единственным условием будет использование структуры callrealmode_Data .

Функция GetRamsize реализует в своей логике механизм получения карты физической памяти через прерывание int0x15, многократно вызывая функцию callrealmode_Call (аналог int0x15), пока param.getsysmemmap.next_num (он же EBX) не станет равным нулю. Функция callrealmode_Call использует две обрамляющие код на ассемблере метки callrealmode_start и callrealmode_end для копирования всего 16ти битного кода в нижний мегабайт по адресу CALLREALMODE_OFFSET = 0x5000. Адрес выбран так, чтобы при копировании не перетереть структур BIOS’a. Наибольший интерес в функции представляет ассемблерная вставка, она хорошо прокомментирована, поэтому просто покажем, во что она превратилась в скомпилированном виде:

3. Добавим файл callrealmode_asm.h в папку include, файл можно взять здесь , и файл callrealmode_asm.s в корень исходников, который можно взять здесь. Первый файл содержит определения структур, использованных в callrealmode.c. Второй фал содержит 16ти битный код на ассемблер, в котором выполняется переход в RM, вызов BIOS, возврат в PM и затем в код на С. Код подробно прокомментирован и в нем можно разобраться. Нужно отметить, что процедуры protection_off и protection_on, использующиеся для перехода между PM и RM, сильно упрощены. Они забывают о части регистров, таких как CR3, некоторые MSR, значения которых нужно сохранять и восстанавливать, так, как это происходит с GDTR и IDTR. Более полную реализацию этих функций можно найти в проекте BitVisor, а именно в файле bitvisor-1.2\core\callrealmode_asm.s.

Шаг 4. Последние доработки и запуск

1. Внесем изменения в makefile. Заменим

2. Пересоберем проект:

3. Запустим с опцией “–m”, которая позволяет явно указать размер оперативной памяти. Должно получиться что-то вроде следующего:

Программа печатает все имеющиеся диапазоны памяти. Как и в предыдущих частях, можно сделать dd образа hdd.img на флешку и проверить код на реальном железе, загрузившись с нее.

Дальнейшие планы

В результате мы получили механизм, позволяющий обращаться к BIOS из кода на С. Кроме того, была затронута теоретическая часть, касающаяся работы защищенного режима. В будущем эту статью можно использовать в качестве отправной точки для демонстрации работы с файловой системой FAT32, но об этом в следующий раз!

Ссылка на следующую статью цикла:
«Как запустить программу без операционной системы: часть 6. Поддержка работы с дисками с файловой системой FAT«

Включение и отключение параметров элементов ActiveX в файлах Office

Получите сведения о работе с элементами ActiveX в файлах, изменении их параметров, а также о включении и отключении их с помощью панели сообщений и центра управления безопасностью. Кроме того, вы можете получить дополнительные сведения об элементах ActiveX и о том, как они позволяют улучшить файлы.

ИТ-специалисты могут найти дополнительные сведения о планировании элементов ActiveX в статье TechNet Планирование параметров безопасности для элементов управления ActiveX в приложениях Office 2010.

В этой статье

Включение элементов ActiveX при появлении панели сообщений

При открытии файла с элементами ActiveX появляется желтая панель сообщений со значком щита и кнопкой Включить содержимое. Если известно, что источник элементов является надежным, воспользуйтесь описанными ниже инструкциями.

В области Панель сообщений нажмите кнопку Включить содержимое.
Файл откроется в качестве надежного документа.

На приведенном ниже рисунке показан пример панели сообщений, если в файле есть элементы ActiveX.

Включение элементов ActiveX в представлении Backstage

Другой способ включения элементов ActiveX в файле — с помощью представления Microsoft Office Backstage, которое появляется после открытия вкладки Файл при отображении желтой панели сообщений.

Откройте вкладку Файл.

В области Предупреждение системы безопасности нажмите кнопку Включить содержимое.

В разделе Включить все содержимое выберите команду Всегда включать активное содержимое данного документа.
Файл станет надежным документом.

На приведенном ниже рисунке показаны команды Всегда включать активное содержимое этого документа и Дополнительные параметры.

На приведенном ниже рисунке показаны команды группы Включить содержимое.

Примечание: Исключение составляют элементы ActiveX с флагом блокировки. Такие элементы ActiveX не запускаются. Флаг блокировки — это функция безопасности, которая запрещает элементу ActiveX использовать код ActiveX, например устраняя уязвимость в системе безопасности или предотвращая запуск кода.

Включение элементов ActiveX на один раз при появлении предупреждения системы безопасности

Выполнив приведенные ниже инструкции, можно включить элементы управления на то время, пока открыт файл. Если закрыть файл и открыть его снова, предупреждение появится опять.

Откройте вкладку Файл.

В области Предупреждение системы безопасности нажмите кнопку Включить содержимое.

Выберите элемент Дополнительные параметры .

В диалоговом окне Параметры безопасности Microsoft Office выберите команду Включить содержимое для этого сеанса для каждого элемента ActiveX.

На приведенном ниже рисунке показана область Предупреждения системы безопасности, если элементы ActiveX можно включить на то время, пока открыт файл.

Если файл содержит проект Visual Basic для приложений (VBA), например файл Microsoft Excel с поддержкой макросов, центр управления безопасностью налагает более жесткие ограничения, поскольку такой файл может содержать макросы.

Элементы ActiveX и другой активный контент следует включать только в том случае, если точно известно, что они получены из надежного источника.

Изменение параметров элементов ActiveX в Word, Access, Excel, PowerPoint, Publisher и Visio

Выполнив приведенные ниже инструкции, можно включить или отключить элементы ActiveX в центре управления безопасностью.

Выберите Файл > Параметры.

Выберите по очереди пункты Центр управления безопасностью, Параметры центра управления безопасностью и Параметры ActiveX.

Выберите нужные параметры и нажмите кнопку ОК.

Далее показан пример области Параметры ActiveX центра управления безопасностью.

Важно: При изменении параметра ActiveX в Word, Access, Excel, PowerPoint, Publisher или Visio аналогичные параметры изменяются и во всех остальных программах из этого списка.

Описание параметров элементов ActiveX

Приведенные ниже объяснения относятся к элементам ActiveX, которые не находятся в надежном расположении или надежных документах.

Важно: Если документ является надежным и предупреждения безопасности о наличии элементов ActiveX или другого активного содержимого получать нежелательно, поместите этот документ в надежное расположение.

Отключить все элементы управления без уведомления. В документах будут отключены все элементы ActiveX.

Запрос перед включением элементов управления, инициализация которых считается небезопасной (UFI), с дополнительными ограничениями и элементов управления, инициализация которых считается безопасной (SFI), с минимальными ограничениями. Здесь возможны два варианта в зависимости от наличия проектов VBA projects.

При наличии проекта VBA. Все элементы ActiveX отключены, отображается панель сообщений. Чтобы включить элементы управления, нажмите кнопку Включить содержимое.

При отсутствии проекта VBA. Элементы ActiveX, инициализация которых считается безопасной SFI, включены с минимальными ограничениями, и панель сообщений не появляется. Чтобы не открывать панель сообщений, необходимо пометить все элементы ActiveX как SFI. Элементы ActiveX, инициализация которых считается небезопасной (UFI), отключены. Однако в случае включения элементов UFI они инициализируются с дополнительными ограничениями (например, значениями по умолчанию). Постоянные данные, являющиеся частью элементов UFI, будут потеряны.

Запрос перед включением всех элементов управления с минимальными ограничениями. Этот параметр установлен по умолчанию. Здесь возможны два варианта в зависимости от наличия проектов VBA.

При наличии проекта VBA. Все элементы ActiveX отключены, отображается панель сообщений. Чтобы включить элементы управления, нажмите кнопку Включить содержимое.

При отсутствии проекта VBA. Элементы ActiveX, инициализация которых считается безопасной (SFI), включены с минимальными ограничениями, и панель сообщений не появляется. Чтобы не открывать панель сообщений, необходимо пометить все элементы ActiveX как SFI. Элементы ActiveX, инициализация которых считается небезопасной (UFI), отключены. Однако в случае включения элементов UFI они инициализируются с минимальными ограничениями (например, постоянные значения или значения по умолчанию, если постоянные данные не существуют).

Включить все элементы управления без ограничений и запросов (не рекомендуется). Все элементы ActiveX в документах включаются с минимальными ограничениями.

Безопасный режим. Позволяет включить элементы ActiveX, инициализация которых считается безопасной (SFI), в безопасном режиме. Это означает, что разработчик пометил данный элемент управления как безопасный.

Что представляет собой элемент ActiveX и какие риски с ним связаны

Элементы ActiveX — это небольшие стандартные блоки, используемые для создания приложений, работающих через Интернет в веб-браузере. Примерами могут служить пользовательские приложения для сбора данных, просмотра файлов определенных типов и показа анимации. Обычно элементы ActiveX используются в кнопках, списках и диалоговых окнах. В программах Office также можно использовать элементы ActiveX для расширения функциональности документов.

Риск и возможные последствия

Элементы ActiveX могут иметь неограниченный доступ к компьютеру и, следовательно, могут получить доступ к локальной файловой системе и изменить параметры реестра операционной системы. Если злоумышленник воспользуется элементом ActiveX, чтобы управлять компьютером, нежелательные последствия могут быть весьма серьезными.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL