On Nov 19 21:29, Corinna Vinschen wrote: > On Nov 19 14:20, Larry Hall (Cygwin) wrote: > > On 11/19/2013 2:03 PM, Corinna Vinschen wrote: > > >On Nov 19 13:21, Charles Wilson wrote: > > >>On 11/19/2013 12:13 PM, Corinna Vinschen wrote: > > >>>Why do they have to make such a mess out of a simple function like > > >>>GetVersionEx? It returns different OS version numbers based on the > > >>>existence of a manifest in the executable. How dense is that? > > >>> > > >>>So we have thousands of executables, none of them has a 8.1 manifest. > > >>>As a result, the uname() function returns OS versions 6.2 rather than > > >>>6.3. Aaaaaargh. > > >>> > > >>>In cygcheck I added a patch to check dwBuildNumber this morning. If > > >>>it's >= 9200, it's 8.1/2012R2, otherwise 8/2012. But that doesn't > > >>>fix the OS version number of course. Sigh. > > >>> > > >>>I'm going to tweak the OS version number and I'll do the same in > > >>>Cygwin's uname function as well. > > >> > > >>Good grief. I suppose I need to add something similar to > > >>/usr/lib/csih/winProductName.exe... > > > > > >Looks like it, yes. What on earth were they thinking? > > > > Who says they were thinking? ;-) > > Point. > > I found what happened: > http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074%28v=vs.85%29.aspx > > Given that we are unable to provide and change manifests on the fly for > thousands of executables, we will have to hack our way along in future > because all upcoming versions of Windows will return a wrong OS version > number. > > Why isn't there at least an additional non-manifest way to claim > compatibility with the current OS? :( Oh, and it's worse than I thought. dwBuildNumber 9200 is the Windows 8 build number, so my workaround doesn't work and the entire version information will be stuck at Windows 8 for the forseeable future, unless somebody knows a workaround for this manifest mess. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat