Merge pull request #1472 from MicrosoftDocs/master

10/12 AM Publish

Author: Taojunshen

docs/assembler/inline/asm.md

@@ -1,10 +1,10 @@
 ---
 title: "__asm | Microsoft Docs"
 ms.custom: ""
-ms.date: "08/30/2018"
+ms.date: "10/09/2018"
 ms.technology: ["cpp-masm"]
 ms.topic: "conceptual"
-f1_keywords: ["__asm", "__asm_cpp"]
+f1_keywords: ["__asm", "_asm", "__asm_cpp"]
 dev_langs: ["C++"]
 helpviewer_keywords: ["__asm keyword [C++], vs. asm blocks", "__asm keyword [C++]"]
 ms.assetid: 77ff3bc9-a492-4b5e-85e1-fa4e414e79cd
@@ -47,6 +47,8 @@ did not cause native code to be generated when compiled with **/clr**; the compi
 
 `__asm int 3` now results in native code generation for the function. If you want a function to cause a break point in your code and if you want that function compiled to MSIL, use [__debugbreak](../../intrinsics/debugbreak.md).
 
+For compatibility with previous versions, **_asm** is a synonym for **__asm** unless compiler option [/Za \(Disable language extensions)](../../build/reference/za-ze-disable-language-extensions.md) is specified.
+
 ## Example
 
 The following code fragment is a simple `__asm` block enclosed in braces:

docs/build/calling-dll-functions-from-visual-basic-applications.md

@@ -17,7 +17,7 @@ For Visual Basic applications (or applications in other languages such as Pascal
 
 `__stdcall` creates the correct calling convention for the function (the called function cleans up the stack and parameters are passed from right to left) but decorates the function name differently. So, when **__declspec(dllexport)** is used on an exported function in a DLL, the decorated name is exported.
 
-The `__stdcall` name decoration prefixes the symbol name with an underscore (_) and appends the symbol with an at sign (**\@**) character followed by the number of bytes in the argument list (the required stack space). As a result, the function when declared as:
+The `__stdcall` name decoration prefixes the symbol name with an underscore ( **\_** ) and appends the symbol with an at sign (**\@**) character followed by the number of bytes in the argument list (the required stack space). As a result, the function when declared as:
 
 ```C
 int __stdcall func (int a, double b)
@@ -29,7 +29,7 @@ The C calling convention (`__cdecl`) decorates the name as `_func`.
 
 To get the decorated name, use [/MAP](../build/reference/map-generate-mapfile.md). Use of **__declspec(dllexport)** does the following:
 
-- If the function is exported with the C calling convention (**_cdecl**), it strips the leading underscore (_) when the name is exported.
+- If the function is exported with the C calling convention (`__cdecl`), it strips the leading underscore ( **\_** ) when the name is exported.
 
 - If the function being exported does not use the C calling convention (for example, `__stdcall`), it exports the decorated name.
 

docs/build/how-to-use-build-events-in-msbuild-projects.md

@@ -18,7 +18,7 @@ A build event is a command that MSBuild performs at a particular stage in the bu
 
 Each of the three build events is represented in an item definition group by a command element (`<Command>`) that is executed and a message element (`<Message>`) that is displayed when **MSBuild** performs the build event. Each element is optional, and if you specify the same element multiple times, the last occurrence takes precedence.
 
-An optional *use-in-build* element (`<`*build-event*`UseInBuild>`) can be specified in a property group to indicate whether the build event is executed. The value of the content of a *use-in-build* element is either `true` or `false`. By default, a build event is executed unless its corresponding *use-in-build* element is set to `false`.
+An optional *use-in-build* element (`<`*build-event*`UseInBuild>`) can be specified in a property group to indicate whether the build event is executed. The value of the content of a *use-in-build* element is either **true** or **false**. By default, a build event is executed unless its corresponding *use-in-build* element is set to `false`.
 
 The following table lists each build event XML element:
 

docs/build/msbuild-visual-cpp-overview.md

@@ -106,7 +106,7 @@ For example, set the `PreferredToolArchitecture` property to `x64` to use the 64
 
 ### UseEnv Property
 
-By default, the platform-specific settings for the current project override the PATH, INCLUDE, LIB, LIBPATH, CONFIGURATION, and PLATFORM environment variables. Set the `UseEnv` property to `true` to guarantee that the environment variables are not overridden.
+By default, the platform-specific settings for the current project override the PATH, INCLUDE, LIB, LIBPATH, CONFIGURATION, and PLATFORM environment variables. Set the `UseEnv` property to **true** to guarantee that the environment variables are not overridden.
 
 `msbuild myProject.vcxproj /p:UseEnv=true`
 

docs/build/reference/gh-enable-penter-hook-function.md

@@ -29,7 +29,7 @@ The `_penter` function is not part of any library and it is up to you to provide
 Unless you plan to explicitly call `_penter`, you do not need to provide a prototype. The function must appear as if it had the following prototype, and it must push the content of all registers on entry and pop the unchanged content on exit:
 
 ```
-void __declspec(naked) _cdecl _penter( void );
+void __declspec(naked) __cdecl _penter( void );
 ```
 
 This declaration is not available for 64-bit projects.
@@ -52,7 +52,7 @@ This declaration is not available for 64-bit projects.
 
 The following code, when compiled with **/Gh**, shows how `_penter` is called twice; once when entering function `main` and once when entering function `x`.
 
-```
+```cpp
 // Gh_compiler_option.cpp
 // compile with: /Gh
 // processor: x86
@@ -63,7 +63,7 @@ int main() {
    x();
 }
 
-extern "C" void __declspec(naked) _cdecl _penter( void ) {
+extern "C" void __declspec(naked) __cdecl _penter( void ) {
    _asm {
       push eax
       push ebx

docs/build/reference/gh-enable-pexit-hook-function.md

@@ -29,7 +29,7 @@ The `_pexit` function is not part of any library and it is up to you to provide
 Unless you plan to explicitly call `_pexit`, you do not need to provide a prototype. The function must appear as if it had the following prototype, and it must push the content of all registers on entry and pop the unchanged content on exit:
 
 ```
-void __declspec(naked) _cdecl _pexit( void );
+void __declspec(naked) __cdecl _pexit( void );
 ```
 
 `_pexit` is similar to `_penter`; see [/Gh (Enable _penter Hook Function)](../../build/reference/gh-enable-penter-hook-function.md) for an example of how to write a `_pexit` function.

docs/build/reference/manifestuac-embeds-uac-information-in-manifest.md

@@ -35,7 +35,7 @@ A string that contains the `level` and `uiAccess` values. For more information,
 One of *asInvoker*, *highestAvailable*, or *requireAdministrator*. Defaults to asInvoker. For more information, see the Remarks section later in this topic.
 
 *_uiAccess*<br/>
-`true` if you want the application to bypass user interface protection levels and drive input to higher-permission windows on the desktop; otherwise, `false`. Defaults to `false`. Set to `true` only for user interface accessibility applications.
+**true** if you want the application to bypass user interface protection levels and drive input to higher-permission windows on the desktop; otherwise, **false**. Defaults to **false**. Set to **true** only for user interface accessibility applications.
 
 ## Remarks
 

docs/build/reference/optimization-pragmas-and-keywords.md

@@ -19,7 +19,7 @@ Several keywords and pragmas that you use in your C or C++ code affect optimizat
 
 - [__assume](../../intrinsics/assume.md)
 
-- [inline, _inline, or \__forceinline](../../cpp/inline-functions-cpp.md)
+- [inline, __inline, or \__forceinline](../../cpp/inline-functions-cpp.md)
 
 - [#pragma auto_inline](../../preprocessor/auto-inline.md)
 

docs/build/reference/winmd-generate-windows-metadata.md

@@ -15,11 +15,9 @@ ms.workload: ["cplusplus"]
 
 Enables generation of a Windows Runtime Metadata (.winmd) file.
 
-```
-/WINMD[:{NO|ONLY}]
-```
+> **/WINMD**\[**:**{**NO**\|**ONLY**}]
 
-## Remarks
+## Arguments
 
 **/WINMD**<br/>
 The default setting for Universal Windows Platform apps. The linker generates both the binary executable file and the .winmd metadata file.
@@ -30,19 +28,27 @@ The linker generates only the binary executable file, but not a .winmd file.
 **/WINMD:ONLY**<br/>
 The linker generates only the .winmd file, but not the binary executable file.
 
-By default, the output file name has the form `binaryname`.winmd. To specify a different file name, use the [/WINMDFILE](../../build/reference/winmdfile-specify-winmd-file.md) option.
+## Remarks
+
+The **/WINMD** linker option is used for UWP apps and Windows runtime components to control the creation of a Windows Runtime metadata (.winmd) file. A .winmd file is a kind of DLL that contains metadata for Windows runtime types and, in the case of runtime components, the implementations of those types. The metadata follows the [ECMA-335](http://www.ecma-international.org/publications/standards/Ecma-335.htm) standard.
+
+By default, the output file name has the form *binaryname*.winmd. To specify a different file name, use the [/WINMDFILE](../../build/reference/winmdfile-specify-winmd-file.md) option.
 
 ### To set this linker option in the Visual Studio development environment
 
 1. Open the project's **Property Pages** dialog box. For details, see [Working with Project Properties](../../ide/working-with-project-properties.md).
 
-1. Select the **Linker** folder.
-
-1. Select the **Windows Metadata** property page.
+1. Select the **Configuration Properties** > **Linker** > **Windows Metadata** property page.
 
 1. In the **Generate Windows Metadata** drop-down list box, select the option you want.
 
 ## See Also
 
+[Walkthrough: Creating a Simple Windows Runtime component and calling it from JavaScript](/windows/uwp/winrt-components/walkthrough-creating-a-simple-windows-runtime-component-and-calling-it-from-javascript)<br/>
+[Introduction to Microsoft Interface Definition Language 3.0](/uwp/midl-3/intro)<br/>
+[/WINMDFILE (Specify winmd File)](winmdfile-specify-winmd-file.md)<br/>
+[/WINMDKEYFILE (Specify winmd Key File)](winmdkeyfile-specify-winmd-key-file.md)<br/>
+[/WINMDKEYCONTAINER (Specify Key Container)](winmdkeycontainer-specify-key-container.md)<br/>
+[/WINMDDELAYSIGN (Partially Sign a winmd)](winmddelaysign-partially-sign-a-winmd.md)<br/>
 [Setting Linker Options](../../build/reference/setting-linker-options.md)<br/>
-[Linker Options](../../build/reference/linker-options.md)
+[Linker Options](../../build/reference/linker-options.md)

docs/c-language/c-keywords.md

@@ -1,7 +1,7 @@
 ---
 title: "C Keywords | Microsoft Docs"
 ms.custom: ""
-ms.date: "11/04/2016"
+ms.date: "10/09/2018"
 ms.technology: ["cpp-language"]
 ms.topic: "language-reference"
 dev_langs: ["C++"]
@@ -36,17 +36,19 @@ The following keywords and special identifiers are recognized by the Microsoft C
 
 |||||
 |-|-|-|-|
-|**__asm**|**dllimport**<sup>2</sup>|**__int8**|**naked**<sup>2</sup>|
-|**__based**<sup>1</sup>|**__except**|**__int16**|**__stdcall**|
-|**__cdecl**|**__fastcall**|**__int32**|**thread**<sup>2</sup>|
-|**__declspec**|**__finally**|**__int64**|**__try**|
-|**dllexport**<sup>2</sup>|**__inline**|**__leave**||
+|**__asm**<sup>3</sup>|**dllimport**<sup>2</sup>|**__int8**<sup>3</sup>|**naked**<sup>2</sup>|
+|**__based**<sup>1, 3</sup>|**__except**<sup>3</sup>|**__int16**<sup>3</sup>|**__stdcall**<sup>3</sup>|
+|**__cdecl**<sup>3</sup>|**__fastcall**|**__int32**<sup>3</sup>|**thread**<sup>2</sup>|
+|**__declspec**<sup>3</sup>|**__finally**<sup>3</sup>|**__int64**<sup>3</sup>|**__try**<sup>3</sup>|
+|**dllexport**<sup>2</sup>|**__inline**<sup>3</sup>|**__leave**<sup>3</sup>||
 
 <sup>1</sup> The **__based** keyword has limited uses for 32-bit and 64-bit target compilations.
 
 <sup>2</sup> These are special identifiers when used with **__declspec**; their use in other contexts is not restricted.
 
-Microsoft extensions are enabled by default. To ensure that your programs are fully portable, you can disable Microsoft extensions by specifying the /Za option (compile for ANSI compatibility) during compilation. When you do this, Microsoft-specific keywords are disabled.
+<sup>3</sup> For compatibility with previous versions, these keywords are available both with two leading underscores and a single leading underscore when Microsoft extensions are enabled.
+
+Microsoft extensions are enabled by default. To ensure that your programs are fully portable, you can disable Microsoft extensions by specifying the [/Za \(Disable language extensions)](../build/reference/za-ze-disable-language-extensions.md) option during compilation. When you do this, some Microsoft-specific keywords are disabled.
 
 When Microsoft extensions are enabled, you can use the keywords listed above in your programs. For ANSI compliance, most of these keywords are prefaced by a double underscore. The four exceptions, **dllexport**, **dllimport**, **naked**, and **thread**, are used only with **__declspec** and therefore do not require a leading double underscore. For backward compatibility, single-underscore versions of the rest of the keywords are supported.