Is code written on Vista 64 compatible with 32-bit os?

Question

We get new machines for developers and move on to Vista 64 Ultimate to take advantage of our 8GB bar. Our manager wants us to do all the developers on 32-bit virtual machines to make sure that there will be no production problems with our code.

Is there a way to guarantee that the resulting programs will run on 32-bit OS? I don’t mind using virtual machines, but I don’t like the way they make you return to the “Single” type of monitor. I like to move VS toolbars to another monitor.

EDIT: we use Visual Studio 2005 and 2008, VB.NET and / or C #

EDIT: using the Harpreet command, these are the steps that I used to install my Visual Studio environment to compile x86 / 32bit:

• Click "Create" and open "Configuration Manager"
• Highlight Active Solution Platform drop-down
• Select x86 if it is listed, and go to step 5 if you do not select <New... >
• In the New Solution Platform dialog box, select x86 and click OK
• Check the chosen platform for all your projects - x86
• Click "Close."

Enjoy.

Thanks Kit

Answer 1

I am doing development on 64-bit machines for 32-bit Windows. It's not a problem. You need to make sure your projects are configured to compile in x86 mode to be conservative. You will want to go through each project in the solution and double-check it. You can also use the AnyCPU parameter, but this is a bit risky, since it will work differently on your development machine than on a 32-bit machine. Of course, you want to avoid 64-bit mode.

The problems that I encountered are drivers that do not work when the application is compiled for 64-bit (explicitly 64 bit or AnyCPU compiled and runs on 64-bit Windows). These problems can be completely avoided by sticking to x86 compilation. This should reveal all the flaws of your development machines.

Ideally, you can set up a build and test environment that can often be performed on a 32-bit machine. This should reassure your management and allow you to avoid the virtual machine as a desktop.

Answer 2

As long as you compile your executables as 32 bits, they will work on both 32-bit and 64 Windows machines (guaranteed). The advantage of using 64-bit machines is that you can start testing the code using 64-bit compilation (to test things like pointers other than 32-bit integers), thus making it easier to switch to 64-bit code in the future (if you choose your company for the 64-bit version).

Answer 3

Compilation for a 64-bit OS is an option in the compiler. You can fully compile a 32-bit exe from a 64-bit version of Vista. When you start the application, you can see in the TaskManager that there is "* 32" next to the process ... this means that it is 32bit;)

I believe that your managers also need education on a 64-bit OS:

Answer 4

Not the answer to your question, but perhaps the solution to your problem: VirtualBox (and possibly others) supports the "seamless integration" mode, which simply gives you a second launch bar and allows you to freely move windows.

In addition, and this is the answer to your question, it depends on your compilation settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. I can’t say how to do this, but I'm sure some Visual Studio gurus can help you.

Answer 5

We are developing a 32-bit application using VS 2005 (coming soon in 2008), and have just bought several new computers with 64-bit XP Pro x64 or Vista Business processors so that we can use the additional RAM, a brief summary of the possible execution 64 -bit port if it becomes commercially necessary for this. We had no problems with this except setting up some scripts in our development environment, etc.

Those developers who were not included in this update cycle still use 32-bit machines, so they should solve problems when unit tests and a set of application tests are run, as a rule, before registration.

What we also do is make sure that we have a set of “test build” machines consisting of “typical” configurations (XP / Vista, 2/4/8 cores, etc.) that build and test many check-ins - we have different test suites for stability, performance, etc. - before they are added to the integration area. Again, they did not have problems launching a 32-bit application built on a 64-bit OS.

In any case, as others have already said, I would not expect this to be a problem, because it is a compiler that generates the appropriate code for the target OS regardless of the OS on which the compiler actually runs.

Answer 6

Yes, as Adam said. There are 3 options: MSIL (default), x64 and x86. You can target x64 and it will generate dll specifically for 64-bit systems, or you can make x86 that will work on both 32-bit and 64-bit, but it will have the same limitations as 32-bit on a 64-bit system.

MSIL will mainly allow JITER to issue instructions for a specific platform (with a slight decrease in performance compared to its own image)

EDIT : there is no language, so I'm talking about .net framework languages ​​like vb.net and C #, C ++ is a completely different animal.

Answer 7

Found it today:

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

x64 Development with .NET

At the beginning of this year, I switched to a 64-bit operating system - Vista Ultimate x64, to be exact. For the most part, this process was relatively painless, but there were a few hiccups along the way (mostly x64 compatible drivers, but that's not the point of this discussion).

There were several problem points in the x64 development world that I thought I would describe here. This list is likely to grow, so expect future posts on this.

In the beautiful world of .NET development, applications and builds can be compiled for different platforms. By default, applications and assemblies compile like any processor in Visual Studio. In this case, the CLR will load the assembly as any default target for the machine on which it runs. For example, when you run an executable on an x64 machine, it will run as a 64-bit process.

Visual Studio also provides 3 target platforms: x86, x64, and Itanium (IA-64). When creating an executable file as a specific target, it will be loaded as a process of this type. For example, x86 executable running on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64. When assemblies are loaded at run time, they can only be loaded by a process if their purpose matches the host of the process or compiled like any processor. For example, if x64 was set as the build target, it can only be downloaded using the x64 process.

This went into several scenarios for me:

• XNA - XNA is only available as a set of 32-bit assemblies. Therefore, referring to XNA assemblies, the executable / assembly using them should be aimed at the x86 platform. If it is designed as x64 (or like any processor and runs on a 64-bit machine), an error will occur when trying to load XNA assemblies.

• Microsoft Robotics Studio - XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.

• Managed by DirectX. Although it is already deprecated and replaced by XNA, it still uses it. These assemblies were not marked for a specific purpose, however, I had difficulties with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.

• Phidgets - depending on which library you download and when it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, so a 32-bit process is required to host it. The easiest way to determine if an executable or assembly is targeting a specific platform is to use the corflags application. To use this, open the Visual Studio command prompt on the Start menu and run it against the assembly you want to test.

The easiest way to determine if an executable or assembly is targeting a specific platform is to use the corflags application. To use this, open the Visual Studio command prompt on the Start menu and run it against the assembly you want to test.