From: Earnie B. <ea...@us...> - 2012-01-01 16:25:36
|
This bug brings up a point that I've been wanting to ask here for a while. Since WINVER=0x0400 has waned to the point of near non-existence should we not begin to default to 0x0500? Those wanting to support older versions can modify it just like those wanting to support newer versions. Earnie ---------- Forwarded message ---------- From: SF/projects/mingw notification list < min...@li...> Date: Sun, Jan 1, 2012 at 11:10 AM Subject: [MinGW-notify] [ mingw-Bugs-3447223 ] compiler not imports function from lib To: "SourceForge.net" <no...@so...> This list is used to send updates of submitted patches, bug reports and file releases. You are discouraged from posting to this list. If you wish to unsubscribe you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify. Bugs item #3447223, was opened at 2011-12-01 08:18 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3447223&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: w32api Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: splitfrog (splitfrog) Assigned to: Nobody/Anonymous (nobody) Summary: compiler not imports function from lib Initial Comment: A compiler not imports a function GetShellWindow(), that located in libuser32.a library (user32.dll) . Compiler writes message: main.cpp: In function 'int WinMain(HINSTANCE, HINSTANCE, LPSTR, int)': main.cpp:10:17: error: 'GetShellWindow' was not declared in this scope Tested on gcc ver. 4.4.0, 4.5.2, 4.6.1-2. Other functions from libuser32.a are imports fine. My info: GCC Version: Using built-in specs. COLLECT_GCC=C:\Program Files\MinGw_gcc.4.6.1-2\bin\gcc.EXE COLLECT_LTO_WRAPPER=c:/program files/mingw_gcc.4.6.1-2/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 -- enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build= mingw32 --prefix=/mingw Thread model: win32 gcc version 4.6.1 (GCC) Binutils Version: GNU ld (GNU Binutils) 2.21.53.20110804 Environment: MS Windows 2003 Enterprise SP2 x86. (Also tested on Windows 7 x86) ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2012-01-01 08:10 Message: This is more likely to be your error, than a MinGW bug. I'm guessing, because I can't read your code example, (unsuitable archive format -- please use tar.gz or zip), that you haven't enabled the necessary level of WINVER support; see the notes in include/windef.h BTW, "foo not defined in this scope" doesn't mean the symbol wasn't imported from the DLL; it means that you either didn't include a necessary header, or you didn't enable appropriate support to expose a conditional declaration in a header you did include. The declaration of GetShellWindow() is provided conditionally when you include windows.h, but it will not be exposed if you neglect to define _WIN32_WINNT >= 0x0500 beforehand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3447223&group_id=2435 ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ MinGW-notify mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-notify -- -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Chris S. <ir0...@gm...> - 2012-01-04 22:38:12
|
On 4 January 2012 14:31, Earnie Boyd <ea...@us...> wrote: > On Sun, Jan 1, 2012 at 11:25 AM, Earnie Boyd <ea...@us...> > wrote: >> >> This bug brings up a point that I've been wanting to ask here for a while. >> Since WINVER=0x0400 has waned to the point of near non-existence should we >> not begin to default to 0x0500? Those wanting to support older versions can >> modify it just like those wanting to support newer versions. > > Any comment? Makes sense to me. I don't believe Microsoft is even support Win2K any more, are they (i.e. we could bump it to 0x0501)? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie B. <ea...@us...> - 2012-01-05 12:44:02
|
On Wed, Jan 4, 2012 at 5:38 PM, Chris Sutcliffe <ir0...@gm...> wrote: > On 4 January 2012 14:31, Earnie Boyd <ea...@us...> wrote: > > On Sun, Jan 1, 2012 at 11:25 AM, Earnie Boyd < > ea...@us...> > > wrote: > >> > >> This bug brings up a point that I've been wanting to ask here for a > while. > >> Since WINVER=0x0400 has waned to the point of near non-existence > should we > >> not begin to default to 0x0500? Those wanting to support older > versions can > >> modify it just like those wanting to support newer versions. > > > > Any comment? > > Makes sense to me. I don't believe Microsoft is even support Win2K > any more, are they (i.e. we could bump it to 0x0501)? > 0x0501 is XP so I'm fine with that. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Charles W. <cwi...@us...> - 2012-01-05 19:00:01
|
On 1/5/2012 7:43 AM, Earnie Boyd wrote: > On Wed, Jan 4, 2012 at 5:38 PM, Chris Sutcliffe wrote: > On 4 January 2012 14:31, Earnie Boyd wrote: > >> This bug brings up a point that I've been wanting to ask here for > a while. > >> Since WINVER=0x0400 has waned to the point of near non-existence > should we > >> not begin to default to 0x0500? Those wanting to support older > versions can > >> modify it just like those wanting to support newer versions. > > > > Any comment? > > Makes sense to me. I don't believe Microsoft is even support Win2K > any more, are they (i.e. we could bump it to 0x0501)? > > > 0x0501 is XP so I'm fine with that. I agree: one, it's time to bump past NT; two, XP is probably the oldest OS we should consider as the default. Once MS stops supporting XP (end of 2012 I think?) we might consider bumping to Vista. But for now, 0x0501 seems to be the right default value. -- Chuck |
From: Chris S. <ir0...@gm...> - 2012-01-05 19:39:47
|
On 5 January 2012 13:59, Charles Wilson wrote: > On 1/5/2012 7:43 AM, Earnie Boyd wrote: >> 0x0501 is XP so I'm fine with that. > > I agree: one, it's time to bump past NT; two, XP is probably the oldest > OS we should consider as the default. Once MS stops supporting XP (end > of 2012 I think?) we might consider bumping to Vista. But for now, > 0x0501 seems to be the right default value. Done. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Charles W. <cwi...@us...> - 2012-01-05 22:43:11
|
On 1/5/2012 9:18 AM, Keith Marshall wrote: > Now, maybe we don't care about the potential fall out from that, but if > we are to make this change, I think we must also post a very prominent > statement regarding its potential consequences to users -- and by very > prominent, I don't mean buried at some obscure location within some > arbitrarily chosen header file, as we have at present. Isn't that what the sourceforge "NEWS" is for? We could also add it to the MinGW README.rtf... -- Chuck |
From: Earnie B. <ea...@us...> - 2012-01-06 13:20:32
|
On Thu, Jan 5, 2012 at 5:42 PM, Charles Wilson < cwi...@us...> wrote: > On 1/5/2012 9:18 AM, Keith Marshall wrote: > > Now, maybe we don't care about the potential fall out from that, but if > > we are to make this change, I think we must also post a very prominent > > statement regarding its potential consequences to users -- and by very > > prominent, I don't mean buried at some obscure location within some > > arbitrarily chosen header file, as we have at present. > > Isn't that what the sourceforge "NEWS" is for? We could also add it to > the MinGW README.rtf... > > Chuck, believing that people read. ;) A FAQ or HOWTO "Support Different Windows OS Versions" would be good as well as NEWS , README and list notification. But why not add a #warning if WINVER isn't defined by the user? Yes, it causes -Werror to abort compilation but it also forces the developer of the code to think. -DWINVER=0x0501 would resolve the abort as well as a #define in the config.h or some other header. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Charles W. <cwi...@us...> - 2012-01-06 16:51:30
|
On 1/6/2012 8:20 AM, Earnie Boyd wrote: > On Thu, Jan 5, 2012 at 5:42 PM, <xxx@yyy.zzz> Charles Wilson wrote: Earnie, fix your mailer; don't quote email addresses. > Isn't that what the sourceforge "NEWS" is for? We could also add it to > the MinGW README.rtf... > > > Chuck, believing that people read. ;) Yeah, you're right. Since one of the various sf redesigns, news items no longer automatically appear on the sf summary page. http://sourceforge.net/projects/mingw/ Now, we're treated instead to the most recent half dozen "user reviews" instead. Wow, that's SO much more important than, say, the NEWS that the project devs actually want to announce. You have to go to the Develop->News pulldown menu... > A FAQ or HOWTO "Support Different Windows OS Versions" would be good as > well as NEWS , README and list notification. But why not add a #warning > if WINVER isn't defined by the user? Oh, please no. Does Visual Studio issue such warnings? No...and VS users DO care about whether their code will run only on W7 or can support Vista/XP/2k/NT/... This is just part of careful programming on the windows platform. If you care about compat, you should #define WINVER; otherwise, a suitable default will be used. Windows SDK v7.0a does this in WinDef.h: #ifndef WINVER #define WINVER 0x0500 #endif /* WINVER */ which argues that we should use a similar default (0x0500) rather than 0x0501. And that our headers should just define it too, rather than adding #warning pragmas or similar. -- Chuck |
From: Earnie B. <ea...@us...> - 2012-01-06 17:59:30
|
On Fri, Jan 6, 2012 at 11:50 AM, Charles Wilson wrote: > > > A FAQ or HOWTO "Support Different Windows OS Versions" would be good as > > well as NEWS , README and list notification. But why not add a #warning > > if WINVER isn't defined by the user? > > Oh, please no. Does Visual Studio issue such warnings? No...and VS users > DO care about whether their code will run only on W7 or can support > Vista/XP/2k/NT/... This is just part of careful programming on the > windows platform. If you care about compat, you should #define WINVER; > otherwise, a suitable default will be used. > > > Windows SDK v7.0a does this in WinDef.h: > > #ifndef WINVER > #define WINVER 0x0500 > #endif /* WINVER */ > > which argues that we should use a similar default (0x0500) rather than > 0x0501. And that our headers should just define it too, rather than > adding #warning pragmas or similar. > > I'll agree with that. I'm surprised though, WINVER 0x0500 also includes the ME version of OS which is sorely broken. I guess there are enough users of Windows 2000 server edition to warrant the possibility. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie B. <ea...@us...> - 2012-01-16 14:27:49
|
On Fri, Jan 6, 2012 at 12:59 PM, Earnie Boyd wrote: > On Fri, Jan 6, 2012 at 11:50 AM, Charles Wilson wrote: > >> >> > A FAQ or HOWTO "Support Different Windows OS Versions" would be good as >> > well as NEWS , README and list notification. But why not add a #warning >> > if WINVER isn't defined by the user? >> >> Oh, please no. Does Visual Studio issue such warnings? No...and VS users >> DO care about whether their code will run only on W7 or can support >> Vista/XP/2k/NT/... This is just part of careful programming on the >> windows platform. If you care about compat, you should #define WINVER; >> otherwise, a suitable default will be used. >> >> >> Windows SDK v7.0a does this in WinDef.h: >> >> #ifndef WINVER >> #define WINVER 0x0500 >> #endif /* WINVER */ >> >> which argues that we should use a similar default (0x0500) rather than >> 0x0501. And that our headers should just define it too, rather than >> adding #warning pragmas or similar. >> > > I'll agree with that. I'm surprised though, WINVER 0x0500 also includes the > ME version of OS which is sorely broken. I guess there are enough users of > Windows 2000 server edition to warrant the possibility. Keith touted at https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3473975&group_id=2435 : > The correct definition of WINVER has NOTHING WHATSOEVER to do with the > version of windows you might be running the compiler on -- I'm guessing > Windows-7 in your case. But maybe that is exactly what we need if WINVER isn't set? But that may be too confusing. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-01-16 15:01:21
|
On 16 January 2012 14:27, Earnie Boyd wrote: > Keith touted at > https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3473975&group_id=2435 > : > >> The correct definition of WINVER has NOTHING WHATSOEVER to do with the >> version of windows you might be running the compiler on -- I'm guessing >> Windows-7 in your case. > > But maybe that is exactly what we need if WINVER isn't set? But that > may be too confusing. You mean, let GCC choose? That would be contrary to MSDN documentation: http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx It would probably also be rather dangerous: Fred builds on Win7, and unthinkingly refers to a Win7 specific API. His code builds fine; he gets no notification of any potential problem. He then gives a copy of his .exe to Barney, who is still on WinXP; BOOM! It will not run. Barney is not a happy bunny; likely Fred isn't either. WINVER (and _WIN32_WINNT) aren't about the properties of the $build platform; they are about the earliest $host version you want to support. Developers need to learn to set them appropriately, if the default isn't what they want. That's how it is with MSVC; it's how it is for us too, and I don't think it prudent for us to change this. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-01-04 19:31:24
|
On Sun, Jan 1, 2012 at 11:25 AM, Earnie Boyd <ea...@us...>wrote: > This bug brings up a point that I've been wanting to ask here for a while. > Since WINVER=0x0400 has waned to the point of near non-existence should we > not begin to default to 0x0500? Those wanting to support older versions > can modify it just like those wanting to support newer versions. > > Any comment? -- -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Teemu N. <sti...@ya...> - 2012-01-04 20:56:50
|
On 4.1.2012 21:31, Earnie Boyd wrote: > On Sun, Jan 1, 2012 at 11:25 AM, Earnie Boyd > <ea...@us... <mailto:ea...@us...>> wrote: > > This bug brings up a point that I've been wanting to ask here for a > while. Since WINVER=0x0400 has waned to the point of near > non-existence should we not begin to default to 0x0500? Those > wanting to support older versions can modify it just like those > wanting to support newer versions. > > > Any comment? The change would make life easier. Teemu |
From: Keith M. <kei...@us...> - 2012-01-05 20:23:10
|
On 04/01/12 19:31, Earnie Boyd wrote: > On Sun, Jan 1, 2012 at 11:25 AM, Earnie Boyd wrote: >> This bug brings up a point that I've been wanting to ask here for a while. >> Since WINVER=0x0400 has waned to the point of near non-existence should we >> not begin to default to 0x0500? Those wanting to support older versions >> can modify it just like those wanting to support newer versions. > > Any comment? I have just one reservation: if we do this, then most users will blindly leave WINVER at 0x0500, (or 0x0501, or whatever other value we may assign), without giving any thought to the implications. Even if they did then hope to distribute their applications with continuing support for Win9x, they would get no warning if they were to include any accidental reference to an API requiring a later version. Now, maybe we don't care about the potential fall out from that, but if we are to make this change, I think we must also post a very prominent statement regarding its potential consequences to users -- and by very prominent, I don't mean buried at some obscure location within some arbitrarily chosen header file, as we have at present. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2012-01-05 21:47:08
|
On 5 January 2012 09:18, Keith Marshall wrote: > I have just one reservation: if we do this, then most users will > blindly leave WINVER at 0x0500, (or 0x0501, or whatever other value we > may assign), without giving any thought to the implications. Even if > they did then hope to distribute their applications with continuing > support for Win9x, they would get no warning if they were to include any > accidental reference to an API requiring a later version. Personally, I believe most software gave up on Win9x support some time ago, but point taken. > Now, maybe we don't care about the potential fall out from that, but if > we are to make this change, I think we must also post a very prominent > statement regarding its potential consequences to users -- and by very > prominent, I don't mean buried at some obscure location within some > arbitrarily chosen header file, as we have at present. I've got no problem with this in general, but I'm curious as to what you propose regarding making a prominent statement. I would not be comfortable issuing a statement via the #warning macro, as this will break any compilation that makes use of -Werror. It can be made (and will be made) in the announcement, but it may not hit home to some developers (or may be ignored completely). Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |