Is Boost API 32Bit only?
I try to build Boost on MSYS2-64Bit which includes 64-Bit headers of windows. Boost is calling a 32-Bit variant of windows API even when Boost is configured to build 64-Bit. There is a 64Bit pre build variant of Boost on sourceforge. That seems to run only in visual studio? Does it use a 32 Bit API as well? Is there any reason for this design? I personaly prefer any variant of GCC over visual studio due to time consuming experiences with visual studio. Kind regards Andrej
I try to build Boost on MSYS2-64Bit which includes 64-Bit headers of windows. Boost is calling a 32-Bit variant of windows API even when Boost is configured to build 64-Bit.
What do you mean by "64-Bits headers"? How are the headers different? What error are you getting? For the record I build on windows using MYS2 64bit all the time with no problems. -- chris
On 17/03/2017 09:01, Andrej Georgi via Boost-users wrote:
I try to build Boost on MSYS2-64Bit which includes 64-Bit headers of windows. Boost is calling a 32-Bit variant of windows API even when Boost is configured to build 64-Bit.
There is a 64Bit pre build variant of Boost on sourceforge. That seems to run only in visual studio? Does it use a 32 Bit API as well?
This seems like either a misunderstanding or misreporting. The Windows headers are not "32-bit" or "64-bit". They are both. A 32-bit process will call 32-bit APIs. A 64-bit process will call 64-bit APIs. It is completely impossible to do anything else. The APIs have the same names and are implemented in libraries with the same names (and apparently in the same path, although actually in a different path, due to Windows trickery). The only differences are that the parameter sizes for *some* of the APIs are different, as they use 64-bit integers and pointers in some places instead of 32-bit ones. Pointer parameters will Just Work™. Integer parameters need to be explicitly specified as either one size, the other size, or both sizes (which one is actually used then depending on the target address model). If they're specified incorrectly then code is likely to crash or otherwise misbehave. If you think that Boost has somehow mis-specified one or more of these, you should be explicit about it, including both your Boost version and which ones you think are incorrect or what errors you're getting. Most likely, though, you're just compiling something incorrectly and/or trying to link 32-bit and 64-bit code together.
Thank you for your reply Gavin and the helpfull informations. I found a preliminary solution for my problem. MSYS2 has a prebuild Boost package. The problem seems to be the compiler which complained about typecasting from "long" to "DWORD". The result was an incorrect choice for an overloaded function. Yes MSYS2 header include overloaded 32 Bit windows functions which use _int64 in contrast to original windows. The compiler prefered __int64 over DWORD for long. There are different solutions to this problem. Anyway I doupt the MSYS2 system can compile Boost becorse _beginthreadex() is missing in process.h. This could be a configuration problem as well I will investigate later if needed. Basicaly I don't need 64Bit API but in case 32 Bit will disapear I don't want to migrate my old code. For Boost to realy implement 64-Bit "long long" types are needed in the API instead of "long". Am 17.03.2017 um 00:51 schrieb Gavin Lambert via Boost-users:
On 17/03/2017 09:01, Andrej Georgi via Boost-users wrote:
I try to build Boost on MSYS2-64Bit which includes 64-Bit headers of windows. Boost is calling a 32-Bit variant of windows API even when Boost is configured to build 64-Bit.
There is a 64Bit pre build variant of Boost on sourceforge. That seems to run only in visual studio? Does it use a 32 Bit API as well?
This seems like either a misunderstanding or misreporting.
The Windows headers are not "32-bit" or "64-bit". They are both.
A 32-bit process will call 32-bit APIs. A 64-bit process will call 64-bit APIs. It is completely impossible to do anything else.
The APIs have the same names and are implemented in libraries with the same names (and apparently in the same path, although actually in a different path, due to Windows trickery).
The only differences are that the parameter sizes for *some* of the APIs are different, as they use 64-bit integers and pointers in some places instead of 32-bit ones.
Pointer parameters will Just Work™. Integer parameters need to be explicitly specified as either one size, the other size, or both sizes (which one is actually used then depending on the target address model). If they're specified incorrectly then code is likely to crash or otherwise misbehave. If you think that Boost has somehow mis-specified one or more of these, you should be explicit about it, including both your Boost version and which ones you think are incorrect or what errors you're getting.
Most likely, though, you're just compiling something incorrectly and/or trying to link 32-bit and 64-bit code together.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 18 March 2017 at 14:13, Andrej Georgi via Boost-users < boost-users@lists.boost.org> wrote:
The problem seems to be the compiler which complained about typecasting from "long" to "DWORD". The result was an incorrect choice for an overloaded function. Yes MSYS2 header include overloaded 32 Bit windows functions which use _int64 in contrast to original windows.
The compiler prefered __int64 over DWORD for long. There are different solutions to this problem.
It sais on this page https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%..., that a DWORD is a A 32-bit unsigned integer. However, this is only true on windows, as DWORD is a typedef for "unsigned long" (a 32 bit unsigned integer on windows). This is a problematic choice (the typedef) as long is defined as 64 bit on all 'nix systems. Here https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models you'll find some info on the different data models. I deduce that MSYS2 or BOOST (on this platform) mixes them (the data models) up, maybe you can roll your own data-type: typedef std::uint32_t MY_DWORD; and use MY_DWORD to use the windows API. As you can see from the last link 'long long' is always a 64 bit integer, and not any cause of trouble ever. (notice on SPARC64 and int is 64 bit, must be a lot of fun using 3rd party libraries). degski
participants (4)
-
Andrej Georgi -
Chris Glover -
degski -
Gavin Lambert