- Проверка безопасности типов CLR может проверять безопасность использования типов в коде, что гарантирует корректное обращение к существующим типам. Если входной параметр метода объявлен как 4-байтное значение, CLR обнаружит и предотвратит передачу 8-байтного значения в качестве значения этого параметра. Безопасность типов также означает, что управление может передаваться только в определенные точки (точки входа методов). Невозможно указать произвольный адрес и заставить программу исполняться, начиная с этого адреса. Совокупность всех этих защитных мер избавляет от многих распространенных программных ошибок (например, от возможности использования переполнения буфера для «взлома» программы).
- Развитая поддержка отладки. Поскольку CLR используется для многих языков, можно написать отдельный фрагмент программы на языке, наиболее подходящем для конкретной задачи, – CLR полностью поддерживает отладку многоязыковых приложений.
- Единый принцип обработки сбоев. Один из самых неприятных моментов Windows-программирования – несогласованный стиль сообщений о сбоях. Одни функции возвращают коды состояний Win32, другие – HRESULT, третьи генерируют исключения. В CLR обо всех сбоях сообщается через исключения, которые позволяют отделить код, необходимый для восстановления после сбоя, от основного алгоритма. Такое разделение облегчает написание, чтение и сопровождение программ. Кроме того, исключения работают в многомодульных и многоязыковых приложениях. И в отличие от кодов состояний и HRESULT исключения нельзя проигнорировать. CLR также предоставляет встроенные средства анализа стека, заметно упрощающие поиск фрагментов, вызывающих сбои.
- Безопасность. Традиционные системы безопасности обеспечивают управление доступом на основе учетных записей пользователей. Это проверенная модель, но она подразумевает, что любому коду можно доверять в одинаковой степени. Такое допущение оправданно, когда весь код устанавливается с физических носителей (например, с компакт-диска) или с доверенных корпоративных серверов. Но по мере увеличения объема мобильного кода, например Web-сценариев, приложений, загружаемых из Интернета, и вложений, содержащихся в электронной почте, нужен ориентированный на код способ контроля за поведением приложений. Такой подход реализован в модели безопасности доступа к коду.
- Взаимодействие с существующим кодом. В Microsoft понимают, что разработчики накопили огромный объем кода и компонентов. Переписывание всего этого кода, так чтобы он задействовал все достоинства NET Framework, значительно замедлило бы переход к этой платформе. Поэтому в .NET Framework реализована полная поддержка доступа к СОМ-компонентам и Win32-функциям в существующих динамических библиотеках DLL[1].
3. Архитектура и принцип работы платформы NET Framework
платформа net framework работа
При работе с платформой .NETможно создавать файлы с исходным кодом на любом языке, поддерживающем CLR. Затем соответствующий компилятор проверяет и анализирует исходный код. Независимо от компилятора результатом его работы является управляемый модуль (managedmodule) – стандартный переносимый исполняемый (portableexecutable, РЕ) файл 32-разрядной (РЕ32) или 64-разрядной Windows (PE32+), который требует для своего выполнения исполняемую среду CLR.
В прошлом почти все компиляторы генерировали код для конкретных процессорных архитектур, таких как x86, IA64, Alpha или PowerPC. Все CLR-совместимые компиляторы вместо этого генерируют IL-код. IL-код иногда называют управляемым (managedcode), потому что CLR управляет его жизненным циклом и выполнением.
Каждый компилятор, предназначенный для CLR, кроме генерации IL-кода, также должен создавать полные метаданные (metadata) для каждого управляемого модуля. Коротко говоря, метаданные – это просто набор таблиц данных, описывающих то, что определено в модуле, например типы и их члены. Метаданные служат многим целям:
- Они устраняют необходимость в заголовочных и библиотечных файлах прикомпиляции, так как все сведения о типах/членах, на которые есть ссылки, содержатся в файле с IL-кодом, в котором они реализованы. Компиляторы могут читать метаданные прямо из управляемых модулей.
- В процессе верификации кода CLR использует метаданные, чтобы убедиться, что код совершает только «безопасные» операции.
- Метаданные позволяют сериализовать поля объекта в блок памяти на удаленной машине и затем десериализовать, восстановив объект и его состояние на этой машине.
- Метаданные позволяют сборщику мусора отслеживать жизненный цикл объектов. Используя метаданные, сборщик мусора определяет тип объектов и узнает, какие поля в них ссылаются на другие объекты.
Метаданные расширяют возможности таких старых технологий, как библиотеки типов и файлы языка описания интерфейсов (Interface Definition Language, IDL). Важно заметить, что метаданные CLR гораздо полнее. И в отличие от библиотек типов и IDL они всегда связаны с файлом, содержащим IL-код. Фактически метаданные всегда встроены в тот же ЕХЕ/DLL, что и код, так что их нельзя разделить. Так как компилятор генерирует метаданные и код одновременно и привязывает их к конечному управляемому модулю, рассинхронизация метаданных и описываемого ими IL-кода исключена.
После компиляции набор управляемых модулей объединяется в сборку. Сборка – это логическая группировка одного или нескольких управляемых модулей или файлов ресурсов. Это самая маленькая единица с точки зрения повторного использования, безопасности и управления версиями. Сборка может состоять из одного или нескольких файлов – все зависит от выбранных средств и компиляторов [1].
При выполнении исполняемого файла Windows анализирует заголовок ЕХЕ-файла на предмет необходимого для его работы адресного пространства – 32-или 64-разрядного. Файл с заголовком РЕ32 может выполняться в адресном пространстве любого из указанных двух типов, а файлу с заголовком РЕ32+ требуется 64-разрядное пространство. Windows также проверяет информацию о процессорной архитектуре на предмет совместимости с имеющейся конфигурацией.64-разрядные версии Windows поддерживают технологию выполнения 32-разрядных приложений в 64-разрядной среде, которую называют W0W64 (WindowsonWindows64). Она даже позволяет выполнять 32-разрядные приложения на машине с процессором Itanium за счет эмуляции команд х8б, но за это приходится расплачиваться снижением производительности.
После анализа заголовка ЕХЕ-файла для выяснения того, какой процесс запустить – 32-, 64-разрядный или WoW64, Windows загружает в адресное пространство процесса соответствующую (х86, х64 или IA64) версию библиотеки MSCorEE.dll. В Windows версии х86 одноименная версия MSCorEE.dll хранится в каталоге C:\Windows\System32. В версиях х64 и IA64 версия х86 библиотеки находится в каталоге C:\Windows\SysWow64, а 64-разрядная версия MSCorEE.dll (хб4 orIA64) размещается в каталоге C:\Windows\System32 (это сделано из соображений обратной совместимости).
Далее основной поток процесса вызывает определенный в MSCorEE.dll метод, который инициализирует CLR, загружает сборку ЕХЕ, а затем ее метод точки входа (Main). На этом процедура запуска управляемого приложения считается завершенной.
Как уже упоминалось, управляемые модули содержат метаданные и код на промежуточном языке (IL). IL – не зависящий от процессора машинный язык, это язык более высокого уровня в сравнении с большинством других машинных языков. Он позволяет работать с объектами и имеет команды для создания и инициализации объектов, вызова виртуальных методов и непосредственного манипулирования элементами массивов. В нем даже есть команды генерации и перехвата исключений для обработки ошибок. IL можно рассматривать как объектно-ориентированный машинный язык.
Для выполнения какого-либо метода его IL-код должен быть преобразован в машинные команды. Этим занимается JIT-компилятор CLR. Рассмотрим пример:
publicvoidMain()
{
Console.WriteLine(“HelloWorld”);
}
Непосредственно перед исполнением метода Main среда CLR находит все типы, на которые ссылается код Main. При этом CLR выделяет внутренние структуры данных, используемые для управления доступом к типам, на которые есть ссылки. В примере метод Main ссылается на единственный тип – Console, и CLR выделяет единственную внутреннюю структуру. Эта внутренняя структура данных содержит по одной записи для каждого метода, определенного в типе Console. Каждая запись содержит адрес, по которому можно найти реализацию метода. При инициализации этой структуры CLR заносит в каждую запись адрес внутренней, недокументированной функции, содержащейся в самой CLR. Это функция JIT Compiler.
Функции JIT Compiler известен вызываемый метод и тип, в котором он определен. JIT Compiler ищет в метаданных соответствующей сборки IL-код вызываемого метода. Затем JIT Compiler проверяет и компилирует IL-код в собственные машинные команды, которые сохраняются в динамически выделенном блоке памяти.
После этого JIT Compiler возвращается к внутренней структуре данных типа и заменяет адрес вызываемого метода адресом блока памяти, содержащего готовые машинные команды. В завершение JIT Compiler передает управление коду в этом блоке памяти. Этот код – реализация метода Write Line (той его версии, что принимает параметр String). Из этого метода управление возвращается в Main, который продолжает выполнение в обычном порядке.
Затем Main обращается к Write Line вторично. К этому моменту код Write Line уже проверен и скомпилирован, так что обращение к блоку памяти производится, минуя вызов JIT Compiler. Отработав, метод Write Line возвращает управление Main. Снижение производительности наблюдается только при первом вызове метода. Все последующие обращения выполняются «на полной скорости»: повторная верификация и компиляция не производятся.
JIT-компилятор хранит машинные команды в динамической памяти. Это значит, что скомпилированный код уничтожается по завершении работы приложения. Так что, если потом снова вызвать приложение или если одновременно запустить второй его экземпляр (в другом процессе ОС), JIT-компилятор заново будет компилировать IL-код в машинные команды.