Как запустить visual studio 2008
В данном разделе будет произведён обзор различных методов расширения среды Visual Studio. Подробно будет рассмотрено создание расширений вида Visual Studio Extension Package (пакет расширения Visual Studio), их отладка, регистрация и развёртывание на машине конечного пользователя.
Эта статья устарела. Обновленную версию этой статьи вы можете прочитать здесь.
Введение
- базовая информация по созданию и отладке MSVS плагинов, а также поддержка данных проектов расширения в единой кодовой базе для нескольких версий Visual Studio;
- обзор объектной модели автоматизации и классов MPF (Managed Package Framework);
- расширения интерфейса среды разработки с использованием API объектной модели автоматизации (EnvDTE) и классов MPF (Managed Package Framework) пользовательскими меню, панелями инструментов, инструментальными окнами и диалогами настроек;
- сбор всех необходимых данных, таких как параметры и настройки компиляции разных конфигураций и платформ, с помощью проектной модели автоматизации Visual C++ для работы с внешним препроцессором/компилятором;
Материал статей основан на опыте разработки плагина-расширения для статического анализатора PVS-Studio. Более детальное и полное описание затронутых в статьях тем доступно по приведённым в конце каждого раздела ссылкам на официальные материалы библиотеки MSDN и другие сторонние ресурсы.
Рассматривается будет только разработка подключаемых модулей для Visual Studio 2005 и выше. Это ограничение идет из-за того, что PVS-Studio работает в системах с VS2005 и выше. В свою очередь мы такое ограничение выбирали при разработке нашего продукта из-за того, что в VS2005 появилась новая модель API, которая не совместима с предыдущими версиями API среды.
Создание и отладка VSPackage модулей расширения Visual Studio
Существует множество способов для расширения функционала Microsoft Visual Studio. На самом базовом уровне можно автоматизировать простые рутинные действия с помощью макросов. Для программной автоматизации простых действий с UI объектами среды, манипуляций пунктами в меню и т.п. можно использовать подключаемый модуль (Add-In).
Расширение встроенных редакторов среды возможно через MEF (Managed Extensibility Framework) компоненты (начиная с версии MSVS 2010). Для интеграции в Visual Studio крупных независимых компонентов лучше всего подходят расширения вида Extension Package (пакеты расширения, также известные как VSPackage). При этом VSPackage позволяют сочетать в себе автоматизацию управления компонентами IDE через объектную модель автоматизации с расширением среды через MEF (Managed Extensibility Framework) и Managed Package Framework классы (таких, как Package).
VSPackage модули также позволяют расширять саму модель автоматизации, предоставляя возможности для добавления в неё пользовательских объектов автоматизации. Такие объекты становятся доступны через модель автоматизации для других модулей-расширений, предоставляя им программный доступ к сторонним интегрированным пользовательским компонентам.
Первые версии плагина PVS-Studio (точнее 1.XX и 2.XX, когда наш продукт еще назывался Viva64), мы выпускали как Add-In. С версии PVS-Studio 3.00 мы переделали его на VSPackage. Причина перехода – нам стало "тесновато" в Add-In и было неудобно отлаживаться. Кроме того, хотелось иметь свой значок на экранной заставке Visual Studio!
Проекты подключаемых модулей VSPackage. Создание пакета расширения
В отличие от подключаемых модулей (Add-In), разработка пакета расширения среды потребует установки Microsoft Visual Studio SDK для целевой версии среды разработки. То есть для разработки пакета расширения под каждую версию Visual Studio потребует установки отдельного SDK.
В дальнейшем мы будем рассматривать версии 2005, 2008, 2010 и 2012. Установка Visual Studio SDK добавляет в стандартные шаблоны среды проект типа Visual Studio Package (пункт Other Project Types -> Extensibility). Данный шаблон сгенерирует простейший MSBuild проект для модуля расширения, позволяя задать язык разработки и заглушки для нескольких типовых компонентов (пункт меню, редактор, пользовательское окно).
Основным классом пакета-расширения Visual Studio должен быть класс-наследник от класса Microsoft.VisualStudio.Shell.Package. Этот базовый класс предоставляет managed-обёртки для интерфейсов взаимодействия с IDE, необходимых полноценному пакету расширения Visual Studio.
Класс Package предоставляет возможность переопределения базового метода Initialize. Метод Initialize получает управление в момент инициализации пакета расширения для текущей сессии IDE.
Инициализация модуля происходит при первом обращении к нему, а также может быть вызвана автоматически, например, при запуске IDE, при вхождении пользователя в заданный UI контекст (например, открытие проекта) и т.п.
Вообще очень важно понимать, как стартует и как завершается модуль расширения. Ведь может оказаться, что разработчик пытается использовать какой-то функционал Visual Studio, который в данный момент использовать нельзя. При разработке PVS-Studio у нас бывали ситуации, когда среда "била нас по рукам" за непонимание того, что при завершении Visual Studio нельзя "в лоб" показать message box с вопросом.
Отладка пакетов расширения. Experimental Instance
Задача отладки подключаемого модуля или расширения для среды разработки является не совсем типичной. Ведь сама эта среда используется и для разработки, и для отладки такого модуля. Подключение такого нестабильного нового модуля к IDE может привести к нестабильности работы самой среды разработки. Дополнительные неудобства создаст необходимость деинсталлировать каждый раз разрабатываемый модуль из среды разработки перед каждой отладкой его новой версии, что зачастую требует перезапуска самой среды (т.к. IDE может блокировать уже подключенный dll, который для отладки потребуется заменить новой версией).
Надо отметить, что отлаживать VSPackage значительно удобнее, чем Add-In. Это послужило одной из ключевых причин для смены используемой в PVS-Studio модели работы с Add-In на VSPackage.
Для решения перечисленных проблем при разработке и отладке пакетов VSPackage можно использовать экспериментальный экземпляр Visual Studio (experimental instance). Его можно запустить, добавив в строку аргументов запуска среды специальный параметр:
Экспериментальный экземпляр среды использует отдельную независимую ветку в системном реестре (experimental hive) для сохранения регистрационной информации установленных компонентов и настроек среды. Любые изменения в настройках IDE, регистрация или модификация новых компонентов в ветке Experimental Hive, никак не отразятся на том экземпляре среды, который используется непосредственно для разработки и отладки модуля (т.е. в основной базовой версии, запускаемой по умолчанию).
Visual Studio SDK предоставляет специальную утилиту для создания или очистки экспериментальных экземпляров — CreateExpInstance. Вызов CreateExpInstance для создания новой экспериментальной ветки выглядит следующим образом:
Выполнение этой команды создаст новую экспериментальную ветку реестра с суффиксом PVSExp в имени для 10 версии IDE (Visual Studio 2010) с предварительным сбросом всех настроек среды до значений по умолчанию. Путь до новой ветки в системном реестре будет выглядеть так:
Хотя по умолчанию при отладке в шаблонном проекте VSPackage используется суффикс Exp (и соответствующая ему ветка реестра), ничто не мешает создавать и другие экспериментальные ветки, соответственно с другими суффиксами имён. Для запуска экземпляра среды в созданной нами ранее новой экспериментальной ветке (содержащей PVSExp в имени) нужно выполнить:
Возможность создать на одной локальной машине несколько экспериментальных веток может быть полезна, например, для одновременной разработки нескольких пакетов расширения в изолированных друг от друга средах.
После установки SDK в меню программ также будет добавлена ссылка, позволяющая сбросить настройки экспериментального экземпляра IDE до значений по умолчанию (например, Reset the Microsoft Visual Studio 2010 Experimental Instance).
Чем быстрее вы разберетесь с тем, как работать с отладочным окружением, тем меньше у вас будет проблем с непониманием что, почему и как загружается при разработке плагина.
Атрибут PackageRegistration сообщает регистрационной утилите о том, что данный класс является модулем-расширением Visual Studio. После его обнаружения будет произведён поиск дополнительных регистрационных атрибутов.
Атрибут Guid задаёт уникальный идентификатор модуля-расширения, который затем будет использован для создания регистрационной под-ветки в системном реестре, в ветке Visual Studio.
Атрибут InstalledProductRegistration позволяет добавить информацию в Help -> About диалог и на splash экран загрузки среды Visual Studio.
Атрибут ProvideAutoLoad позволяет назначить автоматическую инициализацию модуля на активацию заданного UI контекста среды. При вхождении пользователя в данный контекст модуль будет подгружен и инициализирован автоматически. Приведём пример назначения инициализации модуля на открытие solution файла.
Значения GUID идентификаторов для различных контекстов IDE можно посмотреть в классе Microsoft.VisualStudio.VSConstants.UICONTEXT.
Атрибут ProvideMenuResource задаёт ID ресурсов пользовательских команд и меню для их регистрации в IDE.
Атрибут DefaultRegistryRoot задаёт путь для записи регистрационной информации в системном реестре. Начиная с Visual Studio 2010 данный атрибут можно не использовать, а соответствующая ему регистрационная информация должна быть записана в манифесте VSIX контейнера. Пример использования атрибута для регистрации модуля в Visual Studio 2008:
При необходимости добавления в системный реестр во время регистрации пакета расширения пользовательских ключей или необходимости добавления значений для уже существующих ключей, возможно создание пользовательских регистрационных атрибутов путём наследования от абстрактного класса RegistrationAttribute.
Атрибут-наследник RegistrationAttribute обязан будет переопределить методы Register и Unregister, которые используются для модификации регистрационной информации в системном реестре.
Для добавления регистрационной информации в реестр можно воспользоваться утилитой RegPkg, которая автоматически зарегистрирует все перечисленные в переданном ей pkgdef файле компоненты в заданную через аргумент /root ветку реестра. Так, например, вызов RegPkg автоматически прописывается в проектах Visual Studio для регистрации разрабатываемого модуля в экспериментальной ветке реестра для удобства его отладки. После добавления всей регистрационной информации в реестр нужно запустить среду Visual Studio (devenv.exe) с параметром /setup для регистрации новых компонентов уже в самой IDE.
Развертывание плагина на машине разработчика и на машине конечного пользователя. Package Load Key
Прежде чем приступить к описанию процедуры развертывания, запомните важное правило:
При создании дистрибутива с разработанным вами плагином, каждый раз обязательно тестируйте его на машине без Visual Studio SDK, чтобы убедиться, что у обычного пользователя он корректно регистрируется в системе.
Сейчас, когда первые релизы PVS-Studio давно уже позади, у нас не бывает проблем с этим. Однако поначалу несколько неудачных версий попадали к пользователям.
Развёртывание плагина для сред Visual Studio 2005/2008 потребует запуска regpkg для pkgdef файла с указанием основной ветки реестра IDE либо добавления всех ключей из файла pkgdef в системный реестр вручную. Пример команды для автоматического добавления в реестр регистрационной информации из pkgdef файла (в одну строку):
После добавления регистрационной информации в реестр необходимо запустить Visual Studio с параметром /setup, обычно это последний шаг процедуры инсталляции нового модуля.
Запуск среды с данным ключом указывает Visual Studio на необходимость вычитывания метаданных о ресурсах пользовательских компонентов из всех доступных модулей-расширений для их корректного отображения в интерфейсе. Запуск devenv с данным ключом не открывает GUI окно IDE.
В PVS-Studio мы обходимся без запуска RegPkg, а вручную добавляем нужную информацию в реестр во время установки. Это делается из тех соображений, чтобы не зависеть от еще одной сторонней утилиты, а полностью самим контролировать процесс установки. Но мы всё же используем RegPkg при разработке плагина для удобства его отладки.
VSIX пакеты
Начиная с версии Visual Studio 2010, появилась возможность существенно упростить развёртывание VSPackage модулей с помощью VSIX пакетов. VSIX пакет представляет из себя стандартный OPC (Open Packaging Conventions) архив, содержащий бинарные файлы плагина и все необходимые для их развёртывания вспомогательные файлы. Данный архив может быть передан стандартной утилите VSIXInstaller.exe, которая автоматически зарегистрирует содержащиеся в нём модули-расширения.
С помощью инсталлятора VSIX можно также удалить установленный пакет командой /uninstall, с указанием уникального GUID идентификатора модуля.
Cодержимое VSIX контейнера задаётся через специальный файл vsixmanifest, который должен быть добавлен в проект плагина. Vsixmanifest позволяет задать:
- поддерживаемые модулем целевую версию и редакцию среды Visual Studio для установки;
- GUID модуля;
- необходимые для регистрации компоненты (VSPackage, MEF component, toolbox control и т.д.);
- информацию об устанавливаемом модуле (описание, лицензия, версия и т.п.).
Для включения в контейнер дополнительных файлов из проекта необходимо задать для этих файлов в MSBuild проекте узел IncludeInVSIX (можно также отметить такие файлы в SolutionExplorer через окно Properties).
Фактически VSIX файл — это полноценный инсталлятор для расширений Visual Studio последних версий (20010 и 2012), позволяющий установить пакет методом "одного клика". Публикация VSIX пакета на официальном сайте IDE расширений Visual Studio Gallery позволит пользователю устанавливать такой модуль через диалог среды Tools -> Extension Manager.
Появившиеся в VS2010 инсталляции в виде VSIX существенно облегчили пользователю (да и разработчику) установку расширений. Причем на столько, что некоторые разработчики плагинов делают только инсталлятор для VS2010, лишь бы не связываться с разработкой плагина и инсталлятора для старых версий Visual Studio.
На практике, к сожалению, как это часто бывает в программистском мире возможны проблемы при использовании VSIX инсталлятора совместно с интерфейсом extension manager в Visual Studio 2010. В частности, в некоторых случаях бинарные файлы не всегда удаляются корректно, что блокирует работу как VSIX инсталлятора, так и студийного extension manager и вынуждает находить и удалять эти файлы вручную. Поэтому следует использовать VSIX с осторожностью, по возможности обеспечивая перед началом установки прямое удаление файлов от старой версии устанавливаемого плагина.
Package Load Key
Каждый загружаемый в Visual Studio модуль VSPackage должен содержать уникальный PLK (Package Load Key) ключ. PLK ключ задаётся через атрибут ProvideLoadKey класса Package для версий IDE 2005 и 2008.
Начиная с Visual Studio 2010, наличие PLK и, соответственно, атрибута ProvideLoadKey, не является обязательным, однако его можно использовать в случае, если разрабатываемый модуль нацелен на несколько версий среды MSVS. Для получения PLK ключа необходимо зарегистрироваться на портале Visual Studio Industry Partner, т.е. PLK ключ гарантирует, что в среде разработки загружены только пакеты, сертифицированные Microsoft. Однако для машин с установленным пакетом Visual Studio SDK делается исключение. Вместе с SDK устанавливается Developer License Key, позволяющий в дальнейшем загружать в соответствующей данной SDK среде Visual Studio любой модуль расширения, независимо от достоверности его PLK ключа.
И еще раз стоит напомнить о необходимости тестировать готовый дистрибутив на машине без установленного Visual Studio SDK. Дело в том, что если у вас задан неправильный ключ PLK, то на машине разработчика понять это будет непросто, так как модуль расширения будет работать.
Особенности регистрации расширений при поддержке нескольких версий Visual Studio
По умолчанию шаблон VSPackage генерирует проект расширения для текущей, используемой при разработке, версии Visual Studio. Однако это не является необходимым требованием, т.е. возможна разработка расширения для одной версии среды с использованием другой версии. Стоит помнить, что при автоматическом обновлении файла проекта до более новой версии через devenv /Upgrade целевая версия IDE и, соответственно, подключенные managed API библиотеки-обёртки останутся неизменными, т.е. от предыдущей версии Visual Studio.
Для изменения целевой версии Visual Studio (а точнее для регистрации плагина именно в этой версии среды) необходимо поменять значения, передаваемые атрибуту DefaultRegistryRoot (для версий 2005 и 2008, начиная с версии Visual Studio 2010 данный атрибут не нужен), или поменять целевую версию в файле манифеста VSIX (для версий после 2008).
Поддержка VSIX появилась только в Visual Studio 2010, поэтому для сборки и отладки плагина для более ранних версий из Visual Studio 2010 (и более новых версий) необходимо будет обеспечить выполнение всех ранее описанных шагов регистрации вручную, без использования манифеста VSIX. При изменении целевой версии IDE стоит не забывать менять и версии используемых в плагине managed библиотек-обёрток для COM интерфейсов.
Изменение целевой версии IDE для плагина затрагивает следующие атрибуты класса Package:
рософт для создания , документирования , запуска и отладки программ , написанных на различных языках программирования .
VS – мощный инструмент , который позволяет разрабатывать слож - ные программные комплексы , имеющие множественные типы взаимо - действия с пользователями в виде различных диалоговых окон , пане - лей инструментов , меню , кнопок , списков и т . п . Эти программы называются оконными приложениями ( или Windows- приложениями ) и обеспечивают графические пользовательские интерфейсы .
Наряду с оконными приложениями , VS также позволяет писать , ком - пилировать и тестировать консольные приложения . Это символьно - ориентированные программы командной строки , которые взаимодейст - вуют с пользователями через клавиатуру и экран , работающий в сим - вольном режиме .
Поскольку в исходных текстах даже простых оконных приложений присутствует слишком много кода ( который к тому же часто содер - жится сразу в нескольких файлах ), очень важно , чтобы сложности , свя - занные с разработкой оконного интерфейса не затмили для начинаю - щих азы самого языка программирования C/ С ++ ( без знания которых невозможно серьезно заниматься программированием под Windows). По этой причине разработка консольных приложений , которые не тре - буют всего необходимого оконными приложениям багажа , – лучший способ изучения основ языка C/ С ++.
В данной работе представлен обзор инструментальных средств VS, необходимых для создания и отладки простых консольных программ , а также на примерах показано , как использовать эти средства .
КРАТКИЙ ОБЗОР СРЕДЫ РАЗРАБОТКИ
VISUAL STUDIO 2008
Решения и проекты
С точки зрения программирования , все , что вы делаете внутри VS, происходит в контексте решения . Решение – это виртуальный контей - нер высшего уровня для прочих элементов разработки . Решение может содержать один или несколько проектов , а также файлы разнообраз - ных типов ( текстовые документы , диаграммы проектов и т . д .), но не может содержать внутри себя другие решения .
Проект – это контейнер более низкого уровня , который всегда на - ходится внутри какого - то решения и используется в интегрированной среде в качестве организационной единицы для размещения и группи - ровки файлов приложения .
Решения полезны , поскольку они позволяют обращаться с разными проектами как с единым элементом работы . С помощью группирова - ния проектов в одно решение можно работать с ними в одном экземп - ляре VS. Кроме того , решение упрощает некоторые задачи конфигури - рования ( вы можете применять настройки ко всем дочерним проектам решения ). Можно также делать « сборку » решения . В этом случае само по себе решение не компилируется , но составляющие его проекты мо -
гут собираться в готовые приложения при помощи одной команды сборки , выдаваемой для всего решения .
Когда вы впервые попадаете в интегрированную среду разработки VS, то видите Начальную страницу этого инструмента . На рис . 1 по - казан пример такой страницы ( если Начальная страница закрыта , то
в меню можно выбрать команду Вид ► Другие окна ► Начальная страница ).
стандартная панель инструментов
Рис . 1. Начальная страница Visual Studio 2008
В левом верхнем углу окна Начальная страница имеется область Последние проекты . Отсюда можно загрузить проект , над которым недавно работали , либо создать новый .
В табл . 1 приведены краткие описания наиболее часто используе - мых пунктов меню и связанных с ними команд ( рис . 1 и 2).
Вы создали проект консольного приложения C++ и ввели код. Теперь вы можете выполнить сборку приложения и запустить его в Visual Studio. Затем запустите его как автономное приложение из командной строки.
Предварительные требования
Установите и запустите на своем компьютере Visual Studio с рабочей нагрузкой "Разработка классических приложений на C++". Если установка еще не выполнена, следуйте инструкциям в статье Установка поддержки C++ в Visual Studio.
Создайте проект "Hello, World!" и введите его исходный код. Если вы еще не сделали этого, выполните действия, описанные в разделе Создание проекта консольного приложения С++.
Если Visual Studio выглядит следующим образом, можно приступать к сборке и запуску приложения:
Сборка и запуск кода в Visual Studio
Для сборки проекта выберите в меню Сборка пункт Собрать решение. Окно Вывод отображает результаты процесса сборки.
Чтобы запустить этот код, в строке меню выберите Отладка и Запуск без отладки.
Поздравляем! Вы создали свое первое консольное приложение "Hello World" в Visual Studio! Нажмите любую клавишу, чтобы закрыть окно консоли и вернуться в редактор Visual Studio.
Выполнение кода в командном окне
Обычно консольные приложения запускаются из командной строки, а не в Visual Studio. После того как приложение будет создано в Visual Studio, его можно запустить из любого командного окна. Вот как можно найти и запустить новое приложение в окне командной строки.
В обозревателе решений выберите решение HelloWorld (а не проект HelloWorld) и щелкните правой кнопкой мыши, чтобы открыть контекстное меню. Выберите Открыть папку в проводнике, чтобы открыть окно проводника в папке решения HelloWorld.
В окне проводника откройте папку Debug. В этой папке содержится ваше приложение, HelloWorld.exe и несколько других файлов отладки. Удерживая нажатой клавишу SHIFT, щелкните правой кнопкой мыши HelloWorld.exe, чтобы открыть контекстное меню. Выберите команду Копировать как путь, чтобы скопировать путь к приложению в буфер обмена.
Чтобы открыть окно командной строки, нажмите Windows + R, чтобы открыть диалоговое окно Выполнить. Введите cmd.exe в текстовом поле Открыть, а затем выберите ОК для запуска окна командной строки.
В окне командной строки щелкните правой кнопкой мыши, чтобы вставить путь к приложению в командную строку. Нажмите клавишу ВВОД, чтобы запустить приложение.
Поздравляем! Вы создали и запустили консольное приложение в Visual Studio.
Следующие шаги
После создания и запуска этого простого приложения можно приступать к более сложным проектам. Дополнительные сведения см. в разделе Использование интегрированной среды разработки Visual Studio для разработки приложений для настольных систем на языке C++. В нем содержатся более подробные пошаговые руководства, посвященные возможностям Microsoft C++ в Visual Studio.
Руководство по устранению неполадок
Здесь приведены решения распространенных проблем, которые могут возникнуть при создании первого проекта C++.
Сборка и запуск кода в Visual Studio: проблемы
Если в редакторе исходного кода отображаются красные волнистые линии, то сборка может содержать ошибки или предупреждения. Убедитесь, что код соответствует примеру в написании, пунктуации и регистре.
Выполнение кода в командном окне: проблемы
Если путь, показанный в проводнике, заканчивается на \HelloWorld\HelloWorld, вы открыли проект HelloWorld вместо решения HelloWorld. Вы перепутаете папку Debug, в которой нет вашего приложения. Перейдите на уровень вверх в проводнике, чтобы открыть папку решения — первый HelloWorld в пути. В этой папке также содержится папка Debug, в которой вы найдете свое приложение.
Можно также открыть папку Debug решения в командной строке, чтобы запустить приложение. Приложение не будет запускаться из других каталогов, если не указан путь к приложению. Однако вы можете скопировать приложение в другой каталог и запустить его из него. Также можно скопировать его в каталог, указанный переменной среды PATH, а затем запустить его из любого места.
Если в контекстном меню отсутствует параметр Копировать как путь, закройте меню, а затем удерживайте нажатой клавишу SHIFT при повторном открытии. Эта команда предназначена только для удобства. Можно также скопировать путь к папке из панели поиска проводника и вставить его в диалоговое окно Выполнить, а затем ввести имя исполняемого файла в конце. При этом потребуется чуть больше действий по вводу текста, но результат будет тем же.
Статья описывает основные шаги, требуемые для осуществления правильного переноса 32-битных приложений Windows в 64-битные системы Windows. Хотя статья предназначена для разработчиков, использующих C/C++ в среде Visual Studio 2005/2008, она также будет полезна для других разработчиков, намеревающихся перенести свои приложения в 64-битные системы.
Оглавление
Аннотация
Введение
1. Разбор разных 64-битных режимов
2. Выяснить, нужна ли 64-битная версия продукта
2.1. Длительность жизненного цикла приложений
2.2. Ресурсоемкость приложения
2.3. Разработка библиотек
2.4. Зависимость продукта от сторонних библиотек
2.5. Использование 16-битных приложений
2.6. Код на ассемблере
3.1. 64-битный компилятор
3.2. 64-битные компьютеры под управлением 64-битных операционных систем
3.3. 64-битные версии всех используемых библиотек
3.4. Отсутствие встроенного кода на ассемблере
3.5. Обновление методики тестирования
3.6. Новые данные для тестирования
3.7. 64-битные системы защиты
3.8. Установочный пакет
4. Настройка проекта в Visual Studio 2005/2008
5. Компиляция приложения
6. Выявление скрытых ошибок
6.1. Явное преобразование типа
6.2. Неявное преобразование типа
6.3. Биты и сдвиги
6.4. Магические числа
6.5. Ошибки, касающиеся использования 32-битных переменных в качестве индексов
6.6. Ошибки, касающиеся изменения типов используемых функций
6.7. Выявление скрытых ошибок
7. Обновление процесса тестирования
Аннотация
Статья описывает основные шаги, требуемые для осуществления правильного переноса 32-битных приложений Windows в 64-битные системы Windows. Хотя статья предназначена для разработчиков, использующих C/C++ в среде Visual Studio 2005/2008, она также будет полезна для других разработчиков, планирующих перенести свои приложения в 64-битные системы.
Введение
Статья описывает основные проблемы, стоящие перед разработчиками, планирующими перенести 32-битные программы на 64-битные системы. Конечно, список рассмотренных проблем не исчерпывающий, но в дальнейшем будет создан более подробный список. Автор будет рад получить отклики, комментарии и вопросы, помогающие повысить информативность статьи.
1. Разбор разных 64-битных режимов
В рамках архитектуры компьютера под термином "64-битный" понимаются 64-битные целые числа и иные типы данных размером 64 бит. Под "64-битными" системами могут пониматься 64-битные архитектуры микропроцессора (например, EM64T, IA-64) или 64-битная операционная система (например, Windows XP x64 профессиональная версия).
AMD64 (или x86-64, Intel 64, EM64T, x64) - 64-битная архитектура микропроцессора и соответствующая система команд, разработанные компанией AMD. Эта система команд была лицензирована компанией Intel под именем EM64T (Intel64). Архитектура AMD64 является расширением архитектуры x86 с полной обратной совместимостью. Архитектура стала распространенной в качестве основного компонента персональных компьютеров и рабочих станций.
IA-64 - 64- битная архитектура микропроцессора, разработанная совместно компаниями Intel и Hewlett Packard. Она реализована в микропроцессорах Itanium и Itanium 2. Архитектура в основном используется в многопроцессорных серверах и кластерных системах.
AMD64 и IA-64 – две разные 64-битные архитектуры, несовместимые друг с другом. Поэтому разработчики должны сразу решить, нужна ли им поддержка обеих архитектур или лишь одной из них. Большей частью, если вы не разрабатываете узкоспециализированное программное обеспечение (ПО) для кластерных систем или не реализуете свою собственную высокопроизводительную СУБД, вам понадобиться реализовать поддержку только архитектуры AMD64, гораздо более популярной, чем IA-64. Это особенно касается ПО для рынка ПК, почти на 100% занятого архитектурой AMD64.
Далее в статье рассматривается только архитектура AMD64 (EM64T, x64), поскольку сейчас она наиболее актуальна для разработчиков прикладного ПО.
Говоря о разных архитектурах, надо упомянуть понятие "модель данных". Под моделью данных понимаются соответствия между размерами типов, принятых внутри среды разработки. Может иметься несколько средств разработки, придерживающихся разных типов данных для одной операционной системы. Но обычно преобладает только одна модель, максимально соответствующая аппаратно-программной среде. Таким примером является 64-битная Windows, исходная модель данных которой - LLP64. Но ради совместимости 64-битная Windows поддерживает выполнение 32-битных программ, работающих в режиме модели данных ILP32LL. Таблица 1 дает сведения об основных моделях данных.
Таблица 1. Модели данных.
Используемая модель данных влияет на процесс разработки 64-битных приложений, так как надо учитывать размеры данных, используемых в программном коде.
Читайте также: