There are documented values for Windows Vista to 10. The first Insider build of Windows 11 was just released, and the documentation wasn't updated yet, but perhaps it can be found somewhere in the system.
After a bit of fiddling around, seems like the current answer (at least for build 22000.51) is that there's no GUID yet. I found the list of GUIDs in ntdll.dll under the symbol SbSupportedOsList, referenced by a function called SbGetContextDetailsByVersion. The list contains only the five GUIDs mentioned in the documentation.
Microsoft says
... The following GUIDs correspond with the indicated operating systems:
{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} -> Windows 10, Windows 11, Windows Server 2016, Windows Server 2019 and Windows Server 2022 ...
Application Manifests: Elements: supportedOS
have a look at
https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/SbsCs/application-manifests.md#application
you use the windows 10 guide for >= windows 10, and >= server 2016
There is no new supportedOS manifest because Microsoft decided to keep the 10.0 version number. The supportedOS manifest for Windows 10 will continue to expose the current build number; 21996 and up can be assumed to be Windows 11.
Related
I just recently found out about the need for a manifest file so that my native C++ Windows app will properly detect the Windows version. Previously my app was running under the "Operating System Context" of "Windows Vista", but thanks to the manifest file it now runs under the appropriate context for the OS it's running on.
This has sent me down a rabbit hole to learn more about what "Operating System Context" means, and why I should care about it. I've been searching for specific information on what happens under the hood and the best page I've found is:
https://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx
This page details what the Windows Vista (default) application behavior is, and what behavior you can get if you add Windows 7 support via the manifest file.
Here's my problem; I can't find any information like this for Windows 8, 2012, 10, or 2016. I read through the Windows Compatibility Cookbook, but it doesn't seem to contain the type of information available in the above link.
What terms should I be searching for? Is there an up-to-date MSDN page I can bookmark that keeps track of the "Operating System Context" differences?
Thanks!
Partial answer -
Microsoft's page on Application Manifests for Windows 8 and Server 2012 has a section on the SupportedOS element, which refers readers to the download page for the Windows 8 and Windows Server 2012 Compatibility Cookbook. This Cookbook also covers Windows 8.1 and Windows Server 2012 R2. Within this Cookbook, the heading "App (executable) manifest" discusses the the Windows features included in Windows 8 and 8.1 (as well as Windows Server 2012 & 2012 R2) which are impacted by the presence or absence of the corresponding supportedOS element. Search this doc for supportedOS, as it is mentioned in other sections as well.
As for Windows 10 (and implicitly Windows Server 2016), the latest Windows Compatibility Cookbook can be read online or downloaded from this web page. Unfortunately, this latest Cookbook does not go into the details of the specific Windows features that are new or impacted by the supportedOS element for Windows 10. But many of the various behavior changes or compatibility issues with Windows 10 are discussed here.
This page:
Application Manifest
Lists certain changes that occur if you specifically flag your application as compatible with Windows 7. For example:
Windows 7: To improve scalability and reduce thread counts, RPC switched to the NT thread pool (default pool). For Windows Vista, RPC used a private thread pool.
...
Windows Vista (default): For binaries compiled for Windows Vista and below, the private pool is used.
Are there any similar lists of changes that occur on newer versions of Windows (8, 8.1, 10) if you specify their supportedOS GUID in the manifest, vs not specifying one at all?
You are reading Windows 7 documentation. Try reading newer documentation, such as this one for Windows 8:
App (executable) manifest
Windows 10 has not been released yet, so MSDN does not have much in the way of Windows 10 documentation yet. However, the supportedOS guid for Windows 10 has been mentioned in some MSDN blogs, at least:
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
On MSDN lot win32 functions contain this statement:
Requirements: Minimum supported client - Windows 2000 Professional.
Is it really necessary to use the pro version, or function works with home version.
I use windows-xp home, and I can run many functions, but one function fails without reason, could be that it fails because I do not use pro version?
There was no "Home" versions of Windows 2000, Professional was the only non-server version released.
If the documentation displays it as the minimum supported version & do not list exceptions for XP, then anything with a minimum of "Windows 2000 Professional" will run on XP Home or Pro.
When reading the MSDN documentation for WinLocalLogonSid value of WELL_KNOWN_SID_TYPE enumeration, that is:
WinLocalLogonSid
Indicates a SID that matches a local logon group.
Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: This value is not available.
there is an uncertainty of meaning in the system requirement statement. It can be one of the following meanings:
WinLocalLogonSid start to exist in Windows 8.
In case of the documentation is not yet updated to Windows 8, it can also means that WinLocalLogonSid only exists in Windows versions prior to Windows XP.
Unfortunately, those enumeration values were not documented in the header source code.
I made a check for WinNT.h from Windows 7 SDK, surprisingly, the WinLocalLogonSid was available there. I don't have a definite conclusion for this fact because there is a possibility that an identifier is declared but not yet implemented.
So, could someone experienced on this stuffs tell me what is the meaning of such a system requirement statement in MSDN?
Notice that it says at the bottom:
Minimum supported client: Windows XP
Minimum supported server: Windows Server 2003
So yes, it is only Windows 8.
Edit note: After a seemingly enourmous amount of bad feedback MS got from their customers regarding the drop-XP-stunt, they have announced that a patch will be released that'll allow to build executables for XP. So the base for this Q is no lonher really there, but I think it collects some very interesting infos.
As established here: What is special about the executables compiled with Visual Studio 11 which results in that the executables cannot be executed on Windows XP?
and in this Connect bug/issue: https://connect.microsoft.com/VisualStudio/feedback/details/690617, Visual Studio 11 (planned release 2012) is planned to no longer support Windows XP.
That means you cannot create a native C++ executable that can be executed on Windows XP. (One reason being that the new CRT will use Windows API calls that are only available on Windows Vista and higher.)
In one answer, Anders writes:
They seem to drop support for older systems in every new release of VS (NT4,2000,XP) ...
What interests me now is whether this move by Microsoft to drop Windows XP support completely from VS11 C++ can actually be compared to prior releases.
What I mean is, when was support for which OS (NT3.5 / NT4 / 2000sp6 // Win95 / Win98 / ...) completely dropped from Visual C++. (and "what part" of Visual C++ -- the compiler, the CRT, the Windows SDK?)
For example, I think I know that VC6 is the last version of VS that can be used to create executables that run on Windows NT4. I also seem to remember that the dropped support for Win2k had more to do with the Windows SDK you are using than with the actual compiler or CRT, but I'm not sure.
Is there a good resource that shows which MS compilers in which setting can produce compatible code for which OS versions? Is the timing of VS11 (year 2012) no longer supporting a OS that is widely installed (but no longer sold) comparable to prior releases?
One point of interest is that we're in the middle of the shift from C++03 to C++11, and if you're stuck with Windows XP and VC10, the you're stuck with the limited (and partially non-standard) C++11 support it has to offer.
I think it makes sense to compare VS release dates against when the Windows versions became unsupported, rather than when the Windows versions were released.
Once an OS reaches the end of extended support it stops getting security updates and anyone still running it can be considered insane and ignored (outside of very special cases). Before then, it seems legitimate (albeit annoying at times) for people to still use old OS versions and expect software to support them (although vendors, both third-parties and Microsoft themselves, can choose not to, of course).
From Wikipedia, this is when each version of Windows became (or will become) unsupported by Microsoft:
Jan 2020: Windows 7
Apr 2017: Windows Vista
Apr 2014: Windows XP
Jul 2010: Windows 2000
Jul 2006: Windows ME
Jul 2006: Windows 98
Jun 2004: Windows NT 4
Dec 2001: Windows 95
Dec 2001: Windows NT 3
Tying that to the details in the existing answer:
VS in 2012 dropped Windows XP despite it being supported until 2014.
VS in 2010 dropped Windows 2000 which expired soon after.
VS in 2007 dropped Win98/ME both of which already expired.
VS in 2005 dropped Win95 and NT4 both of which which had already expired.
So it looks like VS2012 is the first version that will drop support for an OS which itself will still supported for at least another year. Assuming all these dates are correct (I haven't double-checked them; did this mostly for my own curiousity).
Assuming you are only talking about the minimum supported 32bit desktop editions of Windows, and customer support from Microsoft.
VC11 (y 2012): Windows Vista (y 2007)
VC10 (y2010): Windows XP SP3 (y 2008/2001)
Windows SDK 6.1: Windows XP (y 2001)
VS2008 (y 2007): Windows 2000 SP4 (y 2003). The latest security update dropped Windows 2000 support.
Windows SDK Update for Windows Vista: Windows 2000 (y 2000)
VS2005 (y 2005): Windows 98 (y 1998), Windows 2000 Service Pack 3, Windows XP, Windows NT 3 (y 1993). SP1 dropped 9x support. The latest security update dropped Windows 2000 support.
VC6 (y 1998): Windows 95 (y 1995), Windows NT ??
Compiler can be upgraded via Visual C++ Toolkit 2003
Platform SDK can be upgraded, up to the Feb 2003 version of Windows 2003 SDK.
Support for 64bit OS varies but a good indicator is whether the target OS is still supported at the time of release. The first stable version of SDK with 64bit support is VC2005.
Hacks (may cause more problem down the road)
Patch the executable
Visual C++ compiler: There is a /SUBSYSTEM and a /OSVERSION switch whose default value change over time but you can easily modify the value via the compiler switch or using a hex editor if you know the PE format.
Modify the executable to remove new API calls if you are confident that the code that calls the new API won't be touched in your program.
CRT/MFC/ATL
Make a private build using different build options, or recompile old versions if you have the source code and cannot remove new API calls from a new version.
Fool the linker to link against your own implementation of framework functions. This is used to reduce the size of MFC apps, but this can also drop dependencies like GDI+ during the process.
Microsoft have announced that support for building C++ applications targeted at Windows XP will be included in Visual Studio 2012, so that does make 2012 comparable to previous release of Visual Studio in this respect.
http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx