интернациональное программирование

N|M{INT3 TEAM}{NIM@INT3.RU}

Спецвыпуск: Хакер, номер #065, стр. 065-032-2

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

Разработчикам здесь предоставлены средства для повышения безопасности кода. Например, теперь они могут запретить доступ своей программы к реестру или, обратившись к атрибутам доступа, — доступ к файлам. Эти атрибуты применимы и к программе целиком, и к ее отдельным частям. Контроль подобных ограничений происходит на уровне платформы .NET.

Второй этап компиляции (в машинный код) происходит при запуске программы. Компилируется только тот код, который должен выполняться в данный момент, — реализуется за счет заглушек, которые создаются для каждого метода при старте программы. Когда один из таких методов будет вызван, заглушка вызовет компилятор, а он в свою очередь скомпилирует тело метода. Соответственно, приходится потратить некоторое время, зато только один раз, так как после компиляции компилятор изменяет заглушку так, что выполнение передается в расположение машинного кода. Последующие вызовы метода, откомпилированного по требованию, передаются прямо в созданный ранее машинный код, что уменьшает время, необходимое на выполнение кода. Эта технология, только что описанная мной, носит имя JIT (Just In Time) — «компиляция по требованию».

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

[предназначение сборок] состоит в том, чтобы упростить развертывание приложений и решить вопросы, связанные с отслеживанием версий (они иногда возникают, если пользуешься приложениями, основанными на компонентах). Многие пользователи и разработчики знакомы с вопросами отслеживания версий и развертывания, которые возникли в современных системах, основанных на компонентах. (Речь идет о так называемом DLLHALL.) Вот, к примеру, пользователь установил одну программу, вдруг пара других начинают работать неправильно или вообще перестают исполнять свои обязанности — безумное счастье. В результате многие разработчики тратят бесчисленные часы в попытках сохранить в целостности все необходимые данные системного реестра для активации COM-класса.

Две проблемы в приложениях Win32 при отслеживании версий:

1 ПРАВИЛА ОТСЛЕЖИВАНИЯ ВЕРСИЙ НЕ МОГУТ БЫТЬ ОПРЕДЕЛЕНЫ МЕЖДУ ЧАСТЯМИ ПРИЛОЖЕНИЯ — ОНИ ЗАДАЮТСЯ ОПЕРАЦИОННОЙ СИСТЕМОЙ. СУЩЕСТВУЮЩИЙ ПОДХОД ОСНОВЫВАЕТСЯ НА ОБРАТНОЙ СОВМЕСТИМОСТИ, ГАРАНТИРОВАТЬ КОТОРУЮ ЧАСТО БЫВАЕТ ТРУДНО. ОПРЕДЕЛЕНИЯ ИНТЕРФЕЙСОВ ДОЛЖНЫ БЫТЬ СТАТИЧЕСКИМИ И ДОЛЖНЫ ПУБЛИКОВАТЬСЯ ОДНОКРАТНО, А ЕДИНАЯ ЧАСТЬ КОДА ДОЛЖНА ОБЕСПЕЧИВАТЬ ОБРАТНУЮ СОВМЕСТИМОСТЬ С ПРЕДЫДУЩИМИ ВЕРСИЯМИ. СЛЕДОВАТЕЛЬНО, КОД ОБЫЧНО СОЗДАЕТСЯ ТАКИМ ОБРАЗОМ, ЧТО В ЛЮБОЙ ЗАДАННЫЙ МОМЕНТ ВРЕМЕНИ НА КОМПЬЮТЕРЕ МОЖЕТ ПРИСУТСТВОВАТЬ И ВЫПОЛНЯТЬСЯ ТОЛЬКО ОДНА ВЕРСИЯ КОДА.