How to detect a version of Windows 2012 Core (C ++)

Question

I need to determine the release in Windows 2012 in my program.
In the previous OS, I used GetProductInfo pdwReturnedProductType, but according to msdn:

PRODUCT _ * _ SERVER_CORE values ​​are not returned in Windows Server 2012. For example, the core server
Edition, Server Datacenter, is used to create two different installation parameters: "full server"
and "primary server". With Windows Server 2012, GetProductInfo will return PRODUCT_DATACENTER regardless of the option used during product installation.

Is there any other way to discover the main release?
Thanks.

Answer 1

In fact, I did not find the correct way to detect Windows Core Edition.
So, the solution for Win 2012 to detect the dwm.exe process is working (Desktop Window Manager). It always works, cannot be killed by the user, and does not exist in Windows Core editions.

Answer 2

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels\ ServerCore = 1 Server-Gui-Mgmt = 1 Server-Gui-Shell = 1 

according to MSDN , using these registry values ​​is one way. Another would be to analyze the debug output of /online /get-features /format:table and see if ServerCore-FullServer is enabled. If it is disabled, then you are in servercore faceless access mode.

Answer 3

You can create a program / function that tests a function / library that is not in the main version of .NET. For instance:

 using System; public class CoreChecker { public static void Main(string args[]) { try { ImportNonCoreComponent(); Console.WriteLine("NonCoreAssembly found... this is full server."); } catch (Exception e) { Console.WriteLine("NonCoreAssembly not found... this is core server."); } } public static void ImportNonCoreComponent() { using NonCoreAssembly; } } 

If this does not work, you will need to transfer the usage to the scope of the class and then create the class from NonCoreAssembly to ImportNonCoreComponent (I cannot recall the exact semantics of how this works).

NOTE. The using statement must be isolated from the test function. When the JIT compiler processes it, it throws an exception. This exception will not be handled by the test function, so the try ... catch statement must be in the method that calls it.

You can use this technique to implement a custom action in MSI to crash during installation, or use it as part of your C # application to trigger the message “You need to use a full server”. (which will work if they install the application and then upgrade to Core).

If the difference is behavioral, you can test this behavior in your test function.

Make sure that the test function works in different scenarios and with different versions of .NET.