If however you share your PowerShell scripts or run them from other tools (e.g. If you run scripts on your own systems only and you’re not using 3rd party tools and you’re not using Windows 8.1 (in which PowerShell.exe doesn’t have the manifest) you’re basically fine. The answer is in the manifest as discussed earlier, we can see this if we inspect PowerShell.exe with Resource Hacker: So why are these editors producing different results? We now have 3, and. Let’s check some popular editors for PowerShell. In PowerShell.exe we get the right answer: If you do not have such a manifest then you’ll get (Windows 8).

If you have such a manifest then you will get the real Windows version information.

The new approach is basically the reverse, you can mark your application as being aware of the changes in the GetVersion(Ex) Api by adding a special manifest to your application. However this meant you needed to target specific applications that are at fault. Or for all users with the Application Compatibility Toolkit: Similar things happened with applications checking if they had a specific version of windows components such as Internet Explorer.īefore Windows 10 Microsoft mitigated these errors with Application Compatibility shims which could be set per user via application properties: Or the other round, you’re not supporting an older version of Windows (say Windows XP as an example).Ī common error in such version checks is to check for a specific Windows version but forget to take new (not yet released) versions into account. A typical example is when you are using an API that only works on a specific Windows version (and up).

The reason for this change is Application Compatibility but let’s take a little closer look into this why.Īs an application developer there may be a need to check the version of the OS you’re running on. As you may heard, the API’s returning the Operating System version have changed, started with Windows 8.1 and Server 2012 R2.

Get windows version powershell