From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: cygcheck -svc segfaults on Windows 8.1 with cygwin64
Date: Tue, 19 Nov 2013 20:30:00 -0000 [thread overview]
Message-ID: <20131119202958.GH2936@calimero.vinschen.de> (raw)
In-Reply-To: <528BBA1A.2080209@cygwin.com>
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
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? :(
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-11-19 20:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 5:35 Gabriel Marcano
2013-11-19 10:03 ` Corinna Vinschen
2013-11-19 16:38 ` Warren Young
2013-11-19 17:13 ` Corinna Vinschen
2013-11-19 18:23 ` Charles Wilson
2013-11-19 19:03 ` Corinna Vinschen
2013-11-19 19:21 ` Larry Hall (Cygwin)
2013-11-19 20:30 ` Corinna Vinschen [this message]
2013-11-19 20:36 ` Corinna Vinschen
2013-11-19 21:06 ` Andrey Repin
2013-11-19 21:51 ` Corinna Vinschen
2013-11-19 22:34 ` Corinna Vinschen
2013-11-19 23:41 ` Jim Garrison
2013-11-20 8:59 ` Csaba Raduly
2013-11-19 23:08 ` Warren Young
2013-11-20 10:04 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131119202958.GH2936@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).