Реферат: Платформа Microsoft. NET Framework
- Проверка безопасности типов CLR может проверять безопасность использования типов в коде, что гарантирует корректное обращение к существующим типам. Если входной параметр метода объявлен как 4-байтное значение, CLR обнаружит и предотвратит передачу 8-байтного значения в качестве значения этого параметра. Безопасность типов также означает, что управление может передаваться только в определенные точки (точки входа методов). Невозможно указать произвольный адрес и заставить программу исполняться, начиная с этого адреса. Совокупность всех этих защитных мер избавляет от многих распространенных программных ошибок (например, от возможности использования переполнения буфера для «взлома» программы).
- Развитая поддержка отладки. Поскольку CLR используется для многих языков, можно написать отдельный фрагмент программы на языке, наиболее подходящем для конкретной задачи, – CLR полностью поддерживает отладку многоязыковых приложений.
- Единый принцип обработки сбоев. Один из самых неприятных моментов Windows-программирования – несогласованный стиль сообщений о сбоях. Одни функции возвращают коды состояний Win32, другие – HRESULT, третьи генерируют исключения. В CLR обо всех сбоях сообщается через исключения, которые позволяют отделить код, необходимый для восстановления после сбоя, от основного алгоритма. Такое разделение облегчает написание, чтение и сопровождение программ. Кроме того, исключения работают в многомодульных и многоязыковых приложениях. И в отличие от кодов состояний и HRESULT исключения нельзя проигнорировать. CLR также предоставляет встроенные средства анализа стека, заметно упрощающие поиск фрагментов, вызывающих сбои.
- Безопасность. Традиционные системы безопасности обеспечивают управление доступом на основе учетных записей пользователей. Это проверенная модель, но она подразумевает, что любому коду можно доверять в одинаковой степени. Такое допущение оправданно, когда весь код устанавливается с физических носителей (например, с компакт-диска) или с доверенных корпоративных серверов. Но по мере увеличения объема мобильного кода, например Web-сценариев, приложений, загружаемых из Интернета, и вложений, содержащихся в электронной почте, нужен ориентированный на код способ контроля за поведением приложений. Такой подход реализован в модели безопасности доступа к коду.
- Взаимодействие с существующим кодом. В Microsoft понимают, что разработчики накопили огромный объем кода и компонентов. Переписывание всего этого кода, так чтобы он задействовал все достоинства NET Framework, значительно замедлило бы переход к этой платформе. Поэтому в .NET Framework реализована полная поддержка доступа к СОМ-компонентам и Win32-функциям в существующих динамических библиотеках DLL[1].
3. Архитектура и принцип работы платформы NET Framework
3.1 Компиляция исходного кода
платформа 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].
3.2 Процесс загрузки и исполнения кода в платформе NET
При выполнении исполняемого файла 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. Снижение производительности наблюдается только при первом вызове метода. Все последующие обращения выполняются «на полной скорости»: повторная верификация и компиляция не производятся.
