About This Article
This article is created using an automated generation workflow powered by generative AI. It reviews official Microsoft documentation for Win32, COM, and the Windows Runtime, organizing the differences in how to call them from PowerShell using concise comparative examples.Verification Status: 📘 Microsoft Official Specifications Verified / Windows Physical Device Unverified
The Windows API is not monolithic. From the perspective of PowerShell, different entry points are visible: Win32 uses P/Invoke, COM uses Automation objects, and WinRT uses Windows Runtime types.
First, Look at the Three Entry Points
Win32: Add-Type / P/Invoke
Add-Type @'
using System;
using System.Runtime.InteropServices;
public static class NativeDemo {
[DllImport("user32.dll")]
public static extern int GetSystemMetrics(int nIndex);
}
'@
"Win32 result = $([NativeDemo]::GetSystemMetrics(0))"
If the pixel value of the screen width is returned, you are calling a function in a native DLL.
COM: ProgID
try {
$shell = New-Object -ComObject WScript.Shell
"COM type = $($shell.GetType().FullName)"
} finally {
if ($shell) { [void][Runtime.InteropServices.Marshal]::FinalReleaseComObject($shell) }
}
WinRT: Windows Runtime type
For WinRT, usage conditions from PowerShell vary depending on the type and API. Rather than forcing the assumption that "everything can be called in one line," check the support conditions for the target API from Microsoft's Windows Runtime documentation before proceeding to individual trials.
Look Here
flowchart TD P[PowerShell] --> W[Win32 / PInvoke] P --> C[COM / Automation] P --> R[WinRT / Runtime metadata] W --> OS[Windows native API] C --> APP[OfficeやAutomation component] R --> MOD[Modern Windows API]
Even for the same Windows feature,the calling convention, types, lifetime, and error presentationdiffer. Rather than debating "old versus new superiority," the priority is to check which API model exposes the target feature.
Try Changing One Thing
In the Win32 example,GetSystemMetrics(0)changeGetSystemMetrics(1)to. The value changes from width to height, showing that integer constants determine the meaning of the native API.
For Professional Use
In administrative and IT automation, you can use this as atechnology selection map—for instance, choosing COM for Excel operations, Win32 for low-level Windows state checks, and WinRT candidates for relatively new Windows features. When asking AI to generate code, asking "Which of Win32, COM, or WinRT does this use?" and "Are 64-bit types or cleanup required?" makes it easier to secondary-review the generated code.
Pitfalls and Boundaries
Do not ignore 32/64-bit differences in Win32 pointers and handles.
Verify COM object lifetime and process residue.
Verify WinRT API-specific contracts, OS versions, and projections from PowerShell/.NET.
Do not equate Windows App SDK/WinUI 3 with WinRT itself.
