2011/4/25 Charles Wilson <cwilso11@...>:
> On 4/25/2011 1:48 PM, Jim Bell wrote:
>> GetVersionEx() in my old July 2001 MSDN says it requires Windows NT 3.5
>> or Windows 95 (or later).
>
> No, apparently the win32s add-on to Win 3.1 and 3.11 also supported
> GetVersionEx:
> http://jesusnjim.com/programming/GetVersionEx.html
>
> Recall that win32s was an implementation of a 'subset' of the 32bit
> Win32 API for running on the 16-bit OS's Win 3.1 and Win 3.11.
>
> However, it's really odd: win32s's implementation of GetVersionEx
> returns the version info of *win32s*:
> http://windowsdevcenter.com/pub/a/oreilly/windows/news/versions_0899.html:
>
> platform:major:minor == (0:1:0, 0:1:10, 0:1:15, 0:1:20, 0:1:25, 0:1:30)
>
> instead of the expected values which are the version data for the OS
> itself (e.g. 0:3:0, 0:3:10, 0:3:11)
>
> GetVersion, which existed in the 16bit OS's themselves, accurately
> returns the expected 3:10 or 3:11 information.
>
> But, we (that is, mingwrt) don't support anything older than Win95
> anyway...so we don't care about this. Thank God.
>
>> And according to that same MSDN/OSVERSIONINFO, those two oldest versions
>> would both show 4.
>>
>> So anything old enough to return less than four would be missing
>> GetVersionEx() and wouldn't run anyway.
>>
>> I say we cut this loose, or put it in a conditional compile if someone
>> wanted to build it for ancient platforms.
>
> Or use GetProcAddress...
>
> Here's how cygwin (used to) handle it, back when they supported Win95:
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.cc?rev=1.61&content-type=text/x-cvsweb-markup&cvsroot=src
>
> Note that they call GetWindowsEx unconditionally, and their big switch
> statement includes:
>
> switch (version.dwPlatformId) {
> case VER_PLATFORM_WIN32_NT:
> ... handle various values of dwMajorVersion here:
> 3 = WinNT 3.51
> 4 = WinNT 4
> 5 = Win2k, XP, or 2003
> 6 = vista
> ... note that later revisions than the one whose link is given
> ... above are smarter about various NT flavors than this old one,
> ... but they have dropped any recognition of pre-NT.
> break;
>
> case VER_PLATFORM_WIN32_WINDOWS:
> ... ignore dwMajorVersion (since for this platform, it's always '4')
> ... and handle various values of dwMinorVersion (e.g. Win95, Win98,
> ... WinME)
> break;
>
> default: /* some other 'platform ID' */
> ... report unknown ...
> break;
> }
>
> So, what this tells me is that unless I've missed something, it was
> ALWAYS wrong to only check _winmajor (or now, dwMajorVersion). You
> really should check dwPlatformID, and THEN dwMajorVersion. Furthermore,
> there IS a platform for which GetVersionEx exists, but dwMajorVersion <
> 4: WinNT 3.51 (2:3:51) [and Win3.1 with win32s installed -- 0:1:xx --
> but we don't care about that]. We probably don't care about WinNT 3.51
> either.
>
> So, can probably ignore these WinNT 3.51/Win32s corner cases...
>
> BUT...this means that tlssup.c has always been broken, ever since it was
> introduced, because the code that should fire (for win95,98,me?) only
> does so in WinNT3.51. I think the (current) conditional
> if (_winmajor < 4)
> should have been
> if (_osplatform == 1 && _winmajor <= 4)
> ...and, of course, should now be replaced by a suitable incantation
> using GetVersionEx.
>
> Summary: (a) I think Jim is partially right, in that we should assume
> GetVersionEx is present. This "breaks" support on Windows 3.x without
> win32s -- if mingwrt currently supports those platforms at all, which I
> doubt.
Yes, agree. This winmajor check here is more a kludge, and it might be
better here to check result of GetVersionEx instead.
> (b) But, I think Jim is wrong in that would should keep the check on
> (some version information), before executing the MINGWM10_DLL-related
> code. The question is, exactly WHAT should that version check BE?
>
> Kai, can you help us out here? What was the original intent for the
> code guarded inside
> #ifndef _WIN64
> if (_winmajor < 4) {
> in __dyn_tls_init() of tlssup.c?
Well, the intend here is to check for OS capability of TLS section
support. Which should be present beginning with winnt 4.0 (and SP5 or
6) AFAIR. As before the TLS section support wasn't supported, so we
fall back here to old mingwm10.dll variant for those older OSes.
Kai
|
