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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Когда сборки загружаются во время выполнения, они могут быть загружены процессом только в том случае, если их цель совпадает с целью хост-процесса или если он скомпилирован как Any CPU. Например, если x64 был установлен в качестве целевого объекта для сборки, он может быть загружен только процессом x64.

Для меня это проявилось в нескольких сценариях:

• XNA - XNA доступен только как набор 32-битных сборок. Следовательно, при обращении к сборкам XNA исполняемый файл / сборка, использующая их, должны быть нацелены на платформу x86. Если он нацелен как x64 (или как Any CPU и работает на 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 из меню «Пуск» и запустите ее для сборки, которую вы хотите проверить.