About This Article
This article was created using an automated generation workflow powered by generative AI. We consulted Microsoft Learn regarding GetDpiForSystem and organized a minimal try-out to call the Win32 API from PowerShell and observe the Windows DPI value.
Verification Status: 📘 Microsoft Official Specification Confirmed / Windows Physical Device Unverified
The success condition for this try is:Calling GetDpiForSystem from PowerShell and successfully displaying a non-zero DPI value.
Smoke Test
Add-Type @'
using System.Runtime.InteropServices;
public static class DpiApi {
[DllImport("user32.dll")]
public static extern uint GetDpiForSystem();
}
'@
$dpi = [DpiApi]::GetDpiForSystem()
if ($dpi -eq 0) { throw '[FAILED] DPI = 0' }
"[SUCCESS] SystemDpi = $dpi"
Observe
Check whether values corresponding to the environment, such as 96, 120, or 144, are displayed. Determine whether the API call succeeded based on the return value rather than simply the absence of errors.
Why?
Windows UI sizing is not determined by physical pixels alone. Because DPI and scaling are involved, relying solely on fixed pixels when building a GUI leads to environment-dependent discrepancies.
Change One Thing
Instead of changing the Windows display scale, first compare values across a different PC or a different configuration environment. If settings must be changed, record the original values beforehand.
Failure / Boundary
The meaning of the API and the recommended APIs vary depending on the DPI awareness state. For apps that require per-monitor DPI, consider alternative APIs such as GetDpiForWindow.
For Professional Use
This serves as an entry point to understanding why text and button sizes might change on different PCs when building internal tools with PowerShell and WPF.
