Fix curly quote gremlins

Author: Colin Robertson

docs/build/arm-exception-handling.md

@@ -9,7 +9,7 @@ Windows on ARM uses the same structured exception handling mechanism for asynchr
 
 ## ARM Exception Handling
 
-Windows on ARM uses *unwind codes* to control stack unwinding during [structured exception handling](/windows/win32/debug/structured-exception-handling) (SEH). Unwind codes are a sequence of bytes stored in the .xdata section of the executable image. They describe the operation of function prologue and epilogue code in an abstract way, so that the effects of a function’s prologue can be undone in preparation for unwinding to the caller’s stack frame.
+Windows on ARM uses *unwind codes* to control stack unwinding during [structured exception handling](/windows/win32/debug/structured-exception-handling) (SEH). Unwind codes are a sequence of bytes stored in the .xdata section of the executable image. They describe the operation of function prologue and epilogue code in an abstract way, so that the effects of a function's prologue can be undone in preparation for unwinding to the caller's stack frame.
 
 The ARM EABI (embedded application binary interface) specifies an exception unwinding model that uses unwind codes, but it's not sufficient for SEH unwinding in Windows, which must handle asynchronous cases where the processor is in the middle of the prologue or epilogue of a function. Windows also separates unwinding control into function-level unwinding and language-specific scope unwinding, which is unified in the ARM EABI. For these reasons, Windows on ARM specifies more details for the unwinding data and procedure.
 
@@ -19,7 +19,7 @@ Executable images for Windows on ARM use the Portable Executable (PE) format. Fo
 
 The exception handling mechanism makes certain assumptions about code that follows the ABI for Windows on ARM:
 
-- When an exception occurs within the body of a function, it does not matter whether the prologue’s operations are undone, or the epilogue’s operations are performed in a forward manner. Both should produce identical results.
+- When an exception occurs within the body of a function, it does not matter whether the prologue's operations are undone, or the epilogue's operations are performed in a forward manner. Both should produce identical results.
 
 - Prologues and epilogues tend to mirror each other. This can be used to reduce the size of the metadata needed to describe unwinding.
 
@@ -261,7 +261,7 @@ This shows the range of hexadecimal values for each byte in an unwind code *Code
 
 The unwind codes are designed so that the first byte of the code tells both the total size in bytes of the code and the size of the corresponding opcode in the instruction stream. To compute the size of the prologue or epilogue, walk the unwind codes from the start of the sequence to the end, and use a lookup table or similar method to determine how long the corresponding opcode is.
 
-Unwind codes 0xFD and 0xFE are equivalent to the regular end code 0xFF, but account for one extra nop opcode in the epilogue case, either 16-bit or 32-bit. For prologues, codes 0xFD, 0xFE and 0xFF are exactly equivalent. This accounts for the common epilogue endings `bx lr` or `b <tailcall-target>`, which don’t have an equivalent prologue instruction. This increases the chance that unwind sequences can be shared between the prologue and the epilogues.
+Unwind codes 0xFD and 0xFE are equivalent to the regular end code 0xFF, but account for one extra nop opcode in the epilogue case, either 16-bit or 32-bit. For prologues, codes 0xFD, 0xFE and 0xFF are exactly equivalent. This accounts for the common epilogue endings `bx lr` or `b <tailcall-target>`, which don't have an equivalent prologue instruction. This increases the chance that unwind sequences can be shared between the prologue and the epilogues.
 
 In many cases, it should be possible to use the same set of unwind codes for the prologue and all epilogues. However, to handle the unwinding of partially executed prologues and epilogues, you might have to have multiple unwind code sequences that vary in ordering or behavior. This is why each epilogue has its own index into the unwind array to show where to begin executing.
 
@@ -284,7 +284,7 @@ For example, consider this prologue and epilogue sequence:
 0148:   bx    lr
 ```
 
-Next to each opcode is the appropriate unwind code to describe this operation. The sequence of unwind codes for the prologue is a mirror image of the unwind codes for the epilogue, not counting the final instruction. This case is common, and is the reason the unwind codes for the prologue are always assumed to be stored in reverse order from the prologue’s execution order. This gives us a common set of unwind codes:
+Next to each opcode is the appropriate unwind code to describe this operation. The sequence of unwind codes for the prologue is a mirror image of the unwind codes for the epilogue, not counting the final instruction. This case is common, and is the reason the unwind codes for the prologue are always assumed to be stored in reverse order from the prologue's execution order. This gives us a common set of unwind codes:
 
 ```asm
 0xc7, 0xdd, 0x04, 0xfd
@@ -322,9 +322,9 @@ Assuming that the function prologue is at the beginning of the function and can'
 
 In the first case, only the prologue must be described. This can be done in compact .pdata form by describing the prologue normally and specifying a *Ret* value of 3 to indicate no epilogue. In the full .xdata form, this can be done by providing the prologue unwind codes at index 0 as usual, and specifying an epilogue count of 0.
 
-The second case is just like a normal function. If there’s only one epilogue in the fragment, and it is at the end of the fragment, then a compact .pdata record can be used. Otherwise, a full .xdata record must be used. Keep in mind that the offsets specified for the epilogue start are relative to the start of the fragment, not the original start of the function.
+The second case is just like a normal function. If there's only one epilogue in the fragment, and it is at the end of the fragment, then a compact .pdata record can be used. Otherwise, a full .xdata record must be used. Keep in mind that the offsets specified for the epilogue start are relative to the start of the fragment, not the original start of the function.
 
-The third and fourth cases are variants of the first and second cases, respectively, except they don’t contain a prologue. In these situations, it is assumed that there is code before the start of the epilogue and it is considered part of the body of the function, which would normally be unwound by undoing the effects of the prologue. These cases must therefore be encoded with a pseudo-prologue, which describes how to unwind from within the body, but which is treated as 0-length when determining whether to perform a partial unwind at the start of the fragment. Alternatively, this pseudo-prologue may be described by using the same unwind codes as the epilogue because they presumably perform equivalent operations.
+The third and fourth cases are variants of the first and second cases, respectively, except they don't contain a prologue. In these situations, it is assumed that there is code before the start of the epilogue and it is considered part of the body of the function, which would normally be unwound by undoing the effects of the prologue. These cases must therefore be encoded with a pseudo-prologue, which describes how to unwind from within the body, but which is treated as 0-length when determining whether to perform a partial unwind at the start of the fragment. Alternatively, this pseudo-prologue may be described by using the same unwind codes as the epilogue because they presumably perform equivalent operations.
 
 In the third and fourth cases, the presence of a pseudo-prologue is specified either by setting the *Flag* field of the compact .pdata record to 2, or by setting the *F* flag in the .xdata header to 1. In either case, the check for a partial prologue unwind is ignored, and all non-epilogue unwinds are considered to be full.
 
@@ -338,7 +338,7 @@ If a fragment has no prologue and no epilogue, it still requires its own .pdata
 
 #### Shrink-wrapping
 
-A more complex special case of function fragments is *shrink-wrapping*, a technique for deferring register saves from the start of the function to later in the function, to optimize for simple cases that don’t require register saving. This can be described as an outer region that allocates the stack space but saves a minimal set of registers, and an inner region that saves and restores additional registers.
+A more complex special case of function fragments is *shrink-wrapping*, a technique for deferring register saves from the start of the function to later in the function, to optimize for simple cases that don't require register saving. This can be described as an outer region that allocates the stack space but saves a minimal set of registers, and an inner region that saves and restores additional registers.
 
 ```asm
 ShrinkWrappedFunction
@@ -354,7 +354,7 @@ ShrinkWrappedFunction
     pop    {r4, pc}          ; C:
 ```
 
-Shrink-wrapped functions are typically expected to pre-allocate the space for the extra register saves in the regular prologue, and then perform the register saves by using `str` or `stm` instead of `push`. This keeps all stack-pointer manipulation in the function’s original prologue.
+Shrink-wrapped functions are typically expected to pre-allocate the space for the extra register saves in the regular prologue, and then perform the register saves by using `str` or `stm` instead of `push`. This keeps all stack-pointer manipulation in the function's original prologue.
 
 The example shrink-wrapped function must be broken into three regions, which are marked as A, B, and C in the comments. The first A region covers the start of the function through the end of the additional non-volatile saves. A .pdata or .xdata record must be constructed to describe this fragment as having a prologue and no epilogues.
 

docs/build/arm64-windows-abi-conventions.md

@@ -4,16 +4,16 @@ ms.date: "03/27/2019"
 ---
 # Overview of ARM64 ABI conventions
 
-The basic application binary interface (ABI) for Windows when compiled and run on ARM processors in 64-bit mode (ARMv8 or later architectures), for the most part, follows ARM’s standard AArch64 EABI. This article highlights some of the key assumptions and changes from what is documented in the EABI. For information about the 32-bit ABI, see [Overview of ARM ABI conventions](overview-of-arm-abi-conventions.md). For more information about the standard ARM EABI, see [Application Binary Interface (ABI) for the ARM Architecture](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html) (external link).
+The basic application binary interface (ABI) for Windows when compiled and run on ARM processors in 64-bit mode (ARMv8 or later architectures), for the most part, follows ARM's standard AArch64 EABI. This article highlights some of the key assumptions and changes from what is documented in the EABI. For information about the 32-bit ABI, see [Overview of ARM ABI conventions](overview-of-arm-abi-conventions.md). For more information about the standard ARM EABI, see [Application Binary Interface (ABI) for the ARM Architecture](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html) (external link).
 
 ## Definitions
 
 With the introduction of 64-bit support, ARM has defined several terms:
 
 - **AArch32** – the legacy 32-bit instruction set architecture (ISA) defined by ARM, including Thumb mode execution.
 - **AArch64** – the new 64-bit instruction set architecture (ISA) defined by ARM.
-- **ARMv7** – the specification of the “7th generation” ARM hardware, which only includes support for AArch32. This version of the ARM hardware is the first version Windows for ARM supported.
-- **ARMv8** – the specification of the “8th generation” ARM hardware, which includes support for both AArch32 and AArch64.
+- **ARMv7** – the specification of the "7th generation" ARM hardware, which only includes support for AArch32. This version of the ARM hardware is the first version Windows for ARM supported.
+- **ARMv8** – the specification of the "8th generation" ARM hardware, which includes support for both AArch32 and AArch64.
 
 Windows also uses these terms:
 
@@ -109,7 +109,7 @@ The floating-point control register (FPCR) has certain requirements on the vario
 
 ## System registers
 
-Like AArch32, the AArch64 specification provides three system-controlled “thread ID” registers:
+Like AArch32, the AArch64 specification provides three system-controlled "thread ID" registers:
 
 | Register | Role |
 | - | - |
@@ -157,7 +157,7 @@ For each argument in the list, the following rules are applied in turn until the
 
 1. If the argument is an HFA or an HVA, then the NSRN is set to 8, and the size of the argument is rounded up to the nearest multiple of 8 bytes.
 
-1. If the argument is an HFA, an HVA, a Quad-precision Floating-point or Short Vector Type, then the NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument’s type.
+1. If the argument is an HFA, an HVA, a Quad-precision Floating-point or Short Vector Type, then the NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument's type.
 
 1. If the argument is a Half- or Single-precision Floating Point type, then the size of the argument is set to 8 bytes. The effect is as if the argument had been copied to the least significant bits of a 64-bit register, and the remaining bits filled with unspecified values.
 
@@ -173,7 +173,7 @@ For each argument in the list, the following rules are applied in turn until the
 
 1. The NGRN is set to 8.
 
-1. The NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument’s type.
+1. The NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument's type.
 
 1. If the argument is a composite type, then the argument is copied to memory at the adjusted NSAA. The NSAA is incremented by the size of the argument. The argument has now been allocated.
 
@@ -219,7 +219,7 @@ All other types use this convention:
 
 Following the ABI put forth by ARM, the stack must remain 16-byte aligned at all times. AArch64 contains a hardware feature that generates stack alignment faults whenever the SP isn't 16-byte aligned and an SP-relative load or store is done. Windows runs with this feature enabled at all times.
 
-Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order. This action ensures no code can “leap over” the guard pages that Windows uses to expand the stack. Typically the touching is done by the `__chkstk` helper, which has a custom calling convention that passes the total stack allocation divided by 16 in x15.
+Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order. This action ensures no code can "leap over" the guard pages that Windows uses to expand the stack. Typically the touching is done by the `__chkstk` helper, which has a custom calling convention that passes the total stack allocation divided by 16 in x15.
 
 ## Red zone
 
@@ -235,7 +235,7 @@ Code within Windows is compiled with frame pointers enabled ([/Oy-](reference/oy
 
 ## Exception unwinding
 
-Unwinding during exception handling is assisted through the use of unwind codes. The unwind codes are a sequence of bytes stored in the .xdata section of the executable. They describe the operation of the prologue and epilogue in an abstract manner, such that the effects of a function’s prologue can be undone in preparation for backing up to the caller’s stack frame. For more information on the unwind codes, see [ARM64 exception handling](arm64-exception-handling.md).
+Unwinding during exception handling is assisted through the use of unwind codes. The unwind codes are a sequence of bytes stored in the .xdata section of the executable. They describe the operation of the prologue and epilogue in an abstract manner, such that the effects of a function's prologue can be undone in preparation for backing up to the caller's stack frame. For more information on the unwind codes, see [ARM64 exception handling](arm64-exception-handling.md).
 
 The ARM EABI also specifies an exception unwinding model that uses unwind codes. However, the specification as presented is insufficient for unwinding in Windows, which must handle cases where the PC is in the middle of a function prologue or epilogue.
 

docs/build/cmake-projects-in-visual-studio.md

@@ -185,7 +185,7 @@ If you need to pass arguments to an executable at debug time, you can use anothe
 
 ## Import an existing cache
 
-When you import an existing *CMakeCache.txt* file, Visual Studio automatically extracts customized variables and creates a pre-populated *CMakeSettings.json* file based on them. The original cache is not modified in any way and can still be used from the command line or with whatever tool or IDE was used to generate it. The new  *CMakeSettings.json* file is placed alongside the project’s root CMakeLists.txt. Visual Studio generates a new cache based the settings file. You can override automatic cache generation in the **Tools > Options > CMake > General** dialog.
+When you import an existing *CMakeCache.txt* file, Visual Studio automatically extracts customized variables and creates a pre-populated *CMakeSettings.json* file based on them. The original cache is not modified in any way and can still be used from the command line or with whatever tool or IDE was used to generate it. The new  *CMakeSettings.json* file is placed alongside the project's root CMakeLists.txt. Visual Studio generates a new cache based the settings file. You can override automatic cache generation in the **Tools > Options > CMake > General** dialog.
 
 Not everything in the cache is imported.  Properties such as the generator and the location of the compilers are replaced with defaults that are known to work well with the IDE.
 

docs/build/cmakesettings-reference.md

@@ -64,7 +64,7 @@ A `configuration` has these properties:
 
 Because Ninja is designed for fast build speeds instead of flexibility and function, it is set as the default. However, some CMake projects may be unable to correctly build using Ninja. If this occurs, you can instruct CMake to generate Visual Studio projects instead.
 
-To specify a Visual Studio generator in Visual Studio 2017, open the  from the main menu by choosing **CMake | Change CMake Settings**. Delete “Ninja” and type “V”. This activates IntelliSense, which enables you to choose the generator you want.
+To specify a Visual Studio generator in Visual Studio 2017, open the  from the main menu by choosing **CMake | Change CMake Settings**. Delete "Ninja" and type "V". This activates IntelliSense, which enables you to choose the generator you want.
 
 To specify a Visual Studio generator in Visual Studio 2019, right-click on the *CMakeLists.txt* file in **Solution Explorer** and choose **CMake Settings for project** > **Show Advanced Settings** > **CMake Generator**.
 
@@ -249,7 +249,7 @@ In the next example, the x86-Debug configuration defines its own value for the *
       "generator": "Ninja",
       "configurationType": "Debug",
       "inheritEnvironments": [ "msvc_x64" ],
-      // Since this configuration doesn’t modify BuildDir, it inherits
+      // Since this configuration doesn't modify BuildDir, it inherits
       // from the one defined globally.
       "buildRoot": "${env.BuildDir}\\${name}"
     }