Код, написанный в Vista 64, совместим с 32-битной ОС?

Question

Мы получаем новые машины для разработки и переходим на Vista 64 Ultimate, чтобы воспользоваться преимуществами нашего 8 Гб оперативной памяти. Наш менеджер хочет, чтобы мы делали все разработки на 32-битных виртуальных машинах, чтобы не было проблем с переходом нашего кода в производство.

Есть ли способ гарантировать, что результирующие программы будут работать на 32-битных ОС? Я не возражаю против использования виртуальных машин, но мне не нравится, как они заставляют вас вернуться к представлению типа «Одиночный» монитор. Мне нравится перемещать панели инструментов VS на другой монитор.

РЕДАКТИРОВАТЬ: Мы используем Visual Studio 2005 и 2008, VB.NET и / или C #

РЕДАКТИРОВАТЬ: Используя ответ Harpreet , это шаги, которые я использовал для настройки среды IDE Visual Studio для компиляции x86 / 32bit:

1. Нажмите Построить и откройте Configuration Manager
2. Выберите выпадающий список Active Solution Platform
3. Выберите x86, если он есть в списке, и перейдите к шагу 5, если нет Выберите <New...>
4. В диалоговом окне New Solution Platform выберите x86 и нажмите OK
5. Убедитесь, что выбранная платформа для всех ваших проектов - x86
6. Нажмите Закрыть.

Наслаждайтесь.

Спасибо, Кит

Answer 1

Я занимаюсь разработкой на 64-битных машинах для 32-битной Windows. Это не проблема. Вы должны убедиться, что ваши проекты настроены на компиляцию в режиме x86, чтобы быть консервативными. Вы захотите просмотреть каждый проект в решении и дважды проверить это. Вы также можете использовать настройку AnyCPU, но это немного опаснее, поскольку она будет работать не так, как 32-разрядная машина. Конечно, вы хотите избежать 64-битного режима.

Проблемы, с которыми я столкнулся, - это драйверы, которые не работают, когда приложение скомпилировано для 64-битной системы (явно 64-битная или AnyCPU, скомпилированная и работающая в 64-битной Windows). Таких проблем можно полностью избежать, придерживаясь компиляции x86. Это должно выявить все недостатки на ваших машинах для разработчиков.

В идеале вы можете настроить среду сборки и тестирования, которую можно часто выполнять на 32-битной машине. Это должно успокоить ваше управление и позволить вам избежать использования виртуальной машины в качестве рабочего стола.

Answer 2

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

Answer 3

Мы разрабатываем 32-разрядное приложение для VS 2005 (скоро 2008 г.) и только что приобрели несколько новых машин с 64-разрядными версиями XP Pro x64 или Vista Business, чтобы мы могли воспользоваться дополнительной оперативной памятью и одновременно наблюдать за ней кратко о возможности создания 64-битного порта, если это становится коммерчески необходимым для этого. У нас не было никаких проблем с этим, кроме настройки некоторых скриптов в нашей среде разработки и т. Д.

Те разработчики, которые не были включены в этот цикл обновления, по-прежнему используют 32-разрядные машины, поэтому они должны обнаруживать проблемы, когда модульные тесты и набор тестов приложений запускаются как само собой разумеющееся до регистрации. 1003 *

Мы также должны убедиться, что у нас есть набор «тестовых сборок», состоящих из «типичных» конфигураций (XP / Vista, 2/4/8 ядер и т. Д.), Которые собирают и тестируют наборы проверки - у нас есть различные тестовые наборы на стабильность, производительность и т. д. - перед их добавлением в область интеграции. Опять же, у них не возникло никаких проблем с запуском 32-разрядного приложения, созданного в 64-разрядной ОС.

В любом случае, как уже говорили другие, я не ожидал, что это станет проблемой, потому что именно компилятор генерирует соответствующий код для целевой ОС независимо от ОС, на которой фактически работает компилятор.

Answer 4

Не ответ на ваш вопрос, но, возможно, решение вашей проблемы: VirtualBox (и, возможно, другие) поддерживает режим «бесшовной интеграции», который просто дает вам вторую панель запуска и позволяет свободно перетаскивать окна.

Кроме того, и это ответ на ваш вопрос, это зависит от ваших настроек компиляции. Вы можете компилировать для разных сред, и вы можете идеально компилировать 32-битные программы в 64-битной системе с помощью Visual Studio. Не могу сказать, как, но я уверен, что некоторые гуру Visual Studio могли бы помочь вам.

Answer 5

Компиляция для 64-битной ОС является опцией в компиляторе. Вы можете абсолютно скомпилировать 32-битный exe из Vista 64 бит. Когда вы запускаете приложение, вы можете увидеть в TaskManager, что рядом с процессом есть «* 32» ... это означает, что оно 32-битное;)

Я считаю, что вашим менеджерам нужно больше узнать о том, что на самом деле означает 64-битная ОС:)

Answer 6

Нашел сегодня:

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

x64 Разработка с использованием .NET

Ранее в этом году я перешел на 64-разрядную операционную систему - точнее, Vista Ultimate x64. По большей части этот процесс был относительно безболезненным, но на этом пути было несколько сбоев (в основном, x64-совместимые драйверы, но это не главное в этом обсуждении).

В мире разработки для x64 было несколько проблемных моментов, которые я хотел бы изложить здесь. Этот список, вероятно, будет расти, поэтому ожидайте будущих сообщений по этому вопросу.

В прекрасном мире разработки .NET приложения и сборки могут быть скомпилированы для различных платформ. По умолчанию приложения и сборки компилируются как Любой ЦП в Visual Studio. В этом сценарии CLR загрузит сборку как цель по умолчанию для машины, на которой она выполняется. Например, при запуске исполняемого файла на компьютере x64 он будет выполняться как 64-разрядный процесс.

Visual Studio также предусматривает 3 конкретные цели платформы: x86, x64 и Itanium (IA-64). При создании исполняемого файла в качестве конкретной цели он будет загружен как процесс этого типа. Например, исполняемый файл с целевой архитектурой x86 на компьютере с архитектурой x64 будет работать как 32-разрядный процесс с использованием 32-разрядного уровня CLR и уровня WOW64. Когда сборки загружаются во время выполнения, они могут быть загружены процессом только в том случае, если их цель соответствует цели хост-процесса или она скомпилирована как Любой ЦП. Например, если в качестве цели сборки была выбрана x64, она может быть загружена только процессом x64.

Это вошло в игру в нескольких сценариях для меня:

• XNA - XNA доступна только в виде набора 32-разрядных сборок. Поэтому при обращении к сборкам XNA исполняемый файл / сборка, использующая их, должен быть ориентирован на платформу x86. Если он настроен как x64 (или как любой ЦП и работает на 64-разрядной машине), при попытке загрузить сборки XNA будет выдана ошибка.

• Microsoft Robotics Studio - XInputGamepadService внутренне использует XNA для связи с контроллером Xbox 360. Смотри выше.

• Управляемый DirectX - хотя это уже устарело и заменяется на XNA, оно все еще используется. Сборки не помечены для определенной цели, однако у меня возникли проблемы с исключениями памяти, особенно с сборкой Microsoft.DirectX.AudioVideoPlayback.

• Фиджеты - в зависимости от того, какую библиотеку вы загружаете и когда, она может быть помечена или не помечена как 32-разрядная. Текущая версия (11/8/07) помечена как таковая, поэтому для ее размещения требуется 32-разрядный процесс. Самый простой способ определить, предназначен ли исполняемый файл или сборка для конкретной платформы, - это использовать приложение corflags. Чтобы использовать это, откройте командную строку Visual Studio из меню «Пуск» и запустите ее для сборки, которую вы хотите проверить.

Самый простой способ определить, предназначен ли исполняемый файл или сборка для конкретной платформы, - это использовать приложение corflags. Чтобы использовать это, откройте командную строку Visual Studio из меню «Пуск» и запустите ее для сборки, которую вы хотите проверить.

Answer 7

Да, как говорил Адам. Есть 3 варианта: MSIL (по умолчанию), x64 и x86. Вы можете использовать x64, и он будет генерировать dll специально для 64-битных систем, или вы можете использовать x86, который будет работать в 32-битной и 64-битной системах, но будет иметь те же ограничения, что и 32-битные в 64-битной системе.

MSIL в основном позволяет JITer выдавать специфическую для платформы инструкцию (с небольшим снижением производительности по сравнению с собственным образом)

РЕДАКТИРОВАТЬ : нет языка, поэтому я говорю о языках .net Framework, таких как vb.net и c #, c ++ - это совершенно другое животное.