от выбранного типа проекта, PE-файл может иметь уточнения exe, dll, mod или mdl.
Заметьте, PE-файл, имеющий уточнение ехе, хотя и является exe-файлом, но это не совсем обычный, исполняемый Windows, файл. При его запуске он распознается как специальный PE-файл и передается CLR для обработки. Исполнительная среда начинает работать с кодом, в котором специфика исходного языка программирования исчезла. Код на IL начинает выполняться под управлением CLR (по этой причине код называется управляемым). Исполнительную среду можно рассматривать как своеобразную виртуальную IL-машину. Эта машина транслирует "на лету" требуемые для исполнения участки кода в команды реального процессора, который в действительности и выполняет код.
Виртуальная машина
Отделение каркаса от студии явилось естественным шагом. Каркас Framework.Net перестал быть частью студии, а стал надстройкой над операционной системой. Теперь компиляция и создание РЕ-модулей на IL отделено от выполнения, и эти процессы могут быть реализованы на разных платформах. В состав CLR входят трансляторы JIT (Just In Time Compiler), которые и выполняют трансляцию IL в командный код той машины, где установлена и функционирует исполнительная среда CLR. Конечно, в первую очередь Microsoft реализовала CLR и FCL для различных версий Windows, включая Windows 98/ Me/NT 4/2000, 32 и 64-разрядные версии Windows ХР и семейство. Net Server. Для операционных систем Windows СЕ и Palm разработана облегченная версия Framework.Net.
В 2001 году ЕСМА (Европейская ассоциация производителей компьютеров) приняла язык программирования С#, CLR и FCL в качестве стандарта, так что Framework.Net уже функционирует на многих платформах, отличных от Windows. Он становится свободно распространяемой виртуальной машиной. Это существенно расширяет сферу его применения. Производители различных компиляторов и сред разработки программных продуктов предпочитают теперь также транслировать свой код в IL, создавая модули в соответствии со спецификациями CLR. Это обеспечивает возможность выполнения их кода на разных платформах.
Microsoft использовала получивший широкое признание опыт виртуальной машины Java, улучшив процесс за счет того, что, в отличие от Java, промежуточный код не интерпретируется исполнительной средой, а компилируется с учетом всех особенностей текущей платформы. Благодаря этому создаются высокопроизводительные приложения.
Следует отметить, что CLR, работая с IL-кодом, выполняет достаточно эффективную оптимизацию и, что не менее важно, защиту кода. Зачастую нецелесообразно выполнять оптимизацию на уровне создания IL-кода — она иногда может не улучшить, а ухудшить ситуацию, не давая CLR провести оптимизацию на нижнем уровне, где можно учесть даже особенности процессора.
Дизассемблер и ассемблер
Если у вас есть готовый PE-файл, то иногда полезно анализировать его IL-код и связанные с ним метаданные. В состав Framework SDK входит дизассемблер — ildasm, выполняющий дизассемблирование PE-файла и показывающий метаданные, а также IL-код с комментариями в наглядной форме. Мы иногда будем пользоваться результатами дизассемблирования. У меня на компьютере кнопка, вызывающая дизассемблер, находится на панели, где собраны наиболее часто используемые мной приложения. Вот путь к папке, в которой обычно находится дизассемблер:
C: Program FilesMicrosoft Visual Studio.Net FrameworkSDKBinildasm.exe
Профессионалы, предпочитающие работать на низком уровне, могут программировать на языке ассемблера IL. В этом случае в их распоряжении будет вся мощь библиотеки FCL и все возможности CLR. У меня на компьютере путь к папке, где находится ассемблер, следующий:
С: WINDOWSMicrosoft.NetFrameworkvl.1.4322ilasm.exe
В этом курсе к ассемблеру мы обращаться не будем — я упоминаю о нем для полноты картины.
Метаданные
Переносимый исполняемый PE-файл является самодокументируемым файлом и, как уже говорилось, содержит и код, и метаданные, описывающие код. Файл начинается с манифеста и включает в себя описание всех классов, хранимых в PE-файле, их свойств, методов, всех аргументов этих методов — всю необходимую CLR информацию. Поэтому помимо PE-файла не требуется никаких дополнительных файлов и записей в реестр — вся нужная информация извлекается из самого файла. Среди классов библиотеки FCL имеется класс Reflection, методы которого позволяют извлекать необходимую информацию. Введение метаданных — не только важная техническая часть CLR, но это также часть новой идеологии разработки программных продуктов. Мы увидим, что и на уровне языка C# самодокументированию уделяется большое внимание.
Мы увидим также, что при проектировании класса программист может создавать собственные атрибуты, добавляемые к метаданным PE-файла. Клиенты этого класса могут, используя класс Reflection, получать эту дополнительную информацию, и на ее основании принимать соответствующие решения.
На рис. 1.1 показаны результаты дизассемблирования PE-файла простого консольного приложения с именем Account, включающего три класса: Account, Testing и Classi. Дизассемблер структурирует информацию, хранимую в метаданных, и показывает ее в типичном формате дерева. Как обычно, это дерево можно сжимать или раскрывать, демонстрируя детали класса. Значки, приписываемые каждому узлу дерева, характеризуют тип узла — класс, свойство, метод, описание. Двойной щелчок кнопки мыши на этом узле позволяет раскрыть его. При раскрытии метода можно получить его код. На рис. 1.1 показан КОД метода add из класса Account.
Рис. 1.1. Пример структуры PE-файла, задающего сборку
Сборщик мусора — Garbage Collector — и управление памятью
Еще одной важной особенностью построения CLR является то, что исполнительная среда берет на себя часть функций, традиционно входящих в ведение разработчиков трансляторов, и облегчает тем самым их работу. Один из таких наиболее значимых компонентов CLR — сборщик мусора (Garbage Collector).
Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (классическим примером является язык C/C++) память освобождает сам программист, в явной форме отдавая команды как на создание, так и на удаление объекта. В этом есть своя логика — "я тебя породил, я тебя и убью". Однако можно и нужно освободить человека от этой работы. Неизбежные ошибки программиста при работе с памятью тяжелы по последствиям, и их крайне тяжело обнаружить. Как правило, объект удаляется в одном модуле, а необходимость в нем обнаруживается в другом, далеком модуле. Обоснование того, что программист не должен заниматься удалением объектов, а сборка мусора должна стать частью исполнительной среды, дано достаточно давно. Наиболее полно оно обосновано в работах Бертрана Мейера и в его книге "Object-Oriented Construction Software", первое издание которой появилось еще в 1988 году.
В CLR эта идея реализована в полной мере. Задача сборки мусора снята не только с программистов, но и с разработчиков трансляторов, она решается в нужное время и в нужном месте — исполнительной средой, ответственной за выполнение вычислений. Здесь же решаются и многие другие вопросы, связанные с использованием памяти, в частности, проверяются возможные нарушения использования "чужой" памяти и другие нарушения, например, с использованием нетипизированных
