Merge pull request #5923 from MicrosoftDocs/main

5/21/2025 AM Publish

Author: Albertyang0

.github/copilot-instructions.md

@@ -0,0 +1,33 @@
+When writing documentation, follow the following guidelines:
+
+Follow the style of the [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/).
+
+Headings should be in sentence case, not title case. Don't use gerunds in titles.
+
+Use the active voice whenever possible, and second person to address the reader directly.
+
+Use a conversational tone with contractions.
+
+Be concise.
+
+Break up long sentences.
+
+Use the present tense for instructions and descriptions. For example, "The method returns a value" instead of "The method will return a value."
+
+Do not use "we" or "our" to refer to the authors of the documentation.
+
+Use the imperative mood for instructions. For example, "Call the method" instead of "You should call the method."
+
+Use "might" instead of "may" to indicate possibility. For example, "This method might throw an exception" instead of "This method may throw an exception."
+
+Use the Oxford comma in lists of three or more items.
+
+Number ordered list items all as "1." instead of "1.", "2.", etc. Use bullets for unordered lists.
+
+Use **bold** when referring to UI elements. Use `code style` for file names and folders, custom types, and other text that should never be localized.
+
+Put raw URLs within angle brackets.
+
+Include links to related topics and resources where appropriate. Use relative links if the target file lives in this repo. If you add a link to another page on learn.microsoft.com that's not in this repo, remove https://learn.microsoft.com/en-us from the link.
+
+If you're adding a new Markdown file, it should be named in all lowercase with hyphens separating words. Also, omit any filler words such as "the" or "a" from the file name.

.gitignore

@@ -7,7 +7,7 @@ _themes.MSDN.Modern/
 _themes.VS.Modern/
 
 # Ignore local configuration changes
-.github/
+#.github/
 .openpublishing.buildcore.ps1
 .vscode/
 

docs/assembler/inline/defining-asm-blocks-as-c-macros.md

@@ -1,9 +1,8 @@
 ---
-description: "Learn more about: Defining __asm Blocks as C Macros"
 title: "Defining __asm Blocks as C Macros"
-ms.date: "08/30/2018"
+description: "Learn more about: Defining __asm Blocks as C Macros"
+ms.date: 08/30/2018
 helpviewer_keywords: ["macros, __asm blocks", "Visual C, macros", "__asm keyword [C++], as C macros"]
-ms.assetid: 677ba11c-21c8-4609-bba7-cd47312243b0
 ---
 # Defining __asm Blocks as C Macros
 
@@ -15,7 +14,7 @@ C macros offer a convenient way to insert assembly code into your source code, b
 
 - Put the **`__asm`** keyword in front of each assembly instruction.
 
-- Use old-style C comments ( `/* comment */`) instead of assembly-style comments ( `; comment`) or single-line C comments ( `// comment`).
+- Use old-style C comments (`/* comment */`) instead of assembly-style comments (`; comment`) or single-line C comments (`// comment`).
 
 To illustrate, the following example defines a simple macro:
 
@@ -39,7 +38,7 @@ The third and fourth **`__asm`** keywords are needed as statement separators. Th
 
 The braces are essential as well. If you omit them, the compiler can be confused by C or C++ statements on the same line to the right of the macro invocation. Without the closing brace, the compiler cannot tell where assembly code stops, and it sees C or C++ statements after the **`__asm`** block as assembly instructions.
 
-Assembly-style comments that start with a semicolon (**;**) continue to the end of the line. This causes problems in macros because the compiler ignores everything after the comment, all the way to the end of the logical line. The same is true of single-line C or C++ comments ( `// comment`). To prevent errors, use old-style C comments ( `/* comment */`) in **`__asm`** blocks defined as macros.
+Assembly-style comments that start with a semicolon (**;**) continue to the end of the line. This causes problems in macros because the compiler ignores everything after the comment, all the way to the end of the logical line. The same is true of single-line C or C++ comments (`// comment`). To prevent errors, use old-style C comments (`/* comment */`) in **`__asm`** blocks defined as macros.
 
 An **`__asm`** block written as a C macro can take arguments. Unlike an ordinary C macro, however, an **`__asm`** macro cannot return a value. So you cannot use such macros in C or C++ expressions.
 

docs/atl-mfc-shared/reference/coledatetime-class.md

@@ -1,10 +1,9 @@
 ---
 title: "COleDateTime Class"
 description: "API reference for the MFC COleDateTime class which Encapsulates the `DATE` data type used in OLE automation."
-ms.date: "08/27/2020"
+ms.date: 08/27/2020
 f1_keywords: ["COleDateTime", "ATLCOMTIME/ATL::COleDateTime", "ATLCOMTIME/ATL::COleDateTime::COleDateTime", "ATLCOMTIME/ATL::COleDateTime::Format", "ATLCOMTIME/ATL::COleDateTime::GetAsDBTIMESTAMP", "ATLCOMTIME/ATL::COleDateTime::GetAsSystemTime", "ATLCOMTIME/ATL::COleDateTime::GetAsUDATE", "ATLCOMTIME/ATL::COleDateTime::GetCurrentTime", "ATLCOMTIME/ATL::COleDateTime::GetDay", "ATLCOMTIME/ATL::COleDateTime::GetDayOfWeek", "ATLCOMTIME/ATL::COleDateTime::GetDayOfYear", "ATLCOMTIME/ATL::COleDateTime::GetHour", "ATLCOMTIME/ATL::COleDateTime::GetMinute", "ATLCOMTIME/ATL::COleDateTime::GetMonth", "ATLCOMTIME/ATL::COleDateTime::GetSecond", "ATLCOMTIME/ATL::COleDateTime::GetStatus", "ATLCOMTIME/ATL::COleDateTime::GetYear", "ATLCOMTIME/ATL::COleDateTime::ParseDateTime", "ATLCOMTIME/ATL::COleDateTime::SetDate", "ATLCOMTIME/ATL::COleDateTime::SetDateTime", "ATLCOMTIME/ATL::COleDateTime::SetStatus", "ATLCOMTIME/ATL::COleDateTime::SetTime", "ATLCOMTIME/ATL::COleDateTime::m_dt", "ATLCOMTIME/ATL::COleDateTime::m_status"]
 helpviewer_keywords: ["shared classes, COleDateTime", "time-only values", "Date data type, MFC encapsulation of", "COleDateTime class", "dates, handling in MFC", "time, handling in MFC"]
-ms.assetid: e718f294-16ec-4649-88b6-a4dbae5178fb
 ---
 # COleDateTime Class
 
@@ -211,7 +210,7 @@ Following is a brief description of each constructor:
 
 - `COleDateTime(` `dateSrc` **)** Constructs a `COleDateTime` object from an existing `COleDateTime` object.
 
-- `COleDateTime(` *varSrc* **)** Constructs a `COleDateTime` object. Attempts to convert a `VARIANT` structure or [COleVariant](../../mfc/reference/colevariant-class.md) object to a date/time ( `VT_DATE`) value. If this conversion is successful, the converted value is copied into the new `COleDateTime` object. If it is not, the value of the `COleDateTime` object is set to 0 (midnight, 30 December 1899) and its status to invalid.
+- `COleDateTime(` *varSrc* **)** Constructs a `COleDateTime` object. Attempts to convert a `VARIANT` structure or [COleVariant](../../mfc/reference/colevariant-class.md) object to a date/time (`VT_DATE`) value. If this conversion is successful, the converted value is copied into the new `COleDateTime` object. If it is not, the value of the `COleDateTime` object is set to 0 (midnight, 30 December 1899) and its status to invalid.
 
 - `COleDateTime(` `dtSrc` **)** Constructs a `COleDateTime` object from a `DATE` value.
 
@@ -263,7 +262,7 @@ Indicates one of the following locale flags:
 Indicates locale ID to use for the conversion. For more information about language identifiers, see [Language Identifiers](/windows/win32/Intl/language-identifiers).
 
 *lpszFormat*<br/>
-A formatting string similar to the `printf` formatting string. Each formatting code, preceded by a percent ( `%`) sign, is replaced by the corresponding `COleDateTime` component. Other characters in the formatting string are copied unchanged to the returned string. For more information, see the run-time function [strftime](../../c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l.md). The value and meaning of the formatting codes for `Format` are:
+A formatting string similar to the `printf` formatting string. Each formatting code, preceded by a percent (`%`) sign, is replaced by the corresponding `COleDateTime` component. Other characters in the formatting string are copied unchanged to the returned string. For more information, see the run-time function [strftime](../../c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l.md). The value and meaning of the formatting codes for `Format` are:
 
 - `%H` Hours in the current day
 

docs/atl-mfc-shared/reference/cstringt-class.md

@@ -486,11 +486,11 @@ A handle for a **`CStringT`** object.
 
 Because the constructors copy the input data into new allocated storage, memory exceptions may result. Some of these constructors act as conversion functions. This allows you to substitute, for example, an **`LPTSTR`** where a **`CStringT`** object is expected.
 
-- **`CStringT`**( `LPCSTR` `lpsz` ): Constructs a Unicode **`CStringT`** from an ANSI string. You can also use this constructor to load a string resource as shown in the example below.
+- **`CStringT`**(`LPCSTR` `lpsz`): Constructs a Unicode **`CStringT`** from an ANSI string. You can also use this constructor to load a string resource as shown in the example below.
 
-- `CStringT(` `LPCWSTR` `lpsz` ): Constructs a **`CStringT`** from a Unicode string.
+- **`CStringT`**(`LPCWSTR` `lpsz`): Constructs a **`CStringT`** from a Unicode string.
 
-- **`CStringT`**( `const unsigned char*` `psz` ): Allows you to construct a **`CStringT`** from a pointer to **`unsigned char`**.
+- **`CStringT`**(`const unsigned char*` `psz`): Allows you to construct a **`CStringT`** from a pointer to **`unsigned char`**.
 
 > [!NOTE]
 > Define the `_CSTRING_DISABLE_NARROW_WIDE_CONVERSION` macro to turn off implicit string conversion between ANSI and Unicode strings. The macro excludes from compilation constructors that support conversion.

docs/build/reference/gd-gr-gv-gz-calling-convention.md

@@ -1,10 +1,9 @@
 ---
-description: "Learn more about: /Gd, /Gr, /Gv, /Gz (Calling Convention)"
 title: "/Gd, /Gr, /Gv, /Gz (Calling Convention)"
-ms.date: "09/05/2018"
+description: "Learn more about: /Gd, /Gr, /Gv, /Gz (Calling Convention)"
+ms.date: 09/05/2018
 f1_keywords: ["/Gr", "/Gv", "/Gd", "VC.Project.VCCLCompilerTool.CallingConvention"]
 helpviewer_keywords: ["-Gd compiler option [C++]", "-Gv compiler option [C++]", "/Gv compiler option [C++]", "-Gr compiler option [C++]", "Gd compiler option [C++]", "Gr compiler option [C++]", "/Gz compiler option [C++]", "-Gz compiler option [C++]", "/Gd compiler option [C++]", "Gz compiler option [C++]", "Gv compiler option [C++]", "/Gr compiler option [C++]"]
-ms.assetid: fd3110cb-2d77-49f2-99cf-a03f9ead00a3
 ---
 # /Gd, /Gr, /Gv, /Gz (Calling Convention)
 
@@ -44,7 +43,7 @@ For more information about calling conventions, see [Calling Conventions](../../
 
 On x86 processors, all function arguments are passed on the stack from right to left. On ARM and x64 architectures, some arguments are passed by register and the rest are passed on the stack from right to left. The calling routine pops the arguments from the stack.
 
-For C, the **`__cdecl`** naming convention uses the function name preceded by an underscore ( `_` ); no case translation is performed. Unless declared as `extern "C"`, C++ functions use a different name-decorating scheme. For more information, see [Decorated Names](decorated-names.md).
+For C, the **`__cdecl`** naming convention uses the function name preceded by an underscore (`_`); no case translation is performed. Unless declared as `extern "C"`, C++ functions use a different name-decorating scheme. For more information, see [Decorated Names](decorated-names.md).
 
 ## __fastcall Specifics
 

docs/c-runtime-library/reference/fopen-wfopen.md

@@ -1,6 +1,6 @@
 ---
-description: "Learn more about: fopen, _wfopen"
 title: "fopen, _wfopen"
+description: "Learn more about: fopen, _wfopen"
 ms.date: 04/27/2023
 api_name: ["_wfopen", "fopen", "_o__wfopen", "_o_fopen"]
 api_location: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-stdio-l1-1-0.dll"]
@@ -136,7 +136,7 @@ Valid characters for the *`mode`* string that is used in **`fopen`** and **`_fdo
 | Characters in *`mode`* string | Equivalent *`oflag`* value for `_open`/`_sopen` |
 |--|--|
 | **`a`** | `_O_WRONLY | _O_APPEND` (usually `_O_WRONLY | _O_CREAT | _O_APPEND`) |
-| **`a+`** | `_O_RDWR | _O_APPEND` (usually `_O_RDWR | _O_APPEND | _O_CREAT` ) |
+| **`a+`** | `_O_RDWR | _O_APPEND` (usually `_O_RDWR | _O_APPEND | _O_CREAT`) |
 | **`r`** | `_O_RDONLY` |
 | **`r+`** | `_O_RDWR` |
 | **`w`** | `_O_WRONLY` (usually `_O_WRONLY | _O_CREAT | _O_TRUNC`) |

docs/c-runtime-library/reference/malloca.md

@@ -1,7 +1,7 @@
 ---
-description: "Learn more about: _malloca"
 title: "_malloca"
-ms.date: "11/04/2016"
+description: "Learn more about: _malloca"
+ms.date: 11/04/2016
 api_name: ["_malloca"]
 api_location: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll"]
 api_type: ["DLLExport"]
@@ -38,7 +38,7 @@ If *`size`* is greater than `_ALLOCA_S_THRESHOLD`, then **`_malloca`** attempts
 
 There are restrictions to explicitly calling **`_malloca`** in an exception handler (EH). EH routines that run on x86-class processors operate in their own memory frame: They perform their tasks in memory space that isn't based on the current location of the stack pointer of the enclosing function. The most common implementations include Windows NT structured exception handling (SEH) and C++ catch clause expressions. Therefore, explicitly calling **`_malloca`** in any of the following scenarios results in program failure during the return to the calling EH routine:
 
-- Windows SEH exception filter expression: **`__except`** (`_malloca ()` )
+- Windows SEH exception filter expression: **`__except`** (`_malloca ()`)
 
 - Windows SEH final exception handler: **`__finally`** {`_malloca ()` }
 

docs/c-runtime-library/reference/splitpath-wsplitpath.md

@@ -1,6 +1,6 @@
 ---
-description: "Learn more about: _splitpath, _wsplitpath"
 title: "_splitpath, _wsplitpath"
+description: "Learn more about: _splitpath, _wsplitpath"
 ms.date: 11/30/2023
 api_name: ["_wsplitpath", "_splitpath", "_o__splitpath", "_o__wsplitpath"]
 api_location: ["msvcrt.dll", "msvcr80.dll", "msvcr90.dll", "msvcr100.dll", "msvcr100_clr0400.dll", "msvcr110.dll", "msvcr110_clr0400.dll", "msvcr120.dll", "msvcr120_clr0400.dll", "ucrtbase.dll", "api-ms-win-crt-filesystem-l1-1-0.dll"]
@@ -41,7 +41,7 @@ Full path.
 Drive letter, followed by a colon (**:**). You can pass `NULL` for this parameter if you don't need the drive letter.
 
 *`dir`*\
-Directory path, including trailing slash. Forward slashes ( `/` ), backslashes ( `\` ), or both may be used. Pass `NULL` for this parameter if you don't need the directory path.
+Directory path, including trailing slash. Forward slashes (`/`), backslashes (`\`), or both may be used. Pass `NULL` for this parameter if you don't need the directory path.
 
 *`fname`*\
 Base filename (no extension). Pass `NULL` for this parameter if you don't need the filename.

docs/error-messages/compiler-errors-1/compiler-error-c2095.md

@@ -1,15 +1,14 @@
 ---
-description: "Learn more about: Compiler Error C2095"
 title: "Compiler Error C2095"
-ms.date: "11/04/2016"
+description: "Learn more about: Compiler Error C2095"
+ms.date: 11/04/2016
 f1_keywords: ["C2095"]
 helpviewer_keywords: ["C2095"]
-ms.assetid: 44f8ada1-974f-4e81-a408-33ac6695aa53
 ---
 # Compiler Error C2095
 
 'function' : actual parameter has type 'void' : parameter 'number'
 
-The parameter passed to the function is type **`void`**, which is not allowed. Use a pointer to void ( `void *`) instead.
+The parameter passed to the function is type **`void`**, which is not allowed. Use a pointer to void (`void *`) instead.
 
 The `number` indicates which parameter is **`void`**.