10/13/2023 PM Publish

reference/5.1/Microsoft.PowerShell.Core/About/about_Functions_Advanced_Methods.md

@@ -1,7 +1,7 @@
 ---
 description: Describes how functions that specify the `CmdletBinding` attribute can use the methods and properties that are available to compiled cmdlets.
 Locale: en-US
-ms.date: 01/20/2023
+ms.date: 10/13/2023
 online version: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_functions_advanced_methods?view=powershell-5.1&WT.mc_id=ps-gethelp
 schema: 2.0.0
 title: about Functions Advanced Methods
@@ -39,12 +39,12 @@ For more information about the `CmdletBinding` attribute, see
 
 The methods described in this section are referred to as the input processing
 methods. For functions, these three methods are represented by the `begin`,
-`process`, and `end` blocks of the function. You aren't required to use any of
-these blocks in your functions.
+`process`, and `end` blocks of the function.
 
-> [!NOTE]
-> These blocks are also available to functions that don't use the
-> `CmdletBinding` attribute.
+You aren't required to use any of these blocks in your functions. If you don't
+use a named block, then PowerShell puts the code in the `end` block of the
+function. However, if you use any of these named blocks, or define a
+`dynamicparam` block, you must put all code in a named block.
 
 The following example shows the outline of a function that contains a `begin`
 block for one-time preprocessing, a `process` block for multiple record
@@ -62,9 +62,8 @@ Function Test-ScriptCmdlet
 ```
 
 > [!NOTE]
-> Using either a `begin` or `end` block requires that you define all three
-> blocks. When using any block, all PowerShell code must be inside one
-> of the blocks.
+> These blocks apply to all functions, not just functions that use the
+> `CmdletBinding` attribute.
 
 ### `begin`
 

reference/5.1/Microsoft.PowerShell.Core/About/about_WMI.md

@@ -21,15 +21,15 @@ Windows Management Instrumentation (WMI) is Microsoft's implementation of
 Web-Based Enterprise Management (WBEM), the industry standard.
 
 Classic WMI uses DCOM to communicate with networked devices to manage remote
-systems. Windows PowerShell 3.0 introduces a CIM provider model that uses
-WinRM to remove the dependency on DCOM. This CIM provider model also uses new
-WMI provider APIs that enable developers to write Windows PowerShell cmdlets
-in native code (C\+\+).
+systems. Windows PowerShell 3.0 introduces a CIM provider model that uses WinRM
+to remove the dependency on DCOM. This CIM provider model also uses new WMI
+provider APIs that enable developers to write Windows PowerShell cmdlets in
+native code (C++).
 
-Do not confuse WMI providers with Windows PowerShell providers. Many Windows
+Don't confuse WMI providers with Windows PowerShell providers. Many Windows
 features have an associated WMI provider that exposes their management
 capabilities. To get WMI providers, run a WMI query that gets instances of the
-__Provider WMI class, such as the following query.
+**__Provider** WMI class, such as the following query.
 
 ```powershell
 Get-WmiObject -Class __Provider
@@ -41,23 +41,23 @@ The following three components of WMI interact with Windows PowerShell:
 Namespaces, Providers, and Classes.
 
 WMI Namespaces organize WMI providers and WMI classes into groups of related
-components. In this way, they are similar to .NET Framework namespaces.
-Namespaces are not physical locations, but are more like logical databases.
-All WMI namespaces are instances of the __Namespace system class. The default
-WMI namespace is Root\/CIMV2 (since Microsoft Windows 2000). To use Windows
-PowerShell to get WMI namespaces in the current session, use a command with
-the following format.
+components. In this way, they're similar to .NET Framework namespaces.
+Namespaces aren't physical locations, but are more like logical databases. All
+WMI namespaces are instances of the __Namespace system class. The default WMI
+namespace is `root/cimv2` (since Microsoft Windows 2000). To use Windows
+PowerShell to get WMI namespaces in the current session, use a command with the
+following format.
 
 ```powershell
 Get-WmiObject -Class __Namespace
 ```
 
 To get WMI namespaces in other namespaces, use the Namespace parameter to
 change the location of the search. The following command finds WMI namespaces
-that reside in the Root/Cimv2/Applications namespace.
+that reside in the `root/cimv2/Applications` namespace.
 
 ```powershell
-Get-WmiObject -Class __Namespace -Namespace root/CIMv2/applications
+Get-WmiObject -Class __Namespace -Namespace root/cimv2/applications
 ```
 
 WMI namespaces are hierarchical. Therefore, obtaining a list of all namespaces
@@ -67,18 +67,17 @@ root namespace.
 WMI Providers expose information about Windows manageable objects. A provider
 retrieves data from a component, and passes that data through WMI to a
 management application, such as Windows PowerShell. Most WMI providers are
-dynamic providers, which means that they obtain the data dynamically when it
-is requested through the management application.
+dynamic providers, which means that they obtain the data dynamically when it's
+requested through the management application.
 
 ## FINDING WMI CLASSES
 
 In a default installation of Windows 8, there are more than 1,100 WMI classes
-in Root\/Cimv2. With this many WMI classes, the challenge becomes identifying
-the appropriate WMI class to use to perform a specific task. Windows
-PowerShell 3.0 provides two ways to find WMI classes that are related to a
-specific topic.
+in `root/cimv2`. With this many WMI classes, the challenge becomes identifying
+the appropriate WMI class to use to perform a specific task. Windows PowerShell
+3.0 provides two ways to find WMI classes that are related to a specific topic.
 
-For example,to find WMI classes in the root\\CIMV2 WMI namespace that are
+For example,to find WMI classes in the `root/cimv2` WMI namespace that are
 related to disks, you can use a query such as the one shown here.
 
 ```powershell
@@ -93,7 +92,7 @@ Get-WmiObject -List *memory*
 ```
 
 The CIM cmdlets also provide the ability to discover WMI classes. To do this,
-use the Get-CIMClass cmdlet. The command shown here lists WMI classes related
+use the `Get-CimClass` cmdlet. The command shown here lists WMI classes related
 to video.
 
 ```powershell
@@ -102,9 +101,9 @@ Get-CimClass *video*
 
 Tab expansion works when changing WMI namespaces, and therefore use of tab
 expansion makes sub-WMI namespaces easily discoverable. In the following
-example, the Get-CimClass cmdlet lists WMI classes related to power settings.
-To find it, type the `root/CIMV2/` namespace and then press the Tab key
-several times until the power namespace appears. Here is the command:
+example, the `Get-CimClass` cmdlet lists WMI classes related to power settings.
+To find it, type the `root/cimv2` namespace and then press the Tab key several
+times until the power namespace appears. Here is the command:
 
 ```powershell
 Get-CimClass *power* -Namespace root/cimv2/power