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

Question

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

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

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

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

1. Нажмите «Создать» и откройте диспетчер конфигурации.
2. Выберите раскрывающийся список «Платформа активных решений».
3. Выберите x86, если он есть в списке, и перейдите к шагу 5, если нет. Выберите <New...>
4. В диалоговом окне «Новая платформа решения» выберите x86 и нажмите «ОК».
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

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

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

Answer 4

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

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

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 также предоставляет три конкретных целевых платформы: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-разрядная.Текущая версия (08.11.07) помечена как таковая, поэтому для ее размещения требуется 32-разрядный процесс.Самый простой способ определить, предназначен ли исполняемый файл или сборка для конкретной платформы, — использовать приложение corflags.Чтобы использовать это, откройте командную строку Visual Studio из меню «Пуск» и запустите ее для сборки, которую вы хотите проверить.

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