/Wp64 Detects 64-bit compatibility errors. This switch is your basic tool to verify 64-bit compatibility of your source code. The /Wp64 switch gives level 4 warning for 64-bit data type issues, which is very valuable for apps which target both 32 and 64 bits
/FD Generates file dependencies. This switch is used by Visual C++ developer environment to ensure that the build engine has up-to-date dependency information. This means Visual C++ will not always have this information available. It may, therefore, occasionally be necessary to force the compile of a source file when a nested resource is changed (such as a header that is included by the original source). The switch is not available for command-line builds
/GZ Catches release build errors in the debug build. This switch is not yet supported by the IA-64 compiler, as the issues are somewhat different in the 64-bit build environment. The /W64 switch gives level 4 warning for 64-bit data type issues, which is very valuable for apps which target both 32 and 64 bits
/ZI Programs database for edit and continue. Using this switch only makes sense for use with an integrated debugger, but the SDK compiler is a standalone command-line program, so this switch is not supported. Generate debug info using /Zi (Program Database), /Z7 (C7-compatible), or /Zd (line numbers only). Change the preprocessor definition from /DWIN32 to /DWIN64 so that the 64-bit versions of the Windows APIs and structs will be defined
/machine:IA64 Obviousyou're targeting IA-64, not x86
/pdb:none Use this option to place all of the debug information in the binary image instead of in a separate program database file (pdb file), which is no longer supported by the Microsoft linker. Note that this change also applies to future releases of 32-bit build tools (such as Visual C++ 7.0)
/pdbtype:sept This option, which tells the linker to leave the debug type information distributed in the source (compiler) .PDB files, is no longer supported by the Microsoft linker. Note that this change also applies to future releases of 32-bit build tools
Linker Switches /LARGEADDRESSAWARE is especially interesting. On 32-bit Windows Advanced Server and Datacenter Server, you can give 3GB of the 4GB address space to your app. This switch says that an app is aware of and can use this extra space. For 64-bit apps this switch is on by default, and if you turn it off then all memory allocated by the system for your app will be at an address less than 2GB. This means that the top 32 bits of every allocated memory will always be zero. So if the top 32 bits of your addresses are always zero, you can throw them away and later put them back (as zeros) and it works. It would fail if some of them had been ones, as you would have lost them when you truncated. When they are all zeros you lose nothing because the truncation throws away only zero bits. This is how app memory is allocated by the WOW64, 32-bit support system. You can also use this if you have bad code that you cannot clean up, but be careful as this switch sets the allocation mode of an entire process. The system tests this switch on the EXE file when an address space is being started. You can only write a DLL that depends on memory allocations below 2GB, if you can guarantee it will only be used by an EXE that has /LARGEADDRESSAWARE:NO
Remember that if you add conflicting switches to the end of the list of settings, the last switch will override any previous conflicting switches. You should refer to the Readme.htm available with the Platform SDK install for the complete list of new and obsolete compiler and linker switches
Creating 64-bit External Projects in Visual C++ 6.0
Substitute your project name for the name Foo in these steps:
Export a makefile: <Project.Export Makefile>. This will create a file named Foo.mak.
Rename Foo.mak to Foo64.mak.
Edit Foo64.mak into a 64-bit makefile.
To the Visual C++ workspace that contains your 32-bit project, add an external Visual C++ 6.0 project (that is, add an external makefile build).
To add an external project, use the menu command <Project.Add To Project.New...>.
In the New dialog box, select the Projects tab, then select Makefile from the list.
Set/change the project name to Foo64, where Foo is the name of the 32-bit project.
Set the location to the same directory as your 32-bit project (You must change the default, which is a new Foo64 subdirectory). Do this in the EditText box, not by pressing the "... button" and not by using the file exploration dialog.
Leave the default of "Add to current Workspace".
Press OK and the new makefile wizard will present a dialog box with the default external command nmake /f "Foo64.mak".
Change the external command from nmake to BuildFoo64 Foo64.mak, which is shown later in this sidebar.
After your Foo64 project has been added, add the Foo64.mak file you exported from the 32-bit project to the project's list of files. Use <Project.Add To Project.Files...>.
Write a CMD file that builds your 64-bit project.
You need a CMD file that SETs the ENVIRONMENT and runs NMAKE on Foo64.mak. Create this as a new file and add it to your 64-bit project. Use <Project.Add To Project.New...Files ... Text File> as follows:
Leave "Add to Project" checked ON.
Verify that the current project is your 64-bit project.
Name the file Foo64.cmd.
Put the file in the project directory.
Here is a sample 64-bit build CMD file for NileApp64.dll from which you can cut and paste and then edit. (Note this sample uses BuildNileApp.cmd rather than BuildFoo64.cmd and assumes a \Projects\ project path.) Also note that this sample calls the provided SDK SetEnv.bat with the /pre64 switch to set the environment for a 64-bit build. The REM statements are left from debugging the CMD file.
echo BuildNileApp.cmd calling SetEnv.cmd /Pre64
CD "\Program Files\Microsoft Platform SDK\"
call SetEnv.bat /pre64
REM echo "The current directory is ..."
REM echo "The current path is ..."
nmake %1 %2 %3
Uncomment the REM statements to get a TRACE of your CMD file execution.