PowerShell - Microsoft's Object-Based Shell That Somehow Works

Look, I've been using PowerShell since version 1.0 back in 2006, and I'll be straight with you - it's slow to start, eats memory like crazy, but once it's running? It's actually pretty fucking brilliant. PowerShell 7.5 (released February 2025) fixes some long-standing performance issues that made me want to throw my laptop out the window.

The Object Thing Actually Matters

Here's the deal: while you're in bash land parsing text with awk, grep, and sed like it's 1975, PowerShell treats everything as actual .NET objects. Run Get-Process | Where-Object {$_.CPU -gt 100} and you get real process objects with properties you can actually work with. No more | cut -d' ' -f3 bullshit. When I started using PowerShell, this felt weird. Now when I go back to bash, everything feels like stone age text manipulation.

The PowerShell pipeline architecture is fundamentally different from Unix shells - instead of text streams, it passes .NET objects between cmdlets, maintaining all properties and methods throughout the chain.

Cross-Platform (But Windows Is Still King)

Microsoft open-sourced PowerShell in 2016 which shocked everyone, including me. It runs on Linux and macOS now, but let's be honest - it's still best on Windows. The GitHub repo has 44k+ stars, which is impressive for a Microsoft shell that most Linux people refuse to touch on principle.

The cross-platform strategy includes installation packages for major Linux distributions and Docker support. But feature parity between platforms isn't perfect - Windows-specific cmdlets obviously don't work on Linux.

I've run PowerShell on Ubuntu and it works fine, but you lose all the Windows-specific cmdlets that make it actually useful. Want to manage Active Directory from Linux PowerShell? Good luck. It's there for consistency, not because it's better than bash on Linux.

Enterprise Integration (The Real Reason We Use It)

PowerShell shines when you're stuck in Microsoft hell - I mean, enterprise environments. Azure PowerShell, Exchange cmdlets, Active Directory management - it's all there and it actually works. Spent 6 hours yesterday automating Office 365 user provisioning that would've taken me days clicking through the admin portal.

The enterprise integration goes deep: PowerShell DSC for configuration management, the PowerShell Gallery with 12,000+ community modules, Group Policy integration, and PowerShell remoting for enterprise automation.

The cmdlet naming (Get-, Set-, New-, Remove-) seems verbose until you realize you can discover everything with tab completion. Try typing Get-Service and pressing Tab - boom, you can see what's available.

Performance Finally Got Fixed (Mostly)

PowerShell 7.5 fixed the array concatenation performance that's been broken since forever. The += operator is way faster now for large arrays, which means my scripts that used to take forever now finish way faster. Still not as fast as bash for simple text processing, but for object manipulation? It's actually competitive now.

The performance improvements in PowerShell 7.x include better startup time optimization, improved array operations, and better .NET 9 integration. Still not perfect, but way better than before.

Startup time is still garbage though - 3 seconds to load the shell because it has to initialize the entire .NET runtime. I've learned to live with it, but coming from bash where everything starts instantly, it's painful.

PowerShell runs on the .NET Runtime, which explains both its power and why it's slower than molasses on startup. Everything in PowerShell is a .NET object, which means you get strong typing and can call any .NET method directly. It's like having the entire .NET framework available from your command line - powerful as hell but with a 3-second startup penalty.

The .NET Core architecture provides cross-platform compatibility while the PowerShell engine handles cmdlet execution, pipeline management, and object serialization for remoting.

Cmdlet Design: Verbose But Discoverable

The Verb-Noun cmdlet pattern seems excessive until you've spent months trying to remember if it's ps or pgrep or tasklist on different systems. Get-Process, Set-Location, New-Item - over 1,000 cmdlets that all follow the same pattern. After using PowerShell for a while, going back to cryptic Unix commands feels like archaeology.

The approved verb list includes Common Verbs (Get, Set, Add, Remove) and Lifecycle Verbs (New, Start, Stop, Restart). You can discover cmdlets using Get-Command with wildcards or tab completion.

The real magic is that cmdlets return actual objects. Run Get-Process and you get System.Diagnostics.Process objects with all their properties and methods. No more parsing ps output with awk - you can just pipe to Sort-Object CPU -Descending and get what you want.

Execution Policies: Security Theater or Necessary Evil?

Execution policies are Microsoft's way of making security everyone else's problem. Default is Restricted which blocks all scripts, because apparently double-clicking a .ps1 file is dangerous but running powershell -c "malicious code here" is totally fine.

The different execution policy levels include Restricted, AllSigned, RemoteSigned, and Unrestricted. Enterprise environments usually use RemoteSigned or PowerShell Constrained Language Mode for tighter security.

Most devs just run Set-ExecutionPolicy Unrestricted and move on with their lives. Enterprise environments use RemoteSigned which requires downloaded scripts to be signed. It's not terrible security, just annoying when you're trying to run a quick script and get the dreaded execution policy error. Pro tip: powershell -ExecutionPolicy Bypass skips all this nonsense.

The Module Ecosystem Actually Rocks

The PowerShell Gallery has 12,000+ modules and most of them don't suck. Key ones that'll save your ass:

• Az - 200+ Azure modules that work better than the Azure CLI half the time
• ActiveDirectory - AD management without clicking through MMC hell
• ExchangeOnlineManagement - Office 365 management that actually works
• VMware.PowerCLI - vSphere automation that beats the web client

Installing is easy: Install-Module Az and you're done. Module versioning can be a pain though - I've had Azure module conflicts break scripts when updates changed cmdlet parameters.

For module management, use PowerShellGet for installation, pin module versions in your scripts, and consider private repositories for internal modules.

Advanced Features That Actually Matter

PowerShell supports classes now, which feels weird in a shell but is useful for complex scripts. Splatting lets you pass parameters as hash tables - saves your sanity on cmdlets with 20+ parameters:

Other advanced features include PowerShell jobs for background processing, PowerShell workflows (deprecated in 7.x), and advanced function parameters.

$params = @{
    Name = \"MyVM\"
    ResourceGroupName = \"Production\"
    Size = \"Standard_D2s_v3\"
}
New-AzVM @params

DSC (Desired State Configuration) is PowerShell's config management system that competes with Ansible and Puppet. It works great on Windows, less great everywhere else.

DSC includes built-in resources for managing files, services, and registry keys, plus community DSC resources and pull servers for centralized configuration management.

Performance: Finally Fixed After 15 Years

PowerShell 7.5 fixed array concatenation that's been shit since version 1. The += operator went from unusably slow to way faster. Still not bash-fast for simple text processing, but for object manipulation it's competitive.

The key lesson: never do $array += $item in loops. Use ArrayList or Generic Lists instead - they don't recreate the entire array every time.

Memory usage is still heavy - PowerShell can easily eat 100MB+ just sitting there. The .NET 9 garbage collector helps with long-running scripts, but it's never going to be as lightweight as bash.

Integration Hell (The Good Kind)

PowerShell talks to everything Microsoft: WMI, COM objects, .NET APIs - if it runs on Windows, PowerShell can probably control it. Third-party tools usually have PowerShell modules too, making it the swiss army knife of Windows automation.

Integration examples include SQL Server PowerShell, Hyper-V management, Windows Event Log analysis, IIS administration, and Office 365 automation. Even Docker has PowerShell support.

The downside? You become dependent on this integration. Try moving your PowerShell automation to Linux and half your cmdlets don't exist.