Re: [Boost-users] Compile errors inside boost::asio code I can'taffect.

Subject: Re: [Boost-users] Compile errors inside boost::asio code I can'taffect.
From: Michael.Broida_at_[hidden]
Date: 2009-06-26 18:47:49

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of 
> Zachary Turner
> Sent: Friday, June 26, 2009 5:30 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] Compile errors inside boost::asio 
> code I can'taffect.
> 
> On Fri, Jun 26, 2009 at 3:14 PM, 
> <Michael.Broida_at_[hidden]> wrote:
> >>>----------------
> > error C2664: 'QueueUserAPC' : cannot convert parameter 1 
> from 'void (__cdecl
> > *)(ULONG)' to 'PAPCFUNC'
> > D:\dev\3rdParty_x64\include\boost\asio\detail\win_thread.hpp    151
> 
> It appears to me that you can only get this error if you have defined
> WINVER to be something less than 0x0500, which means the software you
> are building is attempting to support a version of windows PRIOR to
> Windows 2000.  Is this your intention?  Try defining WINVER to be
> 0x0500 (if you want to run on Win2k and higher) and 0x0501 (if you
> want to run on WinXP+)
> 
> 
> >
> >>>----------------
> > error C2664: 'GetQueuedCompletionStatus' : cannot convert 
> parameter 3 from
> > 'DWORD *' to 'PULONG_PTR'
> > 
> D:\dev\3rdParty_x64\include\boost\asio\detail\win_iocp_io_serv
ice.hpp   142
> >
> >>>----------------
> > error C2664: 'GetQueuedCompletionStatus' : cannot convert 
> parameter 3 from
> > 'DWORD *' to 'PULONG_PTR'
> > 
> D:\dev\3rdParty_x64\include\boost\asio\detail\win_iocp_io_serv
ice.hpp   430
> 
> This could be related to the first issue.  DWORD* and PULONG_PTR are
> supposed to be exactly the same type when compiling for x64 on recent
> operating systems.  So it makes me think that the compiler thinks
> you're on a really old operating system.  I would try this
> 
> #define WINVER 0x0501
> #define _WIN32_WINNT 0x0501
> 
> either in your stdafx.h if you use precompiled header, or as a command
> line option if you don't.

On our 32-bit builds (where this problem does NOT occur) we have been using _WIN32_WINNT=0x0500 in an inherited .vsprops file.  That's for both of these setups:
        - WinXP SP3 + VS2005, mostly for development, testing, etc
        - WindowsServer2003 + VS2005, generally our "production" environment

On the 64-bit builds (where the problem DOES occur) I am using _WIN32_WINNT=0x0600 directly in the .vcproj files.  That's on a WindowsServer2008 SP1, VS2008 setup.  Either "windows.h" or "WinNT.h" says 0x0600 is "Longhorn", and it appears that WindowsServer2008 qualifies, based on what I thought I saw when I intentionally omitted _WIN32_WINNT and let the compiler pick the value.  Maybe I'm wrong; I'll try to verify what happens if I don't specify anything for _WIN32_WINNT.

If you think 0x0600 is a BAD value to use, let me know and I'll revert to 0x0501 all the way around.

        Thanks!
                Mike

This email was sent to you by Thomson Reuters, the global news and information company.
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.