Является ли код, написанный на Vista 64 совместимым с 32-битным os?

Question

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

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

EDIT: Мы используем Visual Studio 2005 и 2008, VB.NET и/или C#

EDIT: Использование Harpreet-х answer, эти шаги, которые я использовал, чтобы установить мой Visual Studio IDE для компиляции x86/32bit:

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

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

Спасибо, Кит

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

EDIT: нет языка, поэтому я говорю о .NET Framework языках, как VB .net и C#, C++ - совершенно другое животное.

Answer 6

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

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

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

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

Answer 7

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

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.

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

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