Most real-world programs use some kind of *build system* to manage complexities of compiling multiple source files for multiple configurations (i.e. debug vs. release), multiple platforms (x86, x64, ARM, and so on), custom build steps, and even multiple executables that must be compiled in a certain order. You make settings in a build configuration file(s), and the build system accepts that file as input before it invoke the compiler. The set of source code files and build configuration files needed to build an executable file is called a *project*.

- create a Visual Studio project by using the Visual Studio IDE and configure it by using property pages. Visual Studio projects produce programs that run on Windows. For an overview, see [Compiling and Building](/visualstudio/ide/compiling-and-building-in-visual-studio) in the Visual Studio documentation.

[Building C/C++ Isolated Applications and Side-by-side Assemblies](building-c-cpp-isolated-applications-and-side-by-side-assemblies.md)

Describes the deployment model for Windows Desktop applications, based on the idea of isolated applications and side-by-side assemblies.

How to target 64-bit x64 hardware with the MSVC build tools.

[Configure Visual C++ for ARM processors](configuring-programs-for-arm-processors-visual-cpp.md)

An even faster way to open a developer command prompt window is to enter *developer command prompt* in the desktop search box, then choose the desired result.

If you prefer to set the build architecture environment in an existing command prompt window, you can use one of the command files (batch files) created by the installer to set the required environment. We only recommend you do this in a new command prompt window, and we do not recommend you later switch environments in the same command window. The location of these files depends on the version of Visual Studio you have installed, and on location and naming choices you made during installation. For Visual Studio 2017, the typical installation location on a 64-bit computer is in \Program Files (x86)\Microsoft Visual Studio\2017\\*edition*, where *edition* may be Community, Professional, Enterprise, BuildTools, or another name you supplied. For Visual Studio 2015, the typical installation location is in \Program Files (x86)\Microsoft Visual Studio 14.0.

- [Exporting C++ functions for use in C-language executables](exporting-cpp-functions-for-use-in-c-language-executables.md)

- [Decorated names](reference/decorated-names.md)

ms.date: "10/18/2018"

ms.assetid: 444d50df-215e-4d31-933a-b41841f186f8

This article assumes that you are familiar with CMake, a cross-platform, open-source tool for defining build processes that run on multiple platforms.

[Visual C++ Porting and Upgrading Guide](../porting/visual-cpp-porting-and-upgrading-guide.md)

ms.date: "11/04/2016"

helpviewer_keywords: ["64-bit compiler [C++], options", "64-bit compiler [C++]", "64-bit programming [C++], about 64-bit programming", "programming [C++], 64-bit", "Visual C++, 64-bit hardware"]

ms.assetid: cb99f72b-8c74-48f4-846a-8921b37b97e9

This section contains topics about targeting 64-bit x64 hardware with the Visual C++ build tools.

How to use Property Pages and Property Sheets to specify your project settings.

[Reference libraries and components at build time](adding-references-in-visual-cpp-projects.md)<br/>

When you create a new project in Visual Studio, a *precompiled header file* named "pch.h" is added to the project. (In earlier versions of Visual Studio, the file was called "stdafx.h".) The purpose of the file is to speed up the build process. Any stable header files, for example Standard Library headers such as `<vector>`, should be included here. The precompiled header is compiled only when it, or any files it includes, are modified. If you only make changes in your project source code, the build will skip compilation for the precompiled header.

Precompile code when you know that your source files use common sets of header files but don't include them in the same order, or when you want to include source code in your precompilation.

The compiler option reference topics for **/Yu** and **/Yc** discuss how to access this functionality in the development environment.

When you use a PCH file, the compiler assumes the same compilation environment — one that uses consistent compiler options, pragmas, and so on — that was in effect when you created the PCH file, unless you specify otherwise. If the compiler detects an inconsistency, it issues a warning and identifies the inconsistency where possible. Such warnings do not necessarily indicate a problem with the PCH file; they simply warn you of possible conflicts. Consistency requirements for PCH files are described in the following sections.

For another approach to using the manual precompiled-header options in a project, study one of the makefiles located in the MFC\SRC directory that is created during the default setup of Visual C++. These makefiles take a similar approach to the one presented in this section but make greater use of Microsoft Program Maintenance Utility (NMAKE) macros, and offer greater control of the build process.

only if the precompiled header file (STABLE.pch) does not exist or if you make changes to the files listed in the two macros. In either case, the precompiled header file will contain code only from the files listed in the STABLEHDRS macro. List the last file you want precompiled in the BOUNDRY macro.

Continuing down the diagram, APPLIB.obj represents the support code used in your final application. It is created from APPLIB.cpp, the files listed in the UNSTABLEHDRS macro, and precompiled code from the precompiled header.