mingw-users

[Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Jim B. <Ji...@JC...>]

Any way to work around this undefined symbol? Anyone successfully
linking against libmsvcr90.a?

The following short program compiles and links against libmsvcr90.a, but
won't run. Instead it gives this message box:

    Entry Point Not Found
    The procedure entry point _winmajor could not be located in the
dynamic link library msvcr90.dll.

The program:
-----------------
#include <time.h>
int main(int argc, char *argv[])
    {
    time_t y = 0;
    struct tm *x = gmtime(&y);
    return 0;
    }
-----------------
Compile:
g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
-mthreads -g -frtti -fexceptions -mthreads -Wall -lstdc++ -lmingw32  -o
Prog -lmsvcr90
-----------------

I'm using MinGW release 20110316.

It appears that _winmajor is in libmsvcr90.a but not in msvcr90.dll
(9.0.30729.4148).

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Earnie <ea...@us...>]

Jim Bell wrote:
> Compile:
> g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
> -mthreads -g -frtti -fexceptions -mthreads -Wall -lstdc++ -lmingw32  -o
> Prog -lmsvcr90

Try g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
-DWINVER=0x0800 -mthreads -g -frtti -fexceptions -mthreads -Wall -o Prog
-lmsvcr90

Note that I added -DWINVER-0x0800 and dropped the -lstdc++ and -lmingw32
from the command line.  I did not test this so you may still get the
linker error.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Jim B. <Ji...@JC...>]

On 1:59 PM, Earnie wrote:
> Jim Bell wrote:
>> Compile:
>> g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
>> -mthreads -g -frtti -fexceptions -mthreads -Wall -lstdc++ -lmingw32  -o
>> Prog -lmsvcr90
> Try g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
> -DWINVER=0x0800 -mthreads -g -frtti -fexceptions -mthreads -Wall -o Prog
> -lmsvcr90
>
> Note that I added -DWINVER-0x0800 and dropped the -lstdc++ and -lmingw32
> from the command line.  I did not test this so you may still get the
> linker error.

THIS WORKS!  Thanks!

But it doesn't run. I get R6034 ("An application has made an attempt to
load the C runtime library incorrectly....")
<http://msdn.microsoft.com/en-us/library/ms235560%28VS.80%29.aspx> and
0xc0000142 (STATUS_DLL_INIT_FAILED,
<http://msdn.microsoft.com/en-us/library/cc704588%28PROT.10%29.aspx>).

I'm pretty sure it's not happy with the location of the .DLL.  I'm
following the instructions in your previous e-mail...

On 1:59 PM, Earnie wrote:
>
> ... Make sure
> that you distribute the dll in a mybinary.exe.local directory which is
> parented to the same directory containing mybinary.exe.  E.G.
> mybinary.exe is in directory c:\Program
> Files\MyPackages\bin\mybinary.exe then create c:\Program
> Files\MyPackages\bin\mybinary.exe.local and put the dependent DLLs in
> that directory.
>

If I put msvcr90.dll anywhere else (e.g., Microsoft.VC90.CRT directory),
I get "Unable to Locate Component: This application has failed to start
because msvcr90.dll was not found."

I think it wants a manifest .rc/.res/.o file.

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Earnie <ea...@us...>]

Jim Bell wrote:
> 
> 
> On 1:59 PM, Earnie wrote:
>> Jim Bell wrote:
>>> Compile:
>>> g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
>>> -mthreads -g -frtti -fexceptions -mthreads -Wall -lstdc++ -lmingw32  -o
>>> Prog -lmsvcr90
>> Try g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
>> -DWINVER=0x0800 -mthreads -g -frtti -fexceptions -mthreads -Wall -o Prog
>> -lmsvcr90
>>
>> Note that I added -DWINVER-0x0800 and dropped the -lstdc++ and -lmingw32
>> from the command line.  I did not test this so you may still get the
>> linker error.
> 
> THIS WORKS!  Thanks!
> 
> But it doesn't run. I get R6034 ("An application has made an attempt to
> load the C runtime library incorrectly....")
> <http://msdn.microsoft.com/en-us/library/ms235560%28VS.80%29.aspx> and
> 0xc0000142 (STATUS_DLL_INIT_FAILED,
> <http://msdn.microsoft.com/en-us/library/cc704588%28PROT.10%29.aspx>).
> 
> I'm pretty sure it's not happy with the location of the .DLL.  I'm
> following the instructions in your previous e-mail...
> 

Yea, you need a manifest file, see
http://msdn.microsoft.com/en-us/library/ms235624(v=VS.80).aspx.  Pay
attention to the first paragraph about the WinSxS folder.  You'll have
to work out that detail.

> On 1:59 PM, Earnie wrote:
>>
>> ... Make sure
>> that you distribute the dll in a mybinary.exe.local directory which is
>> parented to the same directory containing mybinary.exe.  E.G.
>> mybinary.exe is in directory c:\Program
>> Files\MyPackages\bin\mybinary.exe then create c:\Program
>> Files\MyPackages\bin\mybinary.exe.local and put the dependent DLLs in
>> that directory.
>>
> 
> If I put msvcr90.dll anywhere else (e.g., Microsoft.VC90.CRT directory),
> I get "Unable to Locate Component: This application has failed to start
> because msvcr90.dll was not found."
> 

You would need to add the directory to PATH or use the Windows API to
give the location of the dll search path.

> I think it wants a manifest .rc/.res/.o file.

I think so.  Maybe even the one for msvcr90.dll.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Earnie <ea...@us...>]

Earnie wrote:

> 
> I think so.  Maybe even the one for msvcr90.dll.
> 

See http://msdn.microsoft.com/en-us/library/ms235291(v=VS.80).aspx

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Khalid <kh...@ya...>]

Jim Bell <Jim@...> writes:

> 
> 
> On 1:59 PM, Earnie wrote:
> > Jim Bell wrote:
> >> Compile:
> >> g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
> >> -mthreads -g -frtti -fexceptions -mthreads -Wall -lstdc++ -lmingw32  -o
> >> Prog -lmsvcr90
> > Try g++ Prog.cpp -DWIN32 -D_WINDOWS -D_DEBUG -D__MSVCRT_VERSION__=0x0800
> > -DWINVER=0x0800 -mthreads -g -frtti -fexceptions -mthreads -Wall -o Prog
> > -lmsvcr90
> >
> > Note that I added -DWINVER-0x0800 and dropped the -lstdc++ and -lmingw32
> > from the command line.  I did not test this so you may still get the
> > linker error.
> 
> THIS WORKS!  Thanks!
> 
> But it doesn't run. I get R6034 ("An application has made an attempt to
> load the C runtime library incorrectly....")
> <http://msdn.microsoft.com/en-us/library/ms235560%28VS.80%29.aspx> and
> 0xc0000142 (STATUS_DLL_INIT_FAILED,
> <http://msdn.microsoft.com/en-us/library/cc704588%28PROT.10%29.aspx>).
> 
> I'm pretty sure it's not happy with the location of the .DLL.  I'm
> following the instructions in your previous e-mail...
> 
> On 1:59 PM, Earnie wrote:
> >
> > ... Make sure
> > that you distribute the dll in a mybinary.exe.local directory which is
> > parented to the same directory containing mybinary.exe.  E.G.
> > mybinary.exe is in directory c:\Program
> > Files\MyPackages\bin\mybinary.exe then create c:\Program
> > Files\MyPackages\bin\mybinary.exe.local and put the dependent DLLs in
> > that directory.
> >
> 
> If I put msvcr90.dll anywhere else (e.g., Microsoft.VC90.CRT directory),
> I get "Unable to Locate Component: This application has failed to start
> because msvcr90.dll was not found."
> 
> I think it wants a manifest .rc/.res/.o file.
> 
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been 
> demonstrated beyond question. Learn why your peers are replacing JEE 
> containers with lightweight application servers - and what you can gain 
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
> 
> This list observes the Etiquette found at 
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.
> 
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:mingw-users-request@...?subject=unsubscribe
> 
> 


Hello there.

I have tried this (thanks Earnie) and it indeed works if you include a manifest
and use the command Earnie suggested.

However, on inspection under Dependency Walker it seems that the output
(Prog.exe) depends on both msvcrt.dll and msvcr90.dll. 

It needs the former for 
+ _winmajor
+ abort
+ calloc
+ free
+ fwrite
+ memcpy
+ vfprintf

and from the latter everything else.

Is that safe? IOW, to have the program depend on two run-times like in this case?

I have tried to change the specs as per the MinGW wiki and managed to get rid of
the dependency on msvcrt.dll So the program only needs msvcr90.dll for
everything now. Running the program, however, brings this back to square one
with an error message from a dialog stating:

"The procedure entry point _winmajor could not be located in the dynamic link
library msvcr90.dll"

Any ideas?

I am using MinGW 4.5.0, w32api of 3.15, and _mingw of 3.18, in native Windows 32
setup.

Thanks.

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Keith M. <kei...@us...>]

On 25/04/11 09:04, Khalid wrote:
> Is that safe?  IOW, to have the program depend on two run-times like
> in this case?

Since you presumably have both DLLs available, it may work okay, but I
guess there would be scope for instability; (e.g. an exception thrown by
code in one DLL but caught in the other might have strange
consequences).  YMMV.

> I have tried to change the specs as per the MinGW wiki and managed to
> get rid of the dependency on msvcrt.dll So the program only needs
> msvcr90.dll for everything now.  Running the program, however, brings
> this back to square one with an error message from a dialog stating:
> 
> "The procedure entry point _winmajor could not be located in the
> dynamic link library msvcr90.dll"

Naturally, because apparently _winmajor isn't simply deprecated, (as
MSDN suggests), but appears to have been completely withdrawn from the
later runtime.

> Any ideas?

As a Q&D hack, you might provide your own implementation of _winmajor;
(you will need to base it around the definitions in stdlib.h).

The correct long term solution is to eliminate the dependency from
mingwrt, (the only reference I see is in tlssup.c).  That will require
implementation of an alternative strategy for handling the version
dependencies currently present.  Patches welcome!

A complete patch set should also adjust visibility of the _winmajor and
related symbols, to remove them from the mingwrt import libraries for
those versions of the runtime which no longer support them.

-- 
Regards,
Keith.

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Earnie <ea...@us...>]

Keith Marshall wrote:
> A complete patch set should also adjust visibility of the _winmajor and
> related symbols, to remove them from the mingwrt import libraries for
> those versions of the runtime which no longer support them.
> 

The alternative solution would be based on GetVersionEx()[1] which is
used by _winmajor and _winminor anyway[2].

[1] http://msdn.microsoft.com/en-us/library/ms724451(v=vs.85).aspx
[2]
http://social.msdn.microsoft.com/Forums/en-US/vcmfcatl/thread/27717ace-b2d5-4c29-bb2c-dd33d0a4600d/
(see the comment by rtischer8277 on January 12, 2011 at 2:13 PM)

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Keith M. <kei...@us...>]

On 25/04/11 13:20, Earnie wrote:
> Keith Marshall wrote:
>> A complete patch set should also adjust visibility of the _winmajor and
>> related symbols, to remove them from the mingwrt import libraries for
>> those versions of the runtime which no longer support them.
> 
> The alternative solution would be based on GetVersionEx()[1] which is
> used by _winmajor and _winminor anyway[2].

Or perhaps:
http://msdn.microsoft.com/en-us/library/ms725492(v=vs.85).aspx

In the context in which it appears in tlssup.c, VerifyVersionInfo() may
be the preferred choice.

-- 
Regards,
Keith.

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Earnie <ea...@us...>]

Keith Marshall wrote:
> On 25/04/11 13:20, Earnie wrote:
>> Keith Marshall wrote:
>>> A complete patch set should also adjust visibility of the _winmajor and
>>> related symbols, to remove them from the mingwrt import libraries for
>>> those versions of the runtime which no longer support them.
>>
>> The alternative solution would be based on GetVersionEx()[1] which is
>> used by _winmajor and _winminor anyway[2].
> 
> Or perhaps:
> http://msdn.microsoft.com/en-us/library/ms725492(v=vs.85).aspx
> 
> In the context in which it appears in tlssup.c, VerifyVersionInfo() may
> be the preferred choice.
> 

I think that is overkill based on the requirements of use.

wMajorVersion

If you are testing the major version, you must also test the minor
version and the service pack major and minor versions.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Khalid <kh...@ya...>]

Earnie <earnie@...> writes:

> 
> Keith Marshall wrote:
> > On 25/04/11 13:20, Earnie wrote:
> >> Keith Marshall wrote:
> >>> A complete patch set should also adjust visibility of the _winmajor and
> >>> related symbols, to remove them from the mingwrt import libraries for
> >>> those versions of the runtime which no longer support them.
> >>
> >> The alternative solution would be based on GetVersionEx()[1] which is
> >> used by _winmajor and _winminor anyway[2].
> > 
> > Or perhaps:
> > http://msdn.microsoft.com/en-us/library/ms725492(v=vs.85).aspx
> > 
> > In the context in which it appears in tlssup.c, VerifyVersionInfo() may
> > be the preferred choice.
> > 
> 
> I think that is overkill based on the requirements of use.
> 
> wMajorVersion
> 
> If you are testing the major version, you must also test the minor
> version and the service pack major and minor versions.
> 


Okay I have written a patch to tlssup.c, but I am unable to login again to the
CVS repository to generate a proper patch. Here is what I did:

@line 99 of tlssup.c
-#ifndef _WIN64
-  if (_winmajor < 4)
+#ifndef _WIN64
+    OSVERSIONINFO os_version_info;
+    
+    ZeroMemory(&os_version_info, sizeof(OSVERSIONINFO));
+    os_version_info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
+    GetVersionEx(&os_version_info);
+        
+  if (os_version_info.dwMajorVersion < 4)


I have built the mingwrt and tested it with the program listed earlier and the
_winmajor problem is now gone.

Best regards,
Khalid

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Chris S. <ir0...@gm...>]

On 25 April 2011 11:37, Khalid wrote:
> Okay I have written a patch to tlssup.c, but I am unable to login again to the
> CVS repository to generate a proper patch. Here is what I did:
>
> @line 99 of tlssup.c
> -#ifndef _WIN64
> -  if (_winmajor < 4)
> +#ifndef _WIN64
> +    OSVERSIONINFO os_version_info;
> +
> +    ZeroMemory(&os_version_info, sizeof(OSVERSIONINFO));
> +    os_version_info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
> +    GetVersionEx(&os_version_info);
> +
> +  if (os_version_info.dwMajorVersion < 4)
>
>
> I have built the mingwrt and tested it with the program listed earlier and the
> _winmajor problem is now gone.

Thank you for the patch.  I will apply it to the mingwrt repository tonight.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Jim B. <Ji...@JC...>]

On 1:59 PM, Khalid wrote:
> Earnie <earnie@...> writes:
>
>> Keith Marshall wrote:
>>> On 25/04/11 13:20, Earnie wrote:
>>>> Keith Marshall wrote:
>>>>> A complete patch set should also adjust visibility of the _winmajor and
>>>>> related symbols, to remove them from the mingwrt import libraries for
>>>>> those versions of the runtime which no longer support them.
>>>> The alternative solution would be based on GetVersionEx()[1] which is
>>>> used by _winmajor and _winminor anyway[2].
>>> Or perhaps:
>>> http://msdn.microsoft.com/en-us/library/ms725492(v=vs.85).aspx
>>>
>>> In the context in which it appears in tlssup.c, VerifyVersionInfo() may
>>> be the preferred choice.
>>>
>> I think that is overkill based on the requirements of use.
>>
>> wMajorVersion
>>
>> If you are testing the major version, you must also test the minor
>> version and the service pack major and minor versions.
>>
>
> Okay I have written a patch to tlssup.c, but I am unable to login again to the
> CVS repository to generate a proper patch. Here is what I did:
>
> @line 99 of tlssup.c
> -#ifndef _WIN64
> -  if (_winmajor < 4)
> +#ifndef _WIN64
> +    OSVERSIONINFO os_version_info;
> +    
> +    ZeroMemory(&os_version_info, sizeof(OSVERSIONINFO));
> +    os_version_info.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
> +    GetVersionEx(&os_version_info);
> +        
> +  if (os_version_info.dwMajorVersion < 4)
>
>
> I have built the mingwrt and tested it with the program listed earlier and the
> _winmajor problem is now gone.

GetVersionEx() in my old July 2001 MSDN says it requires Windows NT 3.5
or Windows 95 (or later).

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.

[Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Charles W. <cwi...@us...>]

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.

(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?

--
Chuck

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Kai T. <kti...@go...>]

2011/4/25 Charles Wilson <cwi...@us...>:
> 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

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Charles W. <cwi...@us...>]

On 4/25/2011 3:36 PM, Kai Tietz wrote:
> 2011/4/25 Charles Wilson 
>> 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.

OK, so the check should be (pseudo-code):

#ifndef _WIN64
if (OS is Win9x, or WinNT4sp4 or earlier)
	.... do mingwm10.dll fallback stuff


I think that becomes:

#ifndef _WIN64
if (version.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS ||
    (version.dwPlatformId == VER_PLATFORM_WIN32_NT &&
     (version.dwMajorVersion < 4 ||  /* NT 3.51 */
      (version.dwMajorVersion == 4 && /* NT 4 */
       strcmp (version.szCSDVersion, "Service Pack 5") < 0)))) /* sp4 or
below */
{
   /* add a comment about the fact that this is fallback code, for
    * older OS's, which uses the legacy mingwm10.dll gobbledygook
    * instead of TLS, to support thread initialization.
    */

   ... do mingwm10.dll stuff
}


Note that we have to use a string comparison on szCSDVersion, because
NT4 only supported OSVERSIONINFO

http://msdn.microsoft.com/en-us/library/ms724834%28v=vs.85%29.aspx

until sp6, when it added support for OSVERISONINFOEX

http://msdn.microsoft.com/en-us/library/ms724833%28v=vs.85%29.aspx

This latter structure is the first one with numeric fields for the
service pack data.



--
Chuck

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Chris S. <ir0...@gm...>]

On 25 April 2011 17:16, Charles Wilson wrote:
> On 4/25/2011 3:36 PM, Kai Tietz wrote:
>> 2011/4/25 Charles Wilson
>>> 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.
>
> OK, so the check should be (pseudo-code):
>
> #ifndef _WIN64
> if (OS is Win9x, or WinNT4sp4 or earlier)
>        .... do mingwm10.dll fallback stuff
>
>
> I think that becomes:
>
> #ifndef _WIN64
> if (version.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS ||
>    (version.dwPlatformId == VER_PLATFORM_WIN32_NT &&
>     (version.dwMajorVersion < 4 ||  /* NT 3.51 */
>      (version.dwMajorVersion == 4 && /* NT 4 */
>       strcmp (version.szCSDVersion, "Service Pack 5") < 0)))) /* sp4 or
> below */
> {
>   /* add a comment about the fact that this is fallback code, for
>    * older OS's, which uses the legacy mingwm10.dll gobbledygook
>    * instead of TLS, to support thread initialization.
>    */
>
>   ... do mingwm10.dll stuff
> }

So where did we land on this?  Is this needed at all any more (i.e.
does MinGW support versions of Windows less than 2k)?

Chuck's check seems comprehensive, and I'm more than happy to apply
it, just wondering if it's needed at all?

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Charles W. <cwi...@us...>]

On 4/27/2011 7:09 AM, Chris Sutcliffe wrote:
> So where did we land on this?  Is this needed at all any more (i.e.
> does MinGW support versions of Windows less than 2k)?
> 
> Chuck's check seems comprehensive, and I'm more than happy to apply
> it, just wondering if it's needed at all?

I think the upshot of Earnie's 11:37UTC comment today is that we should
try not to deliberately break support for older OSs -- and we're
certainly not going to go thru all of mingwrt/w32api and scrub existing
support for Win9x.

To me, that says the check in tlssup.c is necessary -- since we (a) know
the right thing to do, (b) it isn't hard, and (c) has minimal runtime
impact.  The only thing missing is: testing mingw's threading support on
Win9x -- apparently it's been broken on old OS's ever since the new TLS
mechanism supplanted the old mingwm10.dll mechanism for new OS's, and
nobody noticed.

But, so long as we continue to ship mingwm10.dll, we should keep/fix its
support code in tlssup.c.

--
Chuck

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Earnie <ea...@us...>]

Charles Wilson wrote:
> On 4/27/2011 7:09 AM, Chris Sutcliffe wrote:
>> So where did we land on this?  Is this needed at all any more (i.e.
>> does MinGW support versions of Windows less than 2k)?
>>
>> Chuck's check seems comprehensive, and I'm more than happy to apply
>> it, just wondering if it's needed at all?
> 
> I think the upshot of Earnie's 11:37UTC comment today is that we should
> try not to deliberately break support for older OSs -- and we're
> certainly not going to go thru all of mingwrt/w32api and scrub existing
> support for Win9x.
> 

No, not scrub.

> To me, that says the check in tlssup.c is necessary -- since we (a) know
> the right thing to do, (b) it isn't hard, and (c) has minimal runtime
> impact.  The only thing missing is: testing mingw's threading support on
> Win9x -- apparently it's been broken on old OS's ever since the new TLS
> mechanism supplanted the old mingwm10.dll mechanism for new OS's, and
> nobody noticed.
> 

Or we could simply say threading support for Win9x is not supported and
remove it from tlssup.c.  Even though your 3 points are valid, there is
also something to be said for not supporting something we don't have to.

> But, so long as we continue to ship mingwm10.dll, we should keep/fix its
> support code in tlssup.c.

What is the GCC position on the older Windows OS?  The decision of
whether to include it or not should be based on whether or not the
compiler and linker support it.

-- 
Earnie
-- http://www.for-my-kids.com

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[NightStrike <nig...@gm...>]

On Wed, Apr 27, 2011 at 9:01 AM, Charles Wilson
<cwi...@us...> wrote:
> On 4/27/2011 7:09 AM, Chris Sutcliffe wrote:
>> So where did we land on this?  Is this needed at all any more (i.e.
>> does MinGW support versions of Windows less than 2k)?
>>
>> Chuck's check seems comprehensive, and I'm more than happy to apply
>> it, just wondering if it's needed at all?
>
> I think the upshot of Earnie's 11:37UTC comment today is that we should
> try not to deliberately break support for older OSs -- and we're
> certainly not going to go thru all of mingwrt/w32api and scrub existing
> support for Win9x.
>
> To me, that says the check in tlssup.c is necessary -- since we (a) know
> the right thing to do, (b) it isn't hard, and (c) has minimal runtime
> impact.  The only thing missing is: testing mingw's threading support on
> Win9x -- apparently it's been broken on old OS's ever since the new TLS
> mechanism supplanted the old mingwm10.dll mechanism for new OS's, and
> nobody noticed.
>
> But, so long as we continue to ship mingwm10.dll, we should keep/fix its
> support code in tlssup.c.

Right now, we (mw64) do not support anything older than XP.  That
means that mingw.org is the only place for people to turn for older
OSes.  You might want to consider that, if there are still users out
there that need this support.

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Cesar S. <ces...@gm...>]

On 04/25/2011 04:13 PM, Charles Wilson wrote:

> 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)

I did test it on Windows 95 at the time, and it seemed to work well somehow.

See:
Re: TLS Callback Support
http://article.gmane.org/gmane.comp.gnu.mingw.devel/3627

I didn't even had mingwm10.dll anywhere in sight. This seems to indicate
that TLS callbacks do work on Windows 95.

Could someone come up with a test-case that checks specifically for TLS
functionality? I can test it on my VirtualBox Windows 95 image and clear
all doubts.

Regards,

Cesar

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Charles W. <cwi...@us...>]

On 4/27/2011 11:27 PM, Cesar Strauss wrote:
> I did test it on Windows 95 at the time, and it seemed to work well somehow.
> 
> See:
> Re: TLS Callback Support
> http://article.gmane.org/gmane.comp.gnu.mingw.devel/3627
> 
> I didn't even had mingwm10.dll anywhere in sight. This seems to indicate
> that TLS callbacks do work on Windows 95.
> 
> Could someone come up with a test-case that checks specifically for TLS
> functionality? I can test it on my VirtualBox Windows 95 image and clear
> all doubts.

According to
http://winapi.freetechsecrets.com/win32/WIN32TlsGetValue.htm
(it's on the web, it MUST be true, right?)

TlsGetValue is supported on WinNT+, Win95, and win32s (!!).

So, although this test in tlssup.c:

	if (_winmajor < 4)
		... use mingwm10.dll stuff ..
 	else
		... do real tls things ...

was INTENDED to cause Win9x to use mingwm10.dll, it did not have that
effect.  Instead, only WinNT 3.51 would have used mingwm10.dll, and
Win9x used "real" tls just like the modern windows versions.

And, as you discovered: Win9x has TLS support, so...it worked.

The question NOW is, should we exploit that, and remove the mingwm10.dll
stuff from tlssup.c *entirely* -- or "fix" the conditional and push
win9x back into the mingwm10.dll mold?

I lean toward removing the mingwm10 stuff from tlssup.c completely,
because it appears that any output objects produced by modern mingw gcc
WILL contain tls sections -- so if we find a platform that can't use TLS
and instead requires mingwm10.dll, well, we're broken already, because
we put .tls sections into the binary anyway.

--
Chuck

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Chris S. <ir0...@gm...>]

On 4 May 2011 14:19, Charles Wilson wrote:
> According to
> http://winapi.freetechsecrets.com/win32/WIN32TlsGetValue.htm
> (it's on the web, it MUST be true, right?)
>
> TlsGetValue is supported on WinNT+, Win95, and win32s (!!).
>
> So, although this test in tlssup.c:
>
>        if (_winmajor < 4)
>                ... use mingwm10.dll stuff ..
>        else
>                ... do real tls things ...
>
> was INTENDED to cause Win9x to use mingwm10.dll, it did not have that
> effect.  Instead, only WinNT 3.51 would have used mingwm10.dll, and
> Win9x used "real" tls just like the modern windows versions.
>
> And, as you discovered: Win9x has TLS support, so...it worked.
>
> The question NOW is, should we exploit that, and remove the mingwm10.dll
> stuff from tlssup.c *entirely* -- or "fix" the conditional and push
> win9x back into the mingwm10.dll mold?
>
> I lean toward removing the mingwm10 stuff from tlssup.c completely,
> because it appears that any output objects produced by modern mingw gcc
> WILL contain tls sections -- so if we find a platform that can't use TLS
> and instead requires mingwm10.dll, well, we're broken already, because
> we put .tls sections into the binary anyway.

So are we all in agreement that the mingwm10 stuff should be removed
from tlssup.c?  I'm finally getting around to updating mingwrt with
all the outstanding patches and I'd like to close on this as well.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Re: [Mingw-users] Attn: Kai Tietz [Was: -lmsvcr90 produces undefined run-time reference to _winmajor]

[Charles W. <cwi...@us...>]

On 5/22/2011 8:06 PM, Chris Sutcliffe wrote:
> On 4 May 2011 14:19, Charles Wilson wrote:
>> I lean toward removing the mingwm10 stuff from tlssup.c completely,
>> because it appears that any output objects produced by modern mingw gcc
>> WILL contain tls sections -- so if we find a platform that can't use TLS
>> and instead requires mingwm10.dll, well, we're broken already, because
>> we put .tls sections into the binary anyway.
> 
> So are we all in agreement that the mingwm10 stuff should be removed
> from tlssup.c?  I'm finally getting around to updating mingwrt with
> all the outstanding patches and I'd like to close on this as well.

Yes, go ahead (IMO).  It's possible this change might break building
apps using old gcc-3 + new (and current) libmingw32.a, but if so then we
are already broken for that configuration today, and the fix would
require...building a special libmingw32.a that doesn't include
_CRTALLOC(".tls") directives.

I suspect (a) that it is NOT broken, and old gcc-3 works fine with
today's libmingw32.a, and we can go ahead with the proposed change with
no worries, and (b) if it IS broken, then we should just drop support
for gcc-3 (+java, +ada, which aren't yet avail for gcc-4?) +
libmingw32.a newer than 2010-01-25, which is when tlssup.c was added --
and we can go ahead with the proposed change in this case, too.

Since I think (a) is the most likely, I'm not worried about the bad
parts of (b).

It may be a few days before I can construct the appropriate environment
to test this proposition and figure out whether (a) or (b) applies, so
if someone else were to try it, that'd be nice...

--
Chuck

Re: [Mingw-users] -lmsvcr90 produces undefined run-time reference to _winmajor

[Earnie <ea...@us...>]

Jim Bell wrote:
> 
> I say we cut this loose, or put it in a conditional compile if someone
> wanted to build it for ancient platforms.

We've never supported anything less than Windows 95 anyway and anything
less than Windows XP is questionable to work at this point.

-- 
Earnie
-- http://www.for-my-kids.com