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

Question

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

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

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

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

1. Нажмите Build и откройте 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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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.

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

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