A video with text on the top saying Gemini 3 and text on the bottom saying Learn, build, plan anything. In the middle of the screen, alternating slides show Gemini 3 demos, including creating an explorable visual 3-day itinerary to Rome.

On Dec. 2, QuickTime turned 34, and despite its origins in Apple's chaotic 1990s (1991 to be exact), "it's still the backbone of video on our devices," writes Macworld's Jason Snell. That includes MP4 and Apple's immersive video formats for Vision Pro. From the report: By the late '80s and early '90s, digital audio had been thoroughly integrated into Macs. (PCs needed add-on cards to do much more than issue beeps.) The next frontier was video, and even better, synchronized video and audio. There were a whole lot of challenges: the Macs of the day were not really powerful to decode and display more than a few frames per second, which was more of a slideshow than a proper video. Also, the software written to decode and encode such video (called codecs) was complex and expensive, and there were lots of different formats, making file exchange unreliable. Apple's solution wasn't to invent entirely new software to cover every contingency, but to build a framework for multimedia creation and playback that could use different codecs as needed. At its heart was a file that was a container for other streams of audio and video in various formats: the QuickTime Movie, or MOV. [...] QuickTime's legacy lives on. At a recent event I attended at Apple Park, Apple's experts in immersive video for the Vision Pro pointed out that the standard format for immersive videos is, at its heart, a QuickTime container. And perhaps the most ubiquitous video container format on the internet, the MP4 file? That standard file format is actually a container format that can encompass different kinds of audio, video, and other information, all in one place. If that sounds familiar, that's because MPEG-4 is based on the QuickTime format. Thirty-four years later, QuickTime may seem like a quaint product of a long-lost era of Apple. But the truth is, it's become an integral part of the computing world, so pervasive that it's almost invisible. I'd like to forget most of what happened at Apple in the early 1990s, but QuickTime definitely deserves our appreciation.

Read more of this story at Slashdot.

Build with Gemini 3 Pro, the best model in the world for multimodal capabilities.

A practical breakdown of how to use the PowerShell switch statement with patterns, variables, arrays, hashtables, and real-world examples.

What is the PowerShell switch statement?

Ever wondered how to handle multiple conditions in your scripts without long chains of if and elseif statements?

If you are familiar with if and elseif statements in PowerShell, you will find that switch statements are similar but simpler in structure. The PowerShell switch statement is especially useful for checking multiple conditions, values, or object properties. Switch statements are easier to read, require far less repetitive typing, and achieve the same outcome as if or elseif chains.

How the PowerShell switch statement works

Why does the PowerShell switch statement simplify multi-condition logic?

If statements compare one condition at a time. Although elseif lists can replicate switch logic, the switch statement evaluates conditions more efficiently. When a condition matches, its action block runs. Compared to multiple if blocks, switch statements offer cleaner and more readable code.

Elseif statement comparison

Here’s a typical elseif statement:

$date = $(Get-Date).DayOfWeek  

if ($date -eq 'Sunday') {  
    Write-Output "Today is $date."  
} elseif ($date -eq 'Monday') {  
    Write-Output "Today is $date."  
} elseif ($date -eq 'Tuesday') {  
    Write-Output "Today is $date."  
} elseif ($date -eq 'Wednesday') {  
    Write-Output "Today is $date. HUMP DAY!"  
} elseif ($date -eq 'Thursday') {  
    Write-Output "Today is $date."  
} elseif ($date -eq 'Friday') {  
    Write-Output "Today is $date."  
} else {  
    Write-Output "Today is $date."  
}  

This script loops through each comparison and executes only one matching condition.

Switch statement script block

Here is the equivalent switch statement:

$date = $(Get-Date).DayOfWeek  

switch ($date) {  
    Sunday     { Write-Output 'Today is Sunday.' }  
    Monday     { Write-Output 'Today is Monday.' }  
    Tuesday    { Write-Output 'Today is Tuesday.' }  
    Wednesday  { Write-Output 'Today is Wednesday. HUMP DAY!' }  
    Thursday   { Write-Output 'Today is Thursday.' }  
    Friday     { Write-Output 'Today is Friday.' }  
    Saturday   { Write-Output 'Today is Saturday.' }  
}  

This approach provides the same functionality and is easier to maintain.

Feature	PowerShell Switch	If / ElseIf Chain
Best for	Handling multiple conditions with clean, compact logic	Simple or one-off conditional checks
Readability	High — easy to scan, structured case blocks	Lower — becomes harder to read as conditions increase
Pattern support	Yes — supports Wildcard, Regex, Exact, CaseSensitive	No — must manually write -like, regex, or expressions
Performance	Efficient with many comparisons	Less efficient due to repeated evaluations
Ideal use cases	Argument parsing, classification, file type handling	Binary choices, simple numeric evaluations

Syntax and construct of the PowerShell switch statement

What exactly happens inside a switch block?

In PowerShell, a case statement inside a switch structure is an individual condition evaluated against an expression. When a match occurs, its associated code block runs.

Concept of a switch case

A switch case defines a matching condition and an action. A switch statement evaluates an expression, compares it against each case, and runs the first matching block. A default block runs when no other case matches.

Structure of a switch case

switch ($input) {  
    "value1" {  
        # Action for value1  
    }  
    "value2" {  
        # Action for value2  
    }  
    default {  
        # Fallback action  
    }  
}  

Switch statements check cases in order, stop at the first match, and fall back to default when needed.

Example with expressions

$value = 50  

switch ($value) {  
    { $_ -lt 25 } {
        Write-Output "Less than 25."  
    }  
    { $_ -ge 25 -and $_ -lt 75 } {  
        Write-Output "Between 25 and 75."  
    }  
    default {  
        Write-Output "75 or greater."  
    }  
}  

Expressions provide a flexible way to create dynamic switch conditions.

Using variables in PowerShell switch statements

How can variables make your switch logic more dynamic?

Variables allow your cases to evaluate changing values or thresholds.

Using variables in cases

$threshold = 100  
$value = 75  

switch ($value) {  
    { $_ -lt $threshold } {  
        Write-Output "The value is below the threshold."  
    }  
    { $_ -ge $threshold } {  
        Write-Output "The value meets or exceeds the threshold."  
    }  
}  

Variable-based logic supports dynamic comparisons and reusable conditions.

Using arrays in PowerShell switch statements

Did you know switch can evaluate entire arrays automatically?

When you pass an array to switch, PowerShell evaluates each element against all cases.

Using arrays in a switch statement

$numbers = 1..5

switch ($numbers) {  
    1 { Write-Output "One" }  
    2 { Write-Output "Two" }  
    3 { Write-Output "Three" }  
    default { Write-Output "Other number" }  
}  

Each item in the array is processed individually.

Example with strings

$fruits = @("apple", "banana", "orange", "grape")  

switch ($fruits) {  
    "apple" { Write-Output "An apple a day keeps the doctor away." }  
    "banana" { Write-Output "Bananas are rich in potassium." }  
    "orange" { Write-Output "Oranges are a good source of vitamin C." }  
    default { Write-Output "Unknown fruit: $PSItem" }  
}  

Example with complex conditions

$words = @("PowerShell", "switch", "case", "array", "script")

switch ($words) {  
    "*shell" { Write-Output "Contains 'shell': $PSItem" }  
    { $_.Length > 5 } { Write-Output "Long word: $PSItem" }  
    default { Write-Output "Other word: $PSItem" }  
}

Using hashtables in PowerShell switch statements

How can switch and hashtables work together to model structured logic?

Hashtables provide a structured mapping of keys and values you can use within switch logic.

Using hashtables as a data source

$colors = @{  
    "red" = "Stop"  
    "yellow" = "Caution"  
    "green" = "Go"  
}  

$color = "yellow"  

switch ($color) {  
    "red" { Write-Output $colors["red"] }  
    "yellow" { Write-Output $colors["yellow"] }  
    "green" { Write-Output $colors["green"] }  
    default { Write-Output "Unknown color" }  
}

Using hashtables for complex conditions

$levels = @{  
    "low" = 1  
    "medium" = 2  
    "high" = 3  
}  

$input = "medium"  

switch ($input) {  
    { $levels[$_] -lt 2 } { Write-Output "This is a low-level alert." }  
    { $levels[$_] -eq 2 } { Write-Output "This is a medium-level alert." }  
    { $levels[$_] -gt 2 } { Write-Output "This is a high-level alert." }  
    default { Write-Output "Unknown alert level." }  
}

Break statement

When should you stop evaluating additional cases?

The break keyword exits a switch statement immediately after a match.

When to use a break keyword

$fruit = "orange"  

switch ($fruit) {  
    "apple" { Write-Output "It's an apple." }  
    "orange" {  
        Write-Output "It's an orange."  
        break  
    }  
    "banana" { Write-Output "It's a banana." }  
    default { Write-Output "Unknown fruit." }  
}  

Use break when you need early termination or want to avoid overlapping matches.

Default clause

How do you handle unexpected values gracefully?

The default clause provides a fallback when no case matches.

Structure of a default block

$input = "unknown"  

switch ($input) {  
    "apple" { Write-Output "This is an apple." }  
    "banana" { Write-Output "This is a banana." }  
    default { Write-Output "Unknown fruit." }  
}

Default conditions help with error handling and logging.

Match clause using PowerShell switch parameters

Why does PowerShell offer multiple switch matching modes?

PowerShell switch supports parameters that change how cases are evaluated.

The -Wildcard parameter

Wildcard matching works like the -like operator.

$filename = "report2024.docx"

switch -Wildcard ($filename) {  
    "*.docx" { Write-Output "This is a Word document." }  
    "*.xlsx" { Write-Output "This is an Excel spreadsheet." }  
    "report*.docx" { Write-Output "This is a Word report." }  
    default { Write-Output "Unknown file type." }  
}

Multiple wildcard patterns

$input = "abc123"

switch -Wildcard ($input) {  
    "abc*" { Write-Output "Starts with 'abc'." }  
    "*123" { Write-Output "Ends with '123'." }  
    "?bc1??" { Write-Output "Pattern matched." }  
    default { Write-Output "No match." }  
}

The -CaseSensitive parameter

$input = "Apple"

switch -CaseSensitive ($input) {  
    "Apple" { Write-Output "This is a capitalized Apple." }  
    "apple" { Write-Output "This is a lowercase apple." }  
    default { Write-Output "This does not match any case." }  
}

The -RegEx parameter

$input = "user123@example.com"

switch -RegEx ($input) {  
    "^[a-z]+[0-9]*@[a-z]+\.[a-z]+$" { Write-Output "This is a valid email address." }  
    "^[a-z]+[0-9]*$" { Write-Output "This is a username." }  
    default { Write-Output "Input does not match any pattern." }  
}  

The -Exact parameter

$fruit = "Apple"

switch -Exact ($fruit) {  
    "Apple" { Write-Output "This is a capitalized Apple." }  
    "apple" { Write-Output "This is a lowercase apple." }  
    default { Write-Output "Unknown fruit." }  
}

The -File parameter and $PSItem

$logFile = "log.txt"  

switch -File $logFile {  
    { $PSItem -like "*Error*" } { Write-Output "Found an error: $PSItem" }  
    { $PSItem -like "*Warning*" } { Write-Output "Found a warning: $PSItem" }  
    { $PSItem -like "*Info*" } { Write-Output "Found an informational message: $PSItem" }  
    default { Write-Output "Unrecognized log entry: $PSItem" }  
}  

Real-world examples of using the PowerShell switch statement

Where can you apply switch effectively in scripts?

Command-line argument parsing

param (  
    [string] $mode,  
    [int] $count  
)

switch ($mode) {  
    "start" { Write-Output "Starting process with count $count." }  
    "stop" { Write-Output "Stopping process." }  
    "status" { Write-Output "Checking status." }  
    default { Write-Output "Unknown mode." }  
}

Task automation

$status = "completed"

switch ($status) {  
    "pending" { Write-Output "Task is pending." }  
    "in-progress" { Write-Output "Task is in progress." }  
    "completed" { Write-Output "Task is completed." }  
    default { Write-Output "Unknown status." }  
}

File handling

$fileExtension = ".txt"

switch ($fileExtension) {  
    ".txt" { Write-Output "Processing text file." }  
    ".csv" { Write-Output "Processing CSV file." }  
    ".xml" { Write-Output "Processing XML file." }  
    default { Write-Output "Unknown file extension." }  
}

User input processing

$userChoice = "yes"

switch ($userChoice) {  
    "yes" { Write-Output "User chose yes." }  
    "no" { Write-Output "User chose no." }  
    "maybe" { Write-Output "User is undecided." }  
    default { Write-Output "Unknown response." }  
}

Environment-specific configuration

$environment = "production"

switch ($environment) {  
    "development" { Write-Output "Configuring for development." }  
    "staging" { Write-Output "Configuring for staging." }  
    "production" { Write-Output "Configuring for production." }  
    default { Write-Output "Unknown environment." }  
}

Best practices and tips for using the PowerShell switch statement

How can you create cleaner, more maintainable switch constructs?

Best Practice	Why It Matters
Use clear cases	Makes the logic easier to follow and maintain
Include a default clause	Ensures unexpected values are handled safely
Avoid redundant cases	Prevents confusing overlaps and unintended matches
Use break for early exit	Improves efficiency and avoids unnecessary checks
Use wildcards/expressions	Enables flexible and powerful comparisons
Use consistent formatting	Improves readability for future maintainers
Group similar cases	Reduces code duplication and simplifies logic

Conclusion

The PowerShell switch statement is a flexible and efficient tool that improves readability and reduces condition complexity. With options such as -Wildcard, -RegEx, -Exact, and -CaseSensitive, switch statements adapt to nearly any scenario. Following best practices ensures clean and maintainable scripts.

For further learning:

• Microsoft’s official switch documentation
• Deep dive into the switch statement

Keep building your PowerShell skills!

Frequently asked questions

The post PowerShell Switch: A Complete Guide to Mastering Conditional Logic appeared first on Petri IT Knowledgebase.

Ryan is joined by Outshift by Cisco’s VP of Engineering Guillaume De Saint Marc to discuss the future of multi-agent architectures as microservices, the challenges and limitations of the infrastructure for these multi-agent systems, and the importance of communication protocols and interoperability in order to build decentralized and scalable architectures.

Today, Windows on Arm devices, such as those powered by the Snapdragon X series processors, are getting a boost thanks to an update to Prism that increases performance and enables running more apps and games under emulation.

The Prism emulator is a core part of the Windows on Arm platform, ensuring that Windows apps are able to run seamlessly on Windows on Arm even if they were built for traditional x86 processors and have not been updated to run natively on Arm.  Prism works by transparently converting an app's x86 instructions to Arm64 code as the app runs.   

With today's update, Prism expands its capability by supporting translation of more x86 instruction set architecture extensions, including AVX and AVX2, as well as related extensions BMI, FMA, F16C, and others.  These extensions are not guaranteed to be supported by a processor when running Windows, but they are common enough for some apps to depend on their availability.  They are especially relied on by creative tools and games that benefit from the efficient parallel processing that these CPU instructions provide. 

 

Features marked above in green are some of the emulated CPU features newly supported in Prism, as viewed withcoreinfo64.

With support for these additional processor features, Prism can now run a number of apps and games that were previously unable to work on Windows on Arm.  One example is Ableton Live, which will be coming to Windows on Arm as a native app next year.  Attempting to install Ableton Live 12 as an emulated app prior to this update would fail with a system requirements error because it requires AVX support. After the Prism update, the app installs and runs without issue.

 

Comparison of installing Ableton Live 12 on Windows on Arm before (left) and after (right) the update to Prism.

This Prism update has now rolled out to all Windows on Arm devices running Windows 11, version 24H2 or later.  All 64-bit x86 apps will have the updated CPU feature support enabled by default.  Any 32-bit apps will have it off by default but can be opted in using compatibility settings.

For more information about Windows on Arm, you can view our docs at Windows on Arm documentation on Microsoft Learn.

We are committed to continuing to enhance Prism emulation in Windows and are excited about the additional apps and games that will be able to run seamlessly on Windows on Arm with today's update.