PowerShell / Basic: editions, objects, types, and functions / Lesson 1

Choose an edition and discover command contracts

Separate PowerShell 7, Windows PowerShell 5.1, command resolution, help, platform support, and actual execution evidence.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain the cross-platform and Windows-specific edition boundaries.
Distinguish cmdlets, functions, aliases, and native applications.
Read parameter and help contracts before executing commands.

The product name does not identify one runtime

PowerShell 7 is a cross-platform language and automation environment built on modern .NET, while Windows PowerShell 5.1 belongs to the Windows/.NET Framework line. They can differ in available modules, APIs, encodings, native-command handling, and remoting behavior. This course uses the officially documented PowerShell 7.6 LTS family as its conceptual baseline and calls out 5.1 limitations. A script written on Windows is not automatically portable to Linux merely because both have PowerShell. Record edition, version, operating system, module versions, and required .NET capabilities before claiming compatibility or diagnosing a missing command.

A command name can resolve to different implementations

A name can resolve to an alias, function, cmdlet, or native executable according to the session’s discovery rules. Cmdlets commonly use Verb-Noun names and expose structured parameters; native applications retain their own argument and exit-code conventions. An alias convenient in a personal console can obscure an automation dependency or behave differently on another platform. Prefer full meaningful command names in maintained scripts and inspect the resolved command and parameter sets when uncertain. Do not assume a familiar name has the same behavior as a similarly named command in Bash or another shell.

Help describes syntax, binding, and effects

Get-Help and official reference pages explain parameter types, parameter sets, examples, and related commands. Get-Command can reveal discovered commands and metadata, while Get-Member helps inspect the objects produced later. Updating help can require network access and is not an offline prerequisite for understanding a provided example. Read whether a command changes state, accesses a provider, contacts a service, or requires privileges before running it. Examples in this course are illustrative when PowerShell is unavailable locally; no discovery command, module import, profile, service, or credential source has been executed here.

powershell Illustrative in-memory command composition

$items = @('review', 'archive')
$items | ForEach-Object { $_.ToUpperInvariant() }

On the documented language model this emits REVIEW and ARCHIVE. The block remains non-runnable because no PowerShell engine was available to test it; it accesses no host resource by design.

Execution context is part of the interface

A command’s contract includes inputs, output types, error behavior, side effects, and environmental assumptions. Profiles, loaded modules, current location, culture, and preference variables can change observable behavior. A clean automation entry point should state what it imports and which session state it accepts. Qualification can help distinguish commands, but it does not authorize their effects. Treat host selection and privileges separately from syntax. A successful help lookup does not prove a real operation will succeed, just as a parsed data fixture does not prove that a cmdlet exists on every supported target.

Report the tool actually used for a check

An offline model can check a declared compatibility table or data transformation without starting PowerShell. It must not be described as engine parsing, parameter binding, or cmdlet execution. This environment has Python but no pwsh or powershell executable, so only the supplied synthetic models are run. All PowerShell, platform, remoting, credential, and administrative examples remain non-runnable. This limitation keeps the teaching evidence truthful while still making the contracts concrete. Later runtime verification belongs in a separately authorized private lab with the required edition and modules, not against configured services or production systems.

python Render a declared edition distinction offline

editions = {'PowerShell 7.6': 'cross-platform baseline', 'Windows PowerShell 5.1': 'Windows/.NET Framework'}
for name, scope in editions.items():
    print(f'{name}: {scope}')

Expected output

PowerShell 7.6: cross-platform baseline
Windows PowerShell 5.1: Windows/.NET Framework

The Python dictionary prints teaching metadata only. It does not inspect installed PowerShell, load a module, or certify platform compatibility.

Common errors and fixes

PowerShell 7 and 5.1 are treated as identical

Why it happens: Edition and platform dependencies were omitted.
How to fix it: Record the actual runtime and supported module contracts.
Prevent it next time: Maintain an explicit compatibility matrix.

An alias becomes an undocumented script dependency

Why it happens: Interactive convenience replaced explicit command selection.
How to fix it: Use clear command names and declared imports.
Prevent it next time: Test outside personal profiles.

An offline model is called a PowerShell runtime test

Why it happens: The evidence boundary was overstated.
How to fix it: Name the parser/model and untested engine behavior.
Prevent it next time: Separate conceptual and runtime verification reports.

Check your understanding

1. Why can a Windows-only module remain unavailable in cross-platform PowerShell?

Show worked solution

The language runtime does not supply every operating-system API or module dependency. Review that module’s supported platforms and .NET requirements rather than assuming installation of PowerShell makes the underlying Windows capability exist elsewhere.

2. What should a test report say when only the Python fixture ran?