Программирование на Visual C++. Архив рассылки

ПРИМЕЧАНИЕ

Вы сможете найти список всех таких функций в Platform SDK на странице Obsolete Windows Programming Elements.

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

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

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

Что же это такое – сборки (Assembly)?

• Сборки – это наименьшие строительные блоки, на которых базируется платформа .NET.

• Различия в версиях могут существовать только на уровне сборок; предполагается, что внутри сборки никакие элементы (классы, интерфейсы и т. п.) не могут иметь собственные версии.

• Сборки являются хранилищами как для кода, так и для ресурсов.

• Сборки самоописываемы – они содержат метаданные (metadata), которые несут в себе информацию о версии, зависимостях, типах, атрибутах и многое другое.

• Сборки защищены – система защиты исполняемого кода использует права запуска индивидуально для каждой сборки. Автором сборки в метаданных записываются права на использование данной сборки кем бы то ни было, что позволяет защищать код "родными" для системы методами, не прибегая к продуктам сторонних производителей.

Начнем с манифеста

Манифест – это метаданные, включающие информацию о сборке, а именно:

• Данные о версии – версию, имя и необязательные данные.

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

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

• Экспортируемые типы и ресурсы. Видимость для этих объектов может быть двух типов: только для моей сборки (internal) и для всех (public), включая внешние запросы.

• Свойства защиты. Здесь можно выделить три типа:

 • Права на запуск данной сборки.

 • Некоторые возможности сборки будут недоступны, если она не лицензирована.

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

ПРИМЕЧАНИЕ

Список файлов, из которых состоит сборка, и зависимости от других сборок – это совершенно разные вещи. Сборка сама по себе может быть разбита на несколько файлов, хотя для тех, кто ее использует, она будет выглядеть как единое целое. То есть, к примеру, общие классы могут лежать в одном файле, ресурсы – в другом, специальные классы – в третьем файле и так далее. Для чего, спрашивается, это нужно? Во-первых, это нужно для гибкой загрузки распределенных приложений, так как файлы, составляющие сборку, могут загружаться по мере необходимости, а не все сразу. Во-вторых, для создания распределённых приложений, так как местоположение файлов не играет никакой роли: файлы из одной и той же сборки могут находиться где угодно: в Интернете, на сетевых дисках и так далее.

Настало время "поработать руками"

Для начала проверьте, правильно ли у вас настроены пути к Visual Studio.Net. Чтобы правильно настроить пути, вам всего лишь необходимо вызывать при загрузке (ну или как вам нравиться) файл vsvars32.bat, который расположен в директории …Microsoft Visual Studio.NET\Common7\Tools\.

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

• Visual Basic.NET

'File: Some.vb
'Author: Copyright (C) 2001 Dubovcev Aleksey
Imports System
Public Class App
 Public Shared Sub Main
 Console.WriteLine("Hello World")
 End Sub
End Class

• C#

/* File: Some.cs Author: Copyright (C) 2001 Dubovcev Aleksey */
using System;
public class Application {
 public static void Main {
 Console.WriteLine("Hello World");
 }
}

• Managed Visual C++

/* File: Some.cpp Author: Copyright (C) 2001 Dubovcev Aleksey */
#using <mscorlib.dll>
using namespace System;
void main {
 Console::WriteLine("Hello World");
}

Теперь, когда вы построили exe файл, запускайте утилиту ildasm.exe (Intermediate Language Disassembler – дизассемблер промежуточного языка) следующим образом:

ildasm.exe /adv HelloWorld.exe

Параметр командной строки /adv откроет дополнительные пункты меню, которые понадобятся нам позднее. Полную информацию о данной утилите вы сможете найти в .NET Framework Sdk.

Рис. 1