[winapi] Default target Windows version
Hi, First, a little intro. As part of ongoing work on Boost.Sync we've created quite a few headers with WinAPI declarations that are often needed in Boost libraries. The headers are in boost/detail/winapi and can be used by any library that wishes to avoid including windows.h. The headers declare some symbols that depend on the target Windows version. For example, GetTickCount64 only appeared in Windows Vista. The user can define BOOST_USE_WINAPI_VERSION macro before including any Boost headers to indicate the target WinAPI version Boost should use. If the macro is not defined, the headers attempt to deduce the target Windows version from the _WIN32_WINNT and WINVER macros, if they are defined by the user. Lastly, if everything fails, the headers fall back to a default, which is currently Windows XP. I wanted to ask the community if it is appropriate to raise the default to Windows Vista. The rationale for this is that Vista introduced a lot of useful APIs (in thread synchronization, in particular) and XP is losing its popularity and soon will be completely unsupported by Microsoft. Also, I'm not sure what is the current state of affair, but Microsoft already tried to drop pre-Vista targets in MSVC. Note that I'm not suggesting to drop support for pre-Vista Windows. The user will still be able to enable previous versions of WinAPI in one of the mentioned above ways. Lastly, I'd like to encourage Boost developers to use this protocol for defining WinAPI version used by libraries. It would be ideal if by defining BOOST_USE_WINAPI_VERSION the user would be able to control WinAPI version used by all Boost libraries, not just Boost.Sync and Boost.Chrono (the current users of these headers). If you want to add support for this protocol to your library, simply include boost/detail/winapi/config.hpp. This will result in BOOST_USE_WINAPI_VERSION being defined so that it can be checked by the library. Other headers boost/detail/winapi make use of this macro, you can see them as an example.
On 15-10-2013 22:50, Andrey Semashev wrote:
I wanted to ask the community if it is appropriate to raise the default to Windows Vista. The rationale for this is that Vista introduced a lot of useful APIs (in thread synchronization, in particular) and XP is losing its popularity and soon will be completely unsupported by Microsoft. Also, I'm not sure what is the current state of affair, but Microsoft already tried to drop pre-Vista targets in MSVC.
That kinda backfired and VC 2012 and 2013 have an option to compile XP-compatible binaries. What's the concrete advantage of defaulting to Vista? Performance? Olaf
On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
What's the concrete advantage of defaulting to Vista? Performance?
Yes, mostly. Vista has builtin support for condition variables and read/write mutexes, for example. Compiler-based TLS can be used safely with dlls. GetTickCount64 can also be useful in some contexts and is difficult to emulate. All these features will find their use at least in Boost.Sync and Boost.Log (the latter currently uses its own protocol for enabling use of these APIs, but it will be ported eventually).
On Wed, Oct 16, 2013 at 02:20:36AM +0400, Andrey Semashev wrote:
On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
What's the concrete advantage of defaulting to Vista? Performance?
Yes, mostly. Vista has builtin support for condition variables and read/write mutexes, for example. Compiler-based TLS can be used safely with dlls. GetTickCount64 can also be useful in some contexts and is difficult to emulate. All these features will find their use at least in Boost.Sync and Boost.Log (the latter currently uses its own protocol for enabling use of these APIs, but it will be ported eventually).
Some of the things I really look forward to when I personally can drop XP support is the Slim Reader/Writer (SRW) Locks [1], the ability to specify relative RPATHs in manifests, SHGetKnownFolderPath (actually handles paths longer than MAX_PATH) [3]. There are a lot of neat stuff all over the API which is gated by being introduced post-XP. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).as... [2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762188(v=vs.85).as... -- Lars Viklund | zao@acc.umu.se
On 16-10-2013 0:20, Andrey Semashev wrote:
On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
What's the concrete advantage of defaulting to Vista? Performance?
Yes, mostly. Vista has builtin support for condition variables and read/write mutexes, for example. Compiler-based TLS can be used safely with dlls. GetTickCount64 can also be useful in some contexts and is difficult to emulate. All these features will find their use at least in Boost.Sync and Boost.Log (the latter currently uses its own protocol for enabling use of these APIs, but it will be ported eventually).
If a program targets >= Vista, aren't defines available you could check anyway? Then there'd be no need to raise the default to Vista or to introduce a Boost WINAPI define. Olaf
On Wednesday 16 October 2013 12:05:51 Olaf van der Spek wrote:
On 16-10-2013 0:20, Andrey Semashev wrote:
On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
What's the concrete advantage of defaulting to Vista? Performance?
Yes, mostly. Vista has builtin support for condition variables and read/write mutexes, for example. Compiler-based TLS can be used safely with dlls. GetTickCount64 can also be useful in some contexts and is difficult to emulate. All these features will find their use at least in Boost.Sync and Boost.Log (the latter currently uses its own protocol for enabling use of these APIs, but it will be ported eventually).
If a program targets >= Vista, aren't defines available you could check anyway?
Not necessarily. For example, the macros are typically not defined when building Boost itself. Also, if a program relies on Boost to provide abstraction over the OS API, it may well omit defining those macros too.
On 16-10-2013 12:13, Andrey Semashev wrote:
On Wednesday 16 October 2013 12:05:51 Olaf van der Spek wrote:
On 16-10-2013 0:20, Andrey Semashev wrote:
On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
What's the concrete advantage of defaulting to Vista? Performance?
Yes, mostly. Vista has builtin support for condition variables and read/write mutexes, for example. Compiler-based TLS can be used safely with dlls. GetTickCount64 can also be useful in some contexts and is difficult to emulate. All these features will find their use at least in Boost.Sync and Boost.Log (the latter currently uses its own protocol for enabling use of these APIs, but it will be ported eventually).
If a program targets >= Vista, aren't defines available you could check anyway?
Not necessarily. For example, the macros are typically not defined when building Boost itself.
Right. Would this create a new set of library variants and allow me to build both the XP and Vista variants? Some programs might need the XP variants while others might need the Vista ones.
Also, if a program relies on Boost to provide abstraction over the OS API, it may well omit defining those macros too.
True, but then these programs might as well just define the official defines instead of the Boost one. Olaf
On Wednesday 16 October 2013 13:20:10 Olaf van der Spek wrote:
On 16-10-2013 12:13, Andrey Semashev wrote:
On Wednesday 16 October 2013 12:05:51 Olaf van der Spek wrote:
On 16-10-2013 0:20, Andrey Semashev wrote:
On Tuesday 15 October 2013 23:05:45 Olaf van der Spek wrote:
What's the concrete advantage of defaulting to Vista? Performance?
Yes, mostly. Vista has builtin support for condition variables and read/write mutexes, for example. Compiler-based TLS can be used safely with dlls. GetTickCount64 can also be useful in some contexts and is difficult to emulate. All these features will find their use at least in Boost.Sync and Boost.Log (the latter currently uses its own protocol for enabling use of these APIs, but it will be ported eventually).
If a program targets >= Vista, aren't defines available you could check anyway?
Not necessarily. For example, the macros are typically not defined when building Boost itself.
Right. Would this create a new set of library variants and allow me to build both the XP and Vista variants? Some programs might need the XP variants while others might need the Vista ones.
I wasn't planning modifications to Boost.Build, if that's what you mean. But in my libraries I use inline namespaces, which names depend on the selected WinAPI version. This warrants against ABI incompatibilities. Modifying Boost.Build to reflect the selected API in the built file names might be reasonable, but it's too difficult for me right now.
Also, if a program relies on Boost to provide
abstraction over the OS API, it may well omit defining those macros too.
True, but then these programs might as well just define the official defines instead of the Boost one.
The question is what to do when nothing is defined. You have to choose some default. And regarding the official macros, there are at least two of them in wide use (_WIN32_WINNT and WINVER) and quite a few more controlling versions of other parts of Windows SDK. It is much easier to use just one. Also, it would be theoretically possible to constrain Boost to use some specific API version, while the rest of the application uses another (probably, newer) version.
On Wednesday 16 October 2013 00:50:21 you wrote:
Hi,
First, a little intro. As part of ongoing work on Boost.Sync we've created quite a few headers with WinAPI declarations that are often needed in Boost libraries. The headers are in boost/detail/winapi and can be used by any library that wishes to avoid including windows.h.
The headers declare some symbols that depend on the target Windows version. For example, GetTickCount64 only appeared in Windows Vista. The user can define BOOST_USE_WINAPI_VERSION macro before including any Boost headers to indicate the target WinAPI version Boost should use. If the macro is not defined, the headers attempt to deduce the target Windows version from the _WIN32_WINNT and WINVER macros, if they are defined by the user. Lastly, if everything fails, the headers fall back to a default, which is currently Windows XP.
I wanted to ask the community if it is appropriate to raise the default to Windows Vista. The rationale for this is that Vista introduced a lot of useful APIs (in thread synchronization, in particular) and XP is losing its popularity and soon will be completely unsupported by Microsoft. Also, I'm not sure what is the current state of affair, but Microsoft already tried to drop pre-Vista targets in MSVC.
Note that I'm not suggesting to drop support for pre-Vista Windows. The user will still be able to enable previous versions of WinAPI in one of the mentioned above ways.
Lastly, I'd like to encourage Boost developers to use this protocol for defining WinAPI version used by libraries. It would be ideal if by defining BOOST_USE_WINAPI_VERSION the user would be able to control WinAPI version used by all Boost libraries, not just Boost.Sync and Boost.Chrono (the current users of these headers). If you want to add support for this protocol to your library, simply include boost/detail/winapi/config.hpp. This will result in BOOST_USE_WINAPI_VERSION being defined so that it can be checked by the library. Other headers boost/detail/winapi make use of this macro, you can see them as an example.
Since there were no objections, I've changed the default to Vista. Please, let me know if there are problems with it.
On 22.10.2013 17:30, Andrey Semashev wrote:
Since there were no objections, I've changed the default to Vista. Please, let me know if there are problems with it. I think it's not a good idea to change the default before 08.04.2014 (WinXP Professional Extended Support End Date) or even 14.07.2015 (Windows Server 2003 R2 Extended Support End Date).
According to the NetApplications (http://www.netmarketshare.com), WinXP is currently used by 31% of the desktop internet users. Btw, how can I override this default value? -- Sergey Cheban
On Tue, Oct 22, 2013 at 7:15 PM, Sergey Cheban
On 22.10.2013 17:30, Andrey Semashev wrote:
Since there were no objections, I've changed the default to Vista. Please, let me know if there are problems with it.
I think it's not a good idea to change the default before 08.04.2014 (WinXP Professional Extended Support End Date) or even 14.07.2015 (Windows Server 2003 R2 Extended Support End Date).
According to the NetApplications (http://www.netmarketshare.com), WinXP is currently used by 31% of the desktop internet users.
XP is still quite widely used, but its popularity is declining and many new applications don't target it anymore. Don't you think that the ability to enable its support explicitly, if needed, is enough?
Btw, how can I override this default value?
As it was described in the initial post: define BOOST_USE_WINAPI_VERSION, _WIN32_WINNT or WINVER to the version you need.
On 22.10.2013 19:36, Andrey Semashev wrote:
I think it's not a good idea to change the default before 08.04.2014 (WinXP Professional Extended Support End Date) or even 14.07.2015 (Windows Server 2003 R2 Extended Support End Date). According to the NetApplications (http://www.netmarketshare.com), WinXP is currently used by 31% of the desktop internet users. XP is still quite widely used, but its popularity is declining and many new applications don't target it anymore. Really?
Don't you think that the ability to enable its support explicitly, if needed, is enough? It's appropriate but not so convenient for me.
Btw, how can I override this default value? As it was described in the initial post: define BOOST_USE_WINAPI_VERSION, _WIN32_WINNT or WINVER to the version you need. What exactly do I need to add to the command line of the regression tests to check the non-default configuration? Something like --bjam-options="define=_WIN32_WINNT=0x0501"?
-- Sergey Cheban
On Tue, Oct 22, 2013 at 9:00 PM, Sergey Cheban
On 22.10.2013 19:36, Andrey Semashev wrote:
I think it's not a good idea to change the default before 08.04.2014 (WinXP Professional Extended Support End Date) or even 14.07.2015 (Windows Server 2003 R2 Extended Support End Date). According to the NetApplications (http://www.netmarketshare.com), WinXP is currently used by 31% of the desktop internet users.
XP is still quite widely used, but its popularity is declining and many new applications don't target it anymore.
Really?
Well, to my knowledge latest Visual Studio and MS Office don't support XP (as the hosting OS). As well as recent games and some other applications I happen to interact with. And the site you referred to shows the decline. Also note that the change is made to trunk and at best will be released with 1.56 (i.e. sometime next year).
Btw, how can I override this default value?
As it was described in the initial post: define BOOST_USE_WINAPI_VERSION, _WIN32_WINNT or WINVER to the version you need.
What exactly do I need to add to the command line of the regression tests to check the non-default configuration? Something like --bjam-options="define=_WIN32_WINNT=0x0501"?
I'm not familiar with the testing scripts but yes, "define=_WIN32_WINNT=0x0501" would be the option for bjam.
On 22.10.2013 21:41, Andrey Semashev wrote:
XP is still quite widely used, but its popularity is declining and many new applications don't target it anymore. Really? Well, to my knowledge latest Visual Studio and MS Office don't support XP (as the hosting OS). It's Microsoft's business. The latest Visual Studio requires Windows 8.1 if you want to compile the WinRT application.
As well as recent games Many new games require modern computers anyway. For owners of these computers, dropping the WinXP support is not a problem because they usually use Win7+.
and some other applications I happen to interact with. And the site you referred to shows the decline. There any many users of Windows XP. For them, the Windows XP Lifecycle ends at 08 Apr 2014. I see no reason to introduce any problems with WinXP compatibility before this date. On the other hand, I see no reasons to keep WinXP supported by default after it's official death.
-- Sergey Cheban
On Wednesday 23 October 2013 16:35:33 Sergey Cheban wrote:
There any many users of Windows XP. For them, the Windows XP Lifecycle ends at 08 Apr 2014. I see no reason to introduce any problems with WinXP compatibility before this date. On the other hand, I see no reasons to keep WinXP supported by default after it's official death.
Ok, sounds reasonable. I changed the default back to XP.
Le 23/10/13 15:12, Andrey Semashev a écrit :
On Wednesday 23 October 2013 16:35:33 Sergey Cheban wrote:
There any many users of Windows XP. For them, the Windows XP Lifecycle ends at 08 Apr 2014. I see no reason to introduce any problems with WinXP compatibility before this date. On the other hand, I see no reasons to keep WinXP supported by default after it's official death. Ok, sounds reasonable. I changed the default back to XP.
Hi Andrey, I was wondering if we don't need here a different toolset on bjam so that we can deliver both the XP and the Vista libraries. Apologies if I missed some important parts of the thread. Best, Vicente
On Friday 25 October 2013 22:54:52 Vicente J. Botet Escriba wrote:
Le 23/10/13 15:12, Andrey Semashev a écrit :
On Wednesday 23 October 2013 16:35:33 Sergey Cheban wrote:
There any many users of Windows XP. For them, the Windows XP Lifecycle ends at 08 Apr 2014. I see no reason to introduce any problems with WinXP compatibility before this date. On the other hand, I see no reasons to keep WinXP supported by default after it's official death.
Ok, sounds reasonable. I changed the default back to XP.
Hi Andrey,
I was wondering if we don't need here a different toolset on bjam so that we can deliver both the XP and the Vista libraries.
Apologies if I missed some important parts of the thread.
Yes, that idea was mentioned, although I don't think the whole new toolset is required. I agree this would be a useful feature, but I don't plan doing this. At least, not in the near future. Boost.Build is just too complicated for me to do this easily. I wonder what you think about this idea: http://article.gmane.org/gmane.comp.lib.boost.devel/245407 I'm considering changing to this approach in trunk.
On Fri, Oct 25, 2013 at 10:54:52PM +0200, Vicente J. Botet Escriba wrote:
Le 23/10/13 15:12, Andrey Semashev a écrit :
On Wednesday 23 October 2013 16:35:33 Sergey Cheban wrote:
There any many users of Windows XP. For them, the Windows XP Lifecycle ends at 08 Apr 2014. I see no reason to introduce any problems with WinXP compatibility before this date. On the other hand, I see no reasons to keep WinXP supported by default after it's official death. Ok, sounds reasonable. I changed the default back to XP.
Hi Andrey,
I was wondering if we don't need here a different toolset on bjam so that we can deliver both the XP and the Vista libraries.
Apologies if I missed some important parts of the thread.
The last time I tried raising the problem of toolsets (back in v110_xp) I was pretty much laughed out of the room for being silly enough to run Windows, and to think that it was worth targetting XP. In any way, I've settled personally for largely following the instructions in [1], apart from the extraneous ;%CL% on the CL and LINK variables. The following steps works for v110_xp and v120_xp. * Open your usual Visual Studio command prompt. * Set INCLUDE, PATH, LIB, CL, LINK. * Clean out your build tree completely. * Build+install/stage w/ toolset=msvc-11.0 or msvc-12.0. * Pray it/Boost didn't screw something up and end up as crashes/failure-to-launch on XP machines. You may have to use SUBSYSTEM:WINDOWS instead of SUBSYSTEM:CONSOLE, I don't know if it should matter for DLLs. [1] http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx [2] ---8<--- set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% set CL=/D_USING_V110_SDK71_ When targeting x64, set the lib path as follows: set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% Specify the correct subsystem and subsystem version for the linker based on the type of application you are building. Applications targeting the x86 version of Windows XP must specify subsystem version 5.01, and applications targeting x64 must specify version 5.02. For x86 console applications: set LINK=/SUBSYSTEM:CONSOLE,5.01 For x64 console applications: set LINK=/SUBSYSTEM:CONSOLE,5.02 ---8<--- -- Lars Viklund | zao@acc.umu.se
On 26 Oct 2013 at 2:14, Lars Viklund wrote:
The following steps works for v110_xp and v120_xp.
* Open your usual Visual Studio command prompt. * Set INCLUDE, PATH, LIB, CL, LINK. * Clean out your build tree completely. * Build+install/stage w/ toolset=msvc-11.0 or msvc-12.0. * Pray it/Boost didn't screw something up and end up as crashes/failure-to-launch on XP machines.
I am surprised that this works. Boost.Build appears to ignore the command line environment you launch it within, and so always chooses the default toolset for msvc-12.0, therefore producing binaries which ought to fail to launch on XP. BTW, if you statically link your VS2012 executable as a DLL, and then use a loader shim on XP to load that DLL and call its entry point, you generally get away with it working just fine. In the end the VS2012 MSVCRT doesn't use that many Vista only kernel APIs yet. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Sat, Oct 26, 2013 at 03:17:10PM -0400, Niall Douglas wrote: Content-Description: Mail message body
On 26 Oct 2013 at 2:14, Lars Viklund wrote:
The following steps works for v110_xp and v120_xp.
* Open your usual Visual Studio command prompt. * Set INCLUDE, PATH, LIB, CL, LINK. * Clean out your build tree completely. * Build+install/stage w/ toolset=msvc-11.0 or msvc-12.0. * Pray it/Boost didn't screw something up and end up as crashes/failure-to-launch on XP machines.
I am surprised that this works. Boost.Build appears to ignore the command line environment you launch it within, and so always chooses the default toolset for msvc-12.0, therefore producing binaries which ought to fail to launch on XP.
BTW, if you statically link your VS2012 executable as a DLL, and then use a loader shim on XP to load that DLL and call its entry point, you generally get away with it working just fine. In the end the VS2012 MSVCRT doesn't use that many Vista only kernel APIs yet.
It might be quite possible that some of it is completely ineffective, but the end result is that I can deploy software linked against static Boost libraries to XP. I believe some of those environment variables are honored by the tools internally (INCLUDE/LIB/LINK/CL). In any way, it "works" for some particular definition of "works". My DLLs end up with the right subsystem version, for example. -- Lars Viklund | zao@acc.umu.se
It might be quite possible that some of it is completely ineffective, but the end result is that I can deploy software linked against static Boost libraries to XP. That's because static libraries do not contain CRT and because they currently do not use _WIN32_WINNT. If they did, you would probably have
27.10.2013 1:06, Lars Viklund пишет: libraries compatible only with windows 8.
I believe some of those environment variables are honored by the tools internally (INCLUDE/LIB/LINK/CL).
In any way, it "works" for some particular definition of "works". My DLLs end up with the right subsystem version, for example. Do you use boost.build to make your DLLs?
-- Best regards, Sergey Cheban
On Sun, Oct 27, 2013 at 01:34:03AM +0400, Sergey Cheban wrote:
27.10.2013 1:06, Lars Viklund пишет:
It might be quite possible that some of it is completely ineffective, but the end result is that I can deploy software linked against static Boost libraries to XP. That's because static libraries do not contain CRT and because they currently do not use _WIN32_WINNT. If they did, you would probably have libraries compatible only with windows 8.
I believe some of those environment variables are honored by the tools internally (INCLUDE/LIB/LINK/CL).
In any way, it "works" for some particular definition of "works". My DLLs end up with the right subsystem version, for example. Do you use boost.build to make your DLLs?
It seems like the core of my message didn't get through. _If_ I do not do this, the resulting libraries will cause my application to not load. Whatever I use to build my own code (CMake, -T v120_xp) is irrelephant. -- Lars Viklund | zao@acc.umu.se
Sergey Cheban wrote:
On 22.10.2013 19:36, Andrey Semashev wrote:
XP is still quite widely used, but its popularity is declining and many new applications don't target it anymore.
Really?
A somewhat reasonable compromise would be to only default to Vista for VC++ versions targeting Vista by default (VS2010, or was that VS2012?), and to XP for previous releases. If someone is still on VS2005 (say), he probably doesn't want to only run on Vista.
On 23.10.2013 0:56, Peter Dimov wrote:
> A somewhat reasonable compromise would be to only default to Vista for VC++
> versions targeting Vista by default (VS2010, or was that VS2012?), and to XP for
> previous releases. If someone is still on VS2005 (say), he probably doesn't want
> to only run on Vista.
1. It is also possible to support the MsBuild toolsets (i.e. v120, v120_xp or
Windows7.1SDK). Unfortunately, toolsets mean something different for the boost
build system.
In the tools/build/v2/tools/msvc.jam I see only the following:
# Known toolset versions, in order of preference.
.known-versions = 12.0 11.0 10.0 10.0express 9.0 9.0express 8.0 8.0express 7.1
7.1toolkit 7.0 6.0 ;
2. Please note that there is also the Windows Runtime API. To use it, one has to
define WINAPI_FAMILY=WINAPI_FAMILY_APP (by default, windows.h defines
WINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP).
--
Sergey Cheban
On Wednesday 23 October 2013 15:35:39 Sergey Cheban wrote:
On 23.10.2013 0:56, Peter Dimov wrote:
A somewhat reasonable compromise would be to only default to Vista for VC++ versions targeting Vista by default (VS2010, or was that VS2012?), and to XP for previous releases. If someone is still on VS2005 (say), he probably doesn't want to only run on Vista.
1. It is also possible to support the MsBuild toolsets (i.e. v120, v120_xp or Windows7.1SDK). Unfortunately, toolsets mean something different for the boost build system. In the tools/build/v2/tools/msvc.jam I see only the following: # Known toolset versions, in order of preference. .known-versions = 12.0 11.0 10.0 10.0express 9.0 9.0express 8.0 8.0express 7.1 7.1toolkit 7.0 6.0 ;
2. Please note that there is also the Windows Runtime API. To use it, one has to define WINAPI_FAMILY=WINAPI_FAMILY_APP (by default, windows.h defines WINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP).
I don't think that the compiler or toolset used to build the application should determine the target platform, unless the particular toolset is not able to target the particular platform. Versions of the target OS and the toolset are not related in general. I mean, I can use whatever version of GCC or Intel compiler to build for any Windows, so why should MSVC be different?
On 23.10.2013 17:21, Andrey Semashev wrote: > I don't think that the compiler or toolset used to build the application > should determine the target platform, unless the particular toolset is not > able to target the particular platform. Versions of the target OS and the > toolset are not related in general. I mean, I can use whatever version of GCC > or Intel compiler to build for any Windows, so why should MSVC be different? In the msbuild world, the toolset is not just a compiler. The msbuild toolsets consist of: - the specific version of the compiler(s) - the specific version of the Windows SDK - the specific versions of the CRT, ATL and MFC The toolset does not completely determine the target platform. You can compile for different platforms (x86/x64, Win32/WinRT) with the same vc12 toolset. But if you need the WinXP support, you have to use the xp compatible version of the CRT. So, you need the vc12_xp toolset. -- Sergey Cheban
On Wednesday 23 October 2013 18:47:11 Sergey Cheban wrote: > On 23.10.2013 17:21, Andrey Semashev wrote: > > I don't think that the compiler or toolset used to build the application > > should determine the target platform, unless the particular toolset is not > > able to target the particular platform. Versions of the target OS and the > > toolset are not related in general. I mean, I can use whatever version of > > GCC or Intel compiler to build for any Windows, so why should MSVC be > > different? > In the msbuild world, the toolset is not just a compiler. The msbuild > toolsets consist of: > - the specific version of the compiler(s) > - the specific version of the Windows SDK > - the specific versions of the CRT, ATL and MFC > > The toolset does not completely determine the target platform. You can > compile for different platforms (x86/x64, Win32/WinRT) with the same vc12 > toolset. But if you need the WinXP support, you have to use the xp > compatible version of the CRT. So, you need the vc12_xp toolset. Yes, that's what I meant. To put it another way, when vc12_xp is used, you cannot tell what OS is targeted - XP, Vista, 7, 8 or 8.1. vc12 only narrows the list, excluding XP. So, if I understand correctly, when you use a toolset you have to define the WinAPI version macro anyway, right? Or maybe just using the toolset defines it somehow? In that case, no specific support for toolset detection is required from Boost - we can just deduce the WinAPI version like we currently do.
On 23.10.2013 19:14, Andrey Semashev wrote:
The toolset does not completely determine the target platform. You can compile for different platforms (x86/x64, Win32/WinRT) with the same vc12 toolset. But if you need the WinXP support, you have to use the xp compatible version of the CRT. So, you need the vc12_xp toolset.
Yes, that's what I meant. To put it another way, when vc12_xp is used, you cannot tell what OS is targeted - XP, Vista, 7, 8 or 8.1. vc12 only narrows the list, excluding XP.
So, if I understand correctly, when you use a toolset you have to define the WinAPI version macro anyway, right? Yes. But, on the other hand, we can safely set the default target to the lowest target that is supported by the toolset.
Unfortunately, I see no easy way to support the _xp toolsets. As I understand, the boost build uses vcvarsall.bat to set the INCLUDE and LIB variables, and vcvarsall.bat doesn't support WinXP.
Or maybe just using the toolset defines it somehow? In that case, no specific support for toolset detection is required from Boost - we can just deduce the WinAPI version like we currently do. As I see, Windows XP is not a default target platform even for the _xp toolsets. The _xp toolsets use the Windows SDK 7.1, and the default target for this SDK is Windows 7.
-- Sergey Cheban
On 10/23/2013 10:47 AM, Sergey Cheban wrote: > On 23.10.2013 17:21, Andrey Semashev wrote: > >> I don't think that the compiler or toolset used to build the application >> should determine the target platform, unless the particular toolset is >> not >> able to target the particular platform. Versions of the target OS and the >> toolset are not related in general. I mean, I can use whatever version >> of GCC >> or Intel compiler to build for any Windows, so why should MSVC be >> different? > In the msbuild world, the toolset is not just a compiler. The msbuild > toolsets consist of: > - the specific version of the compiler(s) > - the specific version of the Windows SDK > - the specific versions of the CRT, ATL and MFC A specific version of VC++ determines the CRT, ATL, MFC, and the Windows SDK being used. The Windows SDK being used allows you to target an OS via the _WIN32_WINNT macro. > > The toolset does not completely determine the target platform. You can > compile for different platforms (x86/x64, Win32/WinRT) with the same > vc12 toolset. But if you need the WinXP support, you have to use the xp > compatible version of the CRT. So, you need the vc12_xp toolset. All that the VC++12 xp build does is allow your program to run under Windows XP. Without that configuration your program will fail if running under Windows XP. It may also set the _WIN32_WINNT macro automatically. You should try it out to see if it does.
24.10.2013 0:12, Edward Diener пишет:
All that the VC++12 xp build does is allow your program to run under Windows XP. Without that configuration your program will fail if running under Windows XP. It may also set the _WIN32_WINNT macro automatically. You should try it out to see if it does. Windows SDK 7.1A:
#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_) #define _WIN32_WINNT 0x0601 #endif -- Best regards, Sergey Cheban
On Thursday 24 October 2013 00:45:03 Sergey Cheban wrote:
24.10.2013 0:12, Edward Diener пишет:
All that the VC++12 xp build does is allow your program to run under Windows XP. Without that configuration your program will fail if running under Windows XP. It may also set the _WIN32_WINNT macro automatically. You should try it out to see if it does.
Windows SDK 7.1A:
#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_) #define _WIN32_WINNT 0x0601 #endif
Maybe it would be a good idea to just include sdkddkver.h and then analyze _WIN32_WINNT value so that Boost automatically uses the right WinAPI. If the user does not define this macro then we use whatever the default is in the current SDK.
Maybe it would be a good idea to just include sdkddkver.h and then analyze _WIN32_WINNT value so that Boost automatically uses the right WinAPI. If the user does not define this macro then we use whatever the default is in the current SDK. I don't think so. The default _WIN32_WINNT=0x0601 in the windows sdk is very high but it does not break compatibility with WinXP in the most of
24.10.2013 1:06, Andrey Semashev пишет:
the cases. OTOH, if we use the _WIN32_WINNT, our library will be
incompatible with WinXP by default.
I propose the following approach:
condvar_vista.cpp:
==============================
#define _WIN32_WINNT 0x0600
#include
On Thursday 24 October 2013 02:40:06 Sergey Cheban wrote:
24.10.2013 1:06, Andrey Semashev пишет:
Maybe it would be a good idea to just include sdkddkver.h and then analyze _WIN32_WINNT value so that Boost automatically uses the right WinAPI. If the user does not define this macro then we use whatever the default is in the current SDK.
I don't think so. The default _WIN32_WINNT=0x0601 in the windows sdk is very high but it does not break compatibility with WinXP in the most of the cases. OTOH, if we use the _WIN32_WINNT, our library will be incompatible with WinXP by default.
I think if the user targets for XP compatibility, he has to define _WIN32_WINNT anyway, and not just for his code but also for all the third- party code he compiles. If he uses externally built binaries, he has to trust the provider of these binaries that they were built compatible with XP (i.e. with _WIN32_WINNT defined). If you don't define _WIN32_WINNT, you basically rely on Windows SDK to choose the default. And I think this is actually a good strategy to choose the default for Boost, too. Use whatever is allowed by the user and the SDK.
I propose the following approach:
[snip]
With this approach, our library will contain both implementations of the condvar class (providing the SDK is not too old). To choose between them, developers will have to define _WIN32_WINNT for their applications but will not have to recompile our library.
What do you think about this idea?
That won't work because condvar_vista would involve functions that are not present in XP. Any built Boost binary will contain references to these functions and will not load on XP. If we speak only of header-only components implemented that way, assuming no built binaries use them, then that is already the plan. Boost.Sync will contain implementations for XP and Vista, and will select them based on the chosen WinAPI version. But I assure you that mutexes and condition variables will be used in built binaries and thus it does not solve the problem.
I think if the user targets for XP compatibility, he has to define _WIN32_WINNT anyway, and not just for his code but also for all the third- party code he compiles. If he uses externally built binaries, he has to trust the provider of these binaries that they were built compatible with XP (i.e. with _WIN32_WINNT defined). Many of external libraries do not use the Windows SDK at all (zlib, for example). So, it depends. I prefer not to use the externally built
24.10.2013 4:53, Andrey Semashev пишет: libraries but some people use them.
With this approach, our library will contain both implementations of the condvar class (providing the SDK is not too old). To choose between them, developers will have to define _WIN32_WINNT for their applications but will not have to recompile our library. That won't work because condvar_vista would involve functions that are not present in XP. Any built Boost binary will contain references to these functions and will not load on XP. No. The condvar_vista won't be included into the binary because it won't be used (providing _WIN32_WINNT==0x0501 for the user's code). The whole condvar_vista.obj will be linked out. So, the vista-specific functions won't be referenced and the code will be WinXP-compatible.
OTOH, some developers define _WIN32_WINNT==0x0602 because they want access to the vista-specific structures and avoid static linking to the vista-specific functions. BOOST_USE_WINAPI_VERSION would be useful for them. -- Best regards, Sergey Cheban
On 24/10/2013 18:19, Quoth Sergey Cheban:
OTOH, some developers define _WIN32_WINNT==0x0602 because they want access to the vista-specific structures and avoid static linking to the vista-specific functions. BOOST_USE_WINAPI_VERSION would be useful for them.
Count me in that group. It requires a bit more discipline and testing (and GetProcAddress) but it's useful to be able to write software that works on one or the other based on runtime detection rather than precompiled expectations. The part where it will get annoying is for libraries with source, which will be unaffected by the user's defines at the time they include Boost, in turn potentially requiring that they compile Boost itself with different options for different targets. (And Boost binaries are already in the multi-GB bracket even for a simple debug+release setup.)
On Thursday 24 October 2013 09:19:09 Sergey Cheban wrote:
24.10.2013 4:53, Andrey Semashev пишет:
I think if the user targets for XP compatibility, he has to define _WIN32_WINNT anyway, and not just for his code but also for all the third- party code he compiles. If he uses externally built binaries, he has to trust the provider of these binaries that they were built compatible with XP (i.e. with _WIN32_WINNT defined).
Many of external libraries do not use the Windows SDK at all (zlib, for example). So, it depends. I prefer not to use the externally built libraries but some people use them.
Libraries that don't use Windows SDK are irrelevant for the sake of this discussion. But it is rarely a documented feature, so you would have to inspect its code to verify that or just define _WIN32_WINNT to be on the safe side.
With this approach, our library will contain both implementations of the condvar class (providing the SDK is not too old). To choose between them, developers will have to define _WIN32_WINNT for their applications but will not have to recompile our library.
That won't work because condvar_vista would involve functions that are not present in XP. Any built Boost binary will contain references to these functions and will not load on XP.
No. The condvar_vista won't be included into the binary because it won't be used (providing _WIN32_WINNT==0x0501 for the user's code). The whole condvar_vista.obj will be linked out. So, the vista-specific functions won't be referenced and the code will be WinXP-compatible.
If condvar_vista is compiled into a dll, it won't be linked out. If you don't compile it because _WIN32_WINNT == 0x0501 then that's the current approach already. And it requires _WIN32_WINNT to be defined when Boost itself is built.
No. The condvar_vista won't be included into the binary because it won't be used (providing _WIN32_WINNT==0x0501 for the user's code). The whole condvar_vista.obj will be linked out. So, the vista-specific functions won't be referenced and the code will be WinXP-compatible. If condvar_vista is compiled into a dll, it won't be linked out. If you don't compile it because _WIN32_WINNT == 0x0501 then that's the current approach already. And it requires _WIN32_WINNT to be defined when Boost itself is built. Sorry, I've completely forgotten about the dll versions of boost libraries. Of course, to build them, the WINAPI version must be specified at compile time (or,
On 24.10.2013 13:00, Andrey Semashev wrote: the library could use GetProcAddress etc., but this approach has it's own drawbacks). -- Sergey Cheban
participants (9)
-
Andrey Semashev -
Edward Diener -
Gavin Lambert -
Lars Viklund -
Niall Douglas -
Olaf van der Spek -
Peter Dimov -
Sergey Cheban -
Vicente J. Botet Escriba