Merge pull request #1228 from mikeblome/mb-includes

Convert tokens to plain text

Author: Colin Robertson

docs/assembler/inline/inline-assembler.md

@@ -19,7 +19,7 @@ ms.workload: ["cplusplus"]
 > [!NOTE]
 >  Programs with inline assembler code are not fully portable to other hardware platforms. If you are designing for portability, avoid using inline assembler.  
   
- Inline assembly is not supported on the ARM and [!INCLUDE[vcprx64](../../assembler/inline/includes/vcprx64_md.md)] processors.  The following topics explain how to use the Visual C/C++ inline assembler with x86 processors:  
+ Inline assembly is not supported on the ARM and x64 processors.  The following topics explain how to use the Visual C/C++ inline assembler with x86 processors:  
 
 -   [Inline Assembler Overview](../../assembler/inline/inline-assembler-overview.md)  
 

docs/assembler/masm/microsoft-macro-assembler-reference.md

@@ -34,7 +34,7 @@ The Microsoft Macro Assembler (MASM) provides several advantages over inline ass
  Provides links to websites that may contain programming information about processors that are not manufactured, sold, or supported by Microsoft.  
 
  [MASM for x64 (ml64.exe)](../../assembler/masm/masm-for-x64-ml64-exe.md)  
- Information about how to create output files for [!INCLUDE[vcprx64](../../assembler/inline/includes/vcprx64_md.md)].  
+ Information about how to create output files for x64.  
 
 ## Related Sections  
  [Visual C++](../../visual-cpp-in-visual-studio.md)  

docs/atl/atl-com-property-pages.md

@@ -18,7 +18,7 @@ COM property pages provide a user interface for setting the properties (or calli
 
  Each property page can be built completely independently of the objects whose properties can be set. All that a property page needs is to understand a particular interface (or set of interfaces) and to provide a user interface for calling methods on that interface.  
 
- For more information, see [Property Sheets and Property Pages](http://msdn.microsoft.com/library/windows/desktop/ms686577) in the [!INCLUDE[winSDK](../atl/includes/winsdk_md.md)].  
+ For more information, see [Property Sheets and Property Pages](http://msdn.microsoft.com/library/windows/desktop/ms686577) in the Windows SDK.  
 
 ## In This Section  
  [Specifying Property Pages](../atl/specifying-property-pages.md)  

docs/atl/introduction-to-com-and-atl.md

@@ -23,7 +23,7 @@ This section provides a brief introduction to COM and ATL.
 
 ## Related Sections  
  [The Component Object Model](http://msdn.microsoft.com/library/windows/desktop/ms694363)  
- The [!INCLUDE[winSDK](../atl/includes/winsdk_md.md)] material on COM.  
+ The Windows SDK material on COM.  
 
  [ATL](../atl/active-template-library-atl-concepts.md)  
  Provides links to conceptual topics on how to program using the Active Template Library.  

docs/build/building-c-cpp-programs.md

@@ -14,7 +14,7 @@ ms.workload: ["cplusplus"]
 ---
 # Building C/C++ Programs
 
-You can build Visual C++ projects either in Visual Studio or on the command line. The Visual Studio IDE uses [MSBuild](../build/msbuild-visual-cpp.md) to build projects and solutions. On the command line, you can use the C/C++ compiler (cl.exe) and linker (link.exe) to build simple projects. To build more complex projects on the command line, you can use MSBuild or [NMAKE](../build/nmake-reference.md). For an overview about how to use [!INCLUDE[vsprvs](../assembler/masm/includes/vsprvs_md.md)] to build projects and solutions, see [Compiling and Building](/visualstudio/ide/compiling-and-building-in-visual-studio).  
+You can build Visual C++ projects either in Visual Studio or on the command line. The Visual Studio IDE uses [MSBuild](../build/msbuild-visual-cpp.md) to build projects and solutions. On the command line, you can use the C/C++ compiler (cl.exe) and linker (link.exe) to build simple projects. To build more complex projects on the command line, you can use MSBuild or [NMAKE](../build/nmake-reference.md). For an overview about how to use Visual Studio to build projects and solutions, see [Compiling and Building](/visualstudio/ide/compiling-and-building-in-visual-studio).  
 
 ## In This Section  
 

docs/build/configuring-programs-for-windows-xp.md

@@ -19,7 +19,7 @@ To get the platform toolset and components to target [!INCLUDE[winxp](../build/i
 
 ## Windows XP targeting experience
 
-The Windows XP platform toolset that's included in Visual Studio is a version of the [!INCLUDE[win7](../build/includes/win7_md.md)] SDK, but it uses the current C++ compiler. It also configures project properties to appropriate default values, for example, the specification of a compatible linker for down-level targeting. Only Windows desktop apps that are created by using a Windows XP platform toolset run on [!INCLUDE[winxp](../build/includes/winxp_md.md)] and [!INCLUDE[WinXPSvr](../build/includes/winxpsvr_md.md)], but those apps can also run on more recent Windows operating systems.
+The Windows XP platform toolset that's included in Visual Studio is a version of the Windows 7 SDK, but it uses the current C++ compiler. It also configures project properties to appropriate default values, for example, the specification of a compatible linker for down-level targeting. Only Windows desktop apps that are created by using a Windows XP platform toolset run on [!INCLUDE[winxp](../build/includes/winxp_md.md)] and [!INCLUDE[WinXPSvr](../build/includes/winxpsvr_md.md)], but those apps can also run on more recent Windows operating systems.
 
 #### To target Windows XP
 
@@ -59,7 +59,7 @@ Due to differences in platform and library support, the development experience f
 
 - **Static analysis**
 
-   The Windows XP platform toolsets don't support static analysis because the SAL annotations for the [!INCLUDE[win7](../build/includes/win7_md.md)] SDK and the runtime libraries are incompatible. When you want to perform static analysis on an app that supports [!INCLUDE[winxp](../build/includes/winxp_md.md)] or [!INCLUDE[WinXPSvr](../build/includes/winxpsvr_md.md)], you can temporarily switch the solution to target the default platform toolset to perform the analysis, and then switch back to the Windows XP platform toolset to build the app.
+   The Windows XP platform toolsets don't support static analysis because the SAL annotations for the Windows 7 SDK and the runtime libraries are incompatible. When you want to perform static analysis on an app that supports [!INCLUDE[winxp](../build/includes/winxp_md.md)] or [!INCLUDE[WinXPSvr](../build/includes/winxpsvr_md.md)], you can temporarily switch the solution to target the default platform toolset to perform the analysis, and then switch back to the Windows XP platform toolset to build the app.
 
 - **Debugging of DirectX graphics**
 

docs/build/dynamic-parameter-stack-area-construction.md

@@ -11,7 +11,7 @@ ms.author: "corob"
 ms.workload: ["cplusplus"]
 ---
 # Dynamic Parameter Stack Area Construction
-If a frame pointer is used, the option exists to dynamically create the parameter stack area. This is not currently done in the [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)] compiler.  
+If a frame pointer is used, the option exists to dynamically create the parameter stack area. This is not currently done in the x64 compiler.  
 
 ## See Also  
  [Stack Usage](../build/stack-usage.md)

docs/build/exception-handling-x64.md

@@ -12,7 +12,7 @@ ms.author: "corob"
 ms.workload: ["cplusplus"]
 ---
 # Exception Handling (x64)
-This section discusses structured exception handling and C++ exception handling behavior on the [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)].  
+This section discusses structured exception handling and C++ exception handling behavior on the x64.  
 
 -   [Unwind Data for Exception Handling, Debugger Support](../build/unwind-data-for-exception-handling-debugger-support.md)  
 

docs/build/how-to-embed-a-manifest-inside-a-c-cpp-application.md

@@ -12,7 +12,7 @@ ms.author: "corob"
 ms.workload: ["cplusplus"]
 ---
 # How to: Embed a Manifest Inside a C/C++ Application
-It is recommended that a C/C++ application (or library) have its manifest embedded inside the final binary because this guarantees correct runtime behavior in most scenarios. By default, [!INCLUDE[vsprvs](../assembler/masm/includes/vsprvs_md.md)] tries to embed the manifest when it builds a project from source files; see [Manifest Generation in Visual Studio](../build/manifest-generation-in-visual-studio.md) for more information. However if an application is built by using nmake, some changes to the existing makefile are necessary. This section demonstrates how to change existing makefiles to automatically embed the manifest inside the final binary.  
+It is recommended that a C/C++ application (or library) have its manifest embedded inside the final binary because this guarantees correct runtime behavior in most scenarios. By default, Visual Studio tries to embed the manifest when it builds a project from source files; see [Manifest Generation in Visual Studio](../build/manifest-generation-in-visual-studio.md) for more information. However if an application is built by using nmake, some changes to the existing makefile are necessary. This section demonstrates how to change existing makefiles to automatically embed the manifest inside the final binary.  
 
 ## Two approaches  
  There are two ways to embed the manifest inside an application or library.  

docs/build/how-to-modify-the-target-framework-and-platform-toolset.md

@@ -52,7 +52,7 @@ You can change Visual C++ project settings to target different versions of the .
 
 3.  In the left pane of the dialog box, expand **Configuration Properties** and then select **General**.  
 
-4.  In the right pane, select **Platform Toolset** and then select the toolset you want from the drop-down list. For example, if you have installed the [!INCLUDE[vs_dev10_long](../build/includes/vs_dev10_long_md.md)] toolset, select **Visual Studio 2010 (v100)** to use it for your project.  
+4.  In the right pane, select **Platform Toolset** and then select the toolset you want from the drop-down list. For example, if you have installed the Visual Studio 2010 toolset, select **Visual Studio 2010 (v100)** to use it for your project.  
 
 5.  Choose the **OK** button.  
 

docs/build/intrinsics-and-inline-assembly.md

@@ -11,7 +11,7 @@ ms.author: "corob"
 ms.workload: ["cplusplus"]
 ---
 # Intrinsics and Inline Assembly
-One of the constraints for the [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)] compiler is to have no inline assembler support. This means that functions that cannot be written in C or C++ will either have to be written as subroutines or as intrinsic functions supported by the compiler. Certain functions are performance sensitive while others are not. Performance-sensitive functions should be implemented as intrinsic functions.  
+One of the constraints for the x64 compiler is to have no inline assembler support. This means that functions that cannot be written in C or C++ will either have to be written as subroutines or as intrinsic functions supported by the compiler. Certain functions are performance sensitive while others are not. Performance-sensitive functions should be implemented as intrinsic functions.  
 
  The intrinsics supported by the compiler are described in [Compiler Intrinsics](../intrinsics/compiler-intrinsics.md).  
 

docs/build/nmake-reference.md

@@ -12,7 +12,7 @@ ms.author: "corob"
 ms.workload: ["cplusplus"]
 ---
 # NMAKE Reference
-The Microsoft Program Maintenance Utility (NMAKE.EXE) is a command-line tool included with [!INCLUDE[vsprvs](../assembler/masm/includes/vsprvs_md.md)] that builds projects based on commands that are contained in a description file.  
+The Microsoft Program Maintenance Utility (NMAKE.EXE) is a command-line tool included with Visual Studio that builds projects based on commands that are contained in a description file.  
 
  To use NMAKE, you must run it in a Developer Command Prompt window. A Developer Command Prompt window has the environment variables set for the tools, libraries, and include file paths required to build at the command line. For details on how to open a Developer Command Prompt window, see [Build C/C++ code on the command line](../build/building-on-the-command-line.md).  
 

docs/build/overview-of-x64-calling-conventions.md

@@ -11,14 +11,14 @@ ms.author: "corob"
 ms.workload: ["cplusplus"]
 ---
 # Overview of x64 Calling Conventions
-Two important differences between x86 and [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)] are the 64-bit addressing capability and a flat set of 16 64-bit registers for general use. Given the expanded register set, [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)] uses the [__fastcall](../cpp/fastcall.md) calling convention and a RISC-based exception-handling model. The `__fastcall` convention uses registers for the first four arguments and the stack frame to pass additional arguments.  
+Two important differences between x86 and x64 are the 64-bit addressing capability and a flat set of 16 64-bit registers for general use. Given the expanded register set, x64 uses the [__fastcall](../cpp/fastcall.md) calling convention and a RISC-based exception-handling model. The `__fastcall` convention uses registers for the first four arguments and the stack frame to pass additional arguments.  
 
- The following compiler option helps you optimize your application for [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)]:  
+ The following compiler option helps you optimize your application for x64:  
 
 -   [/favor (Optimize for Architecture Specifics)](../build/reference/favor-optimize-for-architecture-specifics.md)  
 
 ## Calling convention  
- The [!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)] Application Binary Interface (ABI) uses a four register fast-call calling convention by default. Space is allocated on the call stack as a shadow store for callees to save those registers. There is a strict one-to-one correspondence between the arguments to a function call and the registers used for those arguments. Any argument that doesn’t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference. There is no attempt to spread a single argument across multiple registers. The x87 register stack is unused. It may be used by the callee, but must be considered volatile across function calls. All floating point operations are done using the 16 XMM registers. Integer arguments are passed in registers RCX, RDX, R8, and R9. Floating point arguments are passed in XMM0L, XMM1L, XMM2L, and XMM3L. 16-byte arguments are passed by reference. Parameter passing is described in detail in [Parameter Passing](../build/parameter-passing.md). In addition to these registers, RAX, R10, R11, XMM4, and XMM5 are considered volatile. All other registers are non-volatile. Register usage is documented in detail in [Register Usage](../build/register-usage.md) and [Caller/Callee Saved Registers](../build/caller-callee-saved-registers.md).  
+ The x64 Application Binary Interface (ABI) uses a four register fast-call calling convention by default. Space is allocated on the call stack as a shadow store for callees to save those registers. There is a strict one-to-one correspondence between the arguments to a function call and the registers used for those arguments. Any argument that doesn’t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference. There is no attempt to spread a single argument across multiple registers. The x87 register stack is unused. It may be used by the callee, but must be considered volatile across function calls. All floating point operations are done using the 16 XMM registers. Integer arguments are passed in registers RCX, RDX, R8, and R9. Floating point arguments are passed in XMM0L, XMM1L, XMM2L, and XMM3L. 16-byte arguments are passed by reference. Parameter passing is described in detail in [Parameter Passing](../build/parameter-passing.md). In addition to these registers, RAX, R10, R11, XMM4, and XMM5 are considered volatile. All other registers are non-volatile. Register usage is documented in detail in [Register Usage](../build/register-usage.md) and [Caller/Callee Saved Registers](../build/caller-callee-saved-registers.md).  
 
  The caller is responsible for allocating space for parameters to the callee, and must always allocate sufficient space to store four register parameters, even if the callee doesn’t take that many parameters. This simplifies support for unprototyped C-language functions, and vararg C/C++ functions. For vararg or unprototyped functions, any floating point values must be duplicated in the corresponding general-purpose register. Any parameters beyond the first four must be stored on the stack, above the shadow store for the first four, prior to the call. Vararg function details can be found in [Varargs](../build/varargs.md). Unprototyped function information is detailed in [Unprototyped Functions](../build/unprototyped-functions.md).  
 

docs/build/predefined-rules.md

@@ -18,8 +18,8 @@ Predefined inference rules use NMAKE-supplied command and options macros.
 |----------|-------------|------------------------|--------------------|----------------------------|  
 |.asm.exe|$(AS) $(AFLAGS) $<|ml $<|no|x86|  
 |.asm.obj|$(AS) $(AFLAGS) /c $<|ml /c $<|yes|x86|  
-|.asm.exe|$(AS) $(AFLAGS) $<|ml64 $<|no|[!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)]|  
-|.asm.obj|$(AS) $(AFLAGS) /c $<|ml64 /c $<|yes|[!INCLUDE[vcprx64](../assembler/inline/includes/vcprx64_md.md)]|  
+|.asm.exe|$(AS) $(AFLAGS) $<|ml64 $<|no|x64|  
+|.asm.obj|$(AS) $(AFLAGS) /c $<|ml64 /c $<|yes|x64|  
 |.c.exe|$(CC) $(CFLAGS) $<|cl $<|no|all|  
 |.c.obj|$(CC) $(CFLAGS) /c $<|cl /c $<|yes|all|  
 |.cc.exe|$(CC) $(CFLAGS) $<|cl $<|no|all|  

docs/build/reference/compiler-options-listed-alphabetically.md

@@ -37,7 +37,7 @@ The following is a comprehensive alphabetical list of compiler options. For a ca
 |[/errorReport](errorreport-report-internal-compiler-errors.md)|Allows you to provide internal compiler error (ICE) information directly to the Visual C++ team.|
 |[/execution-charset](execution-charset-set-execution-character-set.md)|Set execution character set.|
 |[/F](f-set-stack-size.md)|Sets stack size.|
-|[/favor](favor-optimize-for-architecture-specifics.md)|Produces code that is optimized for a specific [!INCLUDE[vcprx64](../../assembler/inline/includes/vcprx64_md.md)] architecture or for the specifics of micro-architectures in both the AMD64 and Extended Memory 64 Technology (EM64T) architectures.|
+|[/favor](favor-optimize-for-architecture-specifics.md)|Produces code that is optimized for a specific x64 architecture or for the specifics of micro-architectures in both the AMD64 and Extended Memory 64 Technology (EM64T) architectures.|
 |[/FA](fa-fa-listing-file.md)|Creates a listing file.|
 |[/Fa](fa-fa-listing-file.md)|Sets the listing file name.|
 |[/FC](fc-full-path-of-source-code-file-in-diagnostics.md)|Display full path of source code files passed to cl.exe in diagnostic text.|
@@ -75,7 +75,7 @@ The following is a comprehensive alphabetical list of compiler options. For a ca
 |[/Gz](gd-gr-gv-gz-calling-convention.md)|Uses the `__stdcall` calling convention (x86 only).|
 |[/H](h-restrict-length-of-external-names.md)|Deprecated. Restricts the length of external (public) names.|
 |[/HELP](help-compiler-command-line-help.md)|Lists the compiler options.|
-|[/homeparams](homeparams-copy-register-parameters-to-stack.md)|Forces parameters passed in registers to be written to their locations on the stack upon function entry. This compiler option is only for the [!INCLUDE[vcprx64](../../assembler/inline/includes/vcprx64_md.md)] compilers (native and cross compile).|
+|[/homeparams](homeparams-copy-register-parameters-to-stack.md)|Forces parameters passed in registers to be written to their locations on the stack upon function entry. This compiler option is only for the x64 compilers (native and cross compile).|
 |[/hotpatch](hotpatch-create-hotpatchable-image.md)|Creates a hotpatchable image.|
 |[/I](i-additional-include-directories.md)|Searches a directory for include files.|
 |[/J](j-default-char-type-is-unsigned.md)|Changes the default `char` type.|