¿El código escrito en Vista 64 es compatible con sistemas operativos de 32 bits?

Question

Estamos adquiriendo nuevas máquinas de desarrollo y pasando a Vista 64 Ultimate para aprovechar nuestra RAM de 8 GB.Nuestro gerente quiere que hagamos todo el desarrollo en máquinas virtuales de 32 bits para asegurarnos de que no haya problemas con el paso de nuestro código a producción.

¿Hay alguna forma de garantizar que los programas resultantes funcionen en sistemas operativos de 32 bits?No me importa usar máquinas virtuales, pero no me gusta cómo te obligan a volver a una vista de tipo monitor "único".Me gusta mover mis barras de herramientas VS a mi otro monitor.

EDITAR:Estamos usando Visual Studio 2005 y 2008, VB.NET y/o C#

EDITAR:Usando Harpreet respuesta, estos son los pasos que utilicé para configurar mi IDE de Visual Studio para compilar x86/32 bits:

1. Haga clic en Construir y abra el Administrador de configuración.
2. Seleccione la lista desplegable Plataforma de solución activa
3. Seleccione x86 si está en la lista y vaya al paso 5, si no. Seleccione <New...>
4. En el cuadro de diálogo Nueva plataforma de solución, seleccione x86 y presione Aceptar
5. Verifique que la plataforma seleccionada para todos sus proyectos sea x86
6. Haga clic en Cerrar.

Disfrutar.

Gracias Keith

Answer 1

Hago desarrollo en máquinas de 64 bits para Windows de 32 bits.No es un problema.Debes asegurarte de que tus proyectos estén configurados para compilarse en modo x86 para ser conservador.Querrá revisar cada proyecto de la solución y volver a verificarlo.También puede usar la configuración AnyCPU, pero es un poco más riesgoso ya que se ejecutará de manera diferente en su máquina de desarrollo que en una máquina de 32 bits.Por supuesto, debes evitar el modo de 64 bits.

Los problemas con los que me he encontrado son controladores que no funcionan cuando la aplicación está compilada para 64 bits (explícitamente 64 bits o AnyCPU compilado y ejecutándose en Windows de 64 bits).Esos problemas se pueden evitar por completo si se sigue con la compilación x86.Eso debería revelar todas las fallas en sus máquinas de desarrollo.

Lo ideal sería configurar un entorno de compilación y prueba que pudiera ejecutarse con frecuencia en una máquina de 32 bits.Esto debería tranquilizar a su administración y permitirle evitar la VM como su escritorio.

Answer 2

Siempre que compile sus ejecutables en 32 bits, se ejecutarán en máquinas Windows de 32 y 64 bits (garantizado).El uso de máquinas de desarrollo de 64 bits tiene la ventaja de que puede comenzar a probar su código con una compilación de 64 bits (para comprobar cosas como punteros convertidos a enteros de 32 bits), lo que facilita la transición a 64 bits en el futuro (si su empresa elige para hacer una versión de 64 bits).

Answer 3

La compilación para un sistema operativo de 64 bits es una opción en el compilador.Puede compilar absolutamente en un exe de 32 bits desde Vista de 64 bits.Cuando ejecutas la aplicación, puedes ver en el Administrador de tareas que hay un "*32" al lado del proceso... esto significa que es de 32 bits;)

Creo que sus gerentes necesitan más educación sobre lo que realmente significa el sistema operativo de 64 bits :)

Answer 4

No es una respuesta a su pregunta, pero posiblemente una solución a su problema:VirtualBox (y probablemente otros) admite el modo de "integración perfecta", que simplemente le brinda una segunda barra de inicio y le permite arrastrar ventanas libremente.

Además, y esta es una respuesta a su pregunta, depende de su configuración de compilación.Puede compilar para diferentes entornos y puede compilar perfectamente programas de 32 bits en un sistema de 64 bits con Visual Studio.No puedo decirte cómo, pero estoy seguro de que algún gurú de Visual Studio podría ayudarte.

Answer 5

Desarrollamos una aplicación de 32 bits usando VS 2005 (2008 pronto) y acabamos de comprar algunas máquinas nuevas con XP Pro x64 o Vista Business de 64 bits para que podamos aprovechar la RAM adicional mientras observamos brevemente el posibilidad de hacer un port de 64 bits si fuera comercialmente necesario hacerlo.No hemos tenido ningún problema al hacer esto aparte de modificar algunos scripts en nuestro entorno de desarrollo, etc.

Aquellos desarrolladores que no fueron incluidos en este ciclo de actualización todavía usan máquinas de 32 bits, por lo que deberían detectar problemas cuando las pruebas unitarias y el conjunto de pruebas de aplicaciones se ejecutan de forma habitual antes de realizar el check-in.

Lo que también hacemos es asegurarnos de tener un conjunto de máquinas de "construcción de prueba" compuestas por configuraciones "típicas" (XP/Vista, 2/4/8 núcleos, etc.) que construyen y prueban conjuntos de registros. - Contamos con varios conjuntos de pruebas diferentes para estabilidad, rendimiento, etc.- antes de que se agreguen al área de integración propiamente dicha.Nuevamente, estos no han detectado ningún problema al ejecutar una aplicación de 32 bits construida en un sistema operativo de 64 bits.

De todos modos, como ya han dicho otros, no esperaría que fuera un problema porque es el compilador el que genera el código apropiado para el sistema operativo de destino, independientemente del sistema operativo en el que realmente se ejecuta el compilador.

Answer 6

Sí, como decía Adam.Hay 3 opciones:MSIL (predeterminado), x64 y x86.Puede apuntar a x64 y generará archivos dll específicamente para sistemas de 64 bits, o puede usar x86, que se ejecutará en 32 y 64 bits, pero tendrá las mismas restricciones que 32 bits en un sistema de 64 bits.

MSIL básicamente permitirá que JITer emita la instrucción específica de la plataforma (con una ligera penalización de rendimiento en comparación con una imagen nativa)

EDITAR:no hay lenguaje, así que estoy hablando de lenguajes .net framework como vb.net y c#, c++ es un animal completamente diferente.

Answer 7

Encontré esto hoy:

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

Desarrollo x64 con .NET

A principios de este año hice el cambio a un sistema operativo de 64 bits: Vista Ultimate x64 para ser exactos.En su mayor parte, este proceso ha sido relativamente sencillo, pero ha habido algunos contratiempos en el camino (controladores compatibles con x64, principalmente, pero ese no es el punto de esta discusión).

En el mundo del desarrollo x64, ha habido algunos puntos problemáticos que pensé describir aquí.Es probable que esta lista crezca, así que espere publicaciones futuras sobre el tema.

En el maravilloso mundo del desarrollo .NET, las aplicaciones y ensamblados se pueden compilar para apuntar a varias plataformas.De forma predeterminada, las aplicaciones y ensamblados se compilan como Cualquier CPU en Visual Studio.En este escenario, CLR cargará el ensamblado como sea cual sea el destino predeterminado para la máquina en la que se está ejecutando.Por ejemplo, cuando se ejecuta un ejecutable en una máquina x64, se ejecutará como un proceso de 64 bits.

Visual Studio también proporciona tres objetivos de plataforma específicos:x86, x64 e Itanium (IA-64).Al crear un ejecutable como un objetivo específico, se cargará como un proceso de ese tipo.Por ejemplo, un ejecutable dirigido a x86 que se ejecute en una máquina x64 se ejecutará como un proceso de 32 bits utilizando la capa CLR y WOW64 de 32 bits.Cuando los ensamblados se cargan en tiempo de ejecución, solo pueden ser cargados por un proceso si su destino coincide con el del proceso de alojamiento o si está compilado como Cualquier CPU.Por ejemplo, si se estableció x64 como destino para un ensamblado, solo se puede cargar mediante un proceso x64.

Esto ha entrado en juego en algunos escenarios para mí:

• XNA: XNA está disponible únicamente como un conjunto de ensamblados de 32 bits.Por lo tanto, al hacer referencia a los ensamblados XNA, el ejecutable/ensamblado que los utiliza debe estar dirigido a la plataforma x86.Si está diseñado como x64 (o como Cualquier CPU y se ejecuta en una máquina de 64 bits), se generará un error al intentar cargar los ensamblados XNA.

• Microsoft Robotics Studio: XInputGamepadService utiliza XNA internamente para comunicarse con el controlador Xbox 360.Véase más arriba.

• DirectX administrado: si bien esto ya está en desuso y se está reemplazando por XNA, todavía tiene sus usos.Los ensamblados no están marcados para un objetivo específico; sin embargo, tuve dificultades con las excepciones de memoria, especialmente con el ensamblado Microsoft.DirectX.AudioVideoPlayback.

• Phidgets: dependiendo de la biblioteca que descargue y cuándo, puede estar marcada o no como solo de 32 bits.La versión actual (8/11/07) está marcada como tal y, por lo tanto, requiere un proceso de 32 bits para alojarla.La forma más sencilla de determinar si un ejecutable o ensamblado está destinado a una plataforma específica es utilizar la aplicación corflags.Para usar esto, abra un símbolo del sistema de Visual Studio desde su menú Inicio y ejecútelo en el ensamblado que desea verificar.

La forma más sencilla de determinar si un ejecutable o ensamblado está destinado a una plataforma específica es utilizar la aplicación corflags.Para usar esto, abra un símbolo del sistema de Visual Studio desde su menú Inicio y ejecútelo en el ensamblado que desea verificar.