> That is exactly what happened to me. My system is XP SP3 (=0x0503), but
> the SDK include file sets _WIN32_WINNT to 0x0600 by default. Eric's code
> in asyn checks the value of POLLIN, and uses WASPoll() if it is defined.
> POLLIN is defined if _WIN32_WINNT = 0x0600, so asyn uses WASPoll(), which
> then results in an application that won't run on my host machine that
> built it!
This does appear to be the current situation, based on the attached test
code. I was careful to minimize use of the windows headers in the EPICS
public header files. And this allows EPICS base to be mostly neutral on the
definition of _WIN32_WINNT. The one exception is currently osiSock.h which
indirectly includes winsock2.h - which appears to define _WIN32_WINNT. In
the future there could be other parallel situations when wrapping the
windows intrinsic atomic operators with inline functions.
Initially, the idea of setting _WIN32_WINNT to 0x0400 in the build system
from within CONFIG.win32-x86.win32-x86 or CONFIG_SITE.win32-x86.win32-x86
makes me queasy as this would tend to set policy, and clash with application
codes which might have different requirements? Admittedly, perhaps setting a
very low value such as 0x400 is a much more sensible default than the one
provided by Microsoft.
The alternative which perhaps can also be considered is to just set
_WIN32_WINNT _only_ in a limited set of windows specific application source
files, that actually include osdSock.h or in other ways touch windows
specific headers, or in windows specific makefile variables within the
application's makefile?
I am definitely listening to arguments to the contrary, as I don?t claim to
see all of the impacts or to have the application builder's perspective.
Should I create an entry in the bug tracker so that we can track the issue?
Here is my test code FWIW.
#include "windows.h"
#if 0
#include "winsock2.h"
#endif
#include "stdio.h"
int main ()
{
printf ("_WIN32_WINNT %x\n", _WIN32_WINNT);
}
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Tuesday, May 31, 2011 11:43 AM
> To: Jeff Hill; Dirk Zimoch; Eric Norum; EPICS
> Cc: Janet Anderson
> Subject: RE: asyn driver on Windows XP
>
> Hi Jeff,
>
> > I confess to not being aware that _not_ setting this parameter on the
> command line might
> > imply that the executable was restricted to only running on the build
> host's platform.
>
> No, that is NOT the problem. It's the opposite: NOT setting this
> parameter can lead to situations where the application will not even run
> on the host platform!
>
> That is exactly what happened to me. My system is XP SP3 (=0x0503), but
> the SDK include file sets _WIN32_WINNT to 0x0600 by default. Eric's code
> in asyn checks the value of POLLIN, and uses WASPoll() if it is defined.
> POLLIN is defined if _WIN32_WINNT = 0x0600, so asyn uses WASPoll(), which
> then results in an application that won't run on my host machine that
> built it!
>
> I am suggesting that we should define _WIN32_WINNT in a CONFIG_SITE file
> to specify the minimum host archtecture we want our application to be able
> to run on.
>
> Mark
>
>
>
> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Tuesday, May 31, 2011 12:18 PM
> To: Mark Rivers; 'Dirk Zimoch'; 'Eric Norum'; 'EPICS'
> Cc: 'Janet Anderson'
> Subject: RE: asyn driver on Windows XP
>
> Hi Mark,
>
> Searching in the source I can see that _WIN32_WINNT is being set in
> certain
> .c/.cpp src\libCom\osi\os\WIN32 in order to enable use of some of the post
> W95 features of windows.
>
>
> C:\hill\epicsInBazaar\cvs-
> trunk\src\libCom\osi\os\WIN32\osdMutex.c(32):#defi
> ne _WIN32_WINNT 0x0400
> C:\hill\epicsInBazaar\cvs-
> trunk\src\libCom\osi\os\WIN32\osdThread.c(27):#
> define _WIN32_WINNT 0x400 /* defining this drops support for W95 */
>
> C:\hill\epicsInBazaar\cvs-
> trunk\src\libCom\osi\os\WIN32\osdThread.c(124):#if
> _WIN32_WINNT >= 0x0501
> C:\hill\epicsInBazaar\cvs-
> trunk\src\libCom\osi\os\WIN32\osdThread.c(213):
> * if defined ( NTDDI_VISTA ) && _WIN32_WINNT >= NTDDI_VISTA
>
> C:\hill\epicsInBazaar\cvs-
> trunk\src\libCom\osi\os\WIN32\setThreadName.cpp(15
> ):# define _WIN32_WINNT 0x400 /* defining this drops support for W95 */
>
> I have been assuming that setting this parameter too high would keep the
> executable from running on older versions of windows where a certain
> feature
> in the WIN32 API is lacking. I confess to not being aware that _not_
> setting
> this parameter on the command line might imply that the executable was
> restricted to only running on the build host's platform. It seems that
> many
> people would be complaining if that were the case? Is this really true? I
> found this page, but a quick read doesn't seem to imply that the
> executable
> is restricted to only running on the build host's platform if _WIN32_WINNT
> isn't set, but maybe that isn't spelled out by MS.
>
> http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx
>
> I suppose that we could set _WIN32_WINNT to 0x400 in
> CONFIG.win32-x86.win32-x86 in order to document at compile time that EPICS
> base will not run on windows 95, but raising it globally above that level
> might restrict deployment of EPICS base to some of the older versions of
> windows that might still in use?
>
> Perhaps the solution is to only selectively set this _WIN32_WINNT in
> certain
> asyn source file (.c/.cpp files) that require a new feature of the windows
> API, and then only these asyn dll will be restricted to certain newer
> versions of windows. Does that work?
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill Email [email protected]
> LANL MS H820 Voice 505 665 1831
> Los Alamos NM 87545 USA FAX 505 665 5107
>
> Message content: TSPA
>
> With sufficient thrust, pigs fly just fine. However, this is
> not necessarily a good idea. It is hard to be sure where they
> are going to land, and it could be dangerous sitting under them
> as they fly overhead. -- RFC 1925
>
>
> > -----Original Message-----
> > From: Mark Rivers [mailto:[email protected]]
> > Sent: Tuesday, May 31, 2011 10:15 AM
> > To: Dirk Zimoch; Eric Norum; EPICS
> > Cc: Janet Anderson; Jeff Hill
> > Subject: RE: asyn driver on Windows XP
> >
> > Folks,
> >
> > I think we need to revisit this problem. The problem is that when
> > building on win32-x86 there is confusion about what OS version is being
> > built for. This most often leads to an error when running applications
> > built with asyn. asyn contains the following code to determine if
> > WSAPoll should be used:
> >
> > # elif defined(_WIN32)
> > # if defined(POLLIN)
> > # define poll(fd,nfd,t) WSAPoll(fd,nfd,t)
> > # else
> > # define FAKE_POLL
> > # endif
> >
> > POLLIN should only be defined on more recent (e.g. Windows Vista and
> > Windows 7) systems, not on XP, where WSAPoll() does not exist.
> >
> > Previously users who were building with Microsoft Visual C++ 2008
> > Express Edition were finding that the file
> >
> > C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\sdkddkver.h
> >
> > Contained the following:
> >
> > #if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
> > #define _WIN32_WINNT 0x0601
> > #endif
> >
> > The definitions of _WIN32_WINNT are:
> > Windows 7 _WIN32_WINNT_WIN7
> > (0x0601)
> > Windows Server 2008 _WIN32_WINNT_WS08
> > (0x0600)
> > Windows Vista _WIN32_WINNT_VISTA
> > (0x0600)
> > Windows Server 2003 with SP1, Windows XP with SP2 _WIN32_WINNT_WS03
> > (0x0502)
> > Windows Server 2003, Windows XP _WIN32_WINNT_WINXP
> > (0x0501)
> > Windows 2000 _WIN32_WINNT_WIN2K
> > (0x0500)
> >
> > I recently upgraded my Windows XP SP3 system from Visual Studio 2005 to
> > Visual Studio 2008, and in doing that it added
> >
> > C:\Program Files\Microsoft SDKs\Windows\v6.0A
> >
> > In place of
> > C:\Program Files\Microsoft SDKs\Windows\v5.0
> >
> >
> > C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\sdkddkver.h
> > contains:
> > #if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
> > #define _WIN32_WINNT 0x0600
> > #endif
> >
> > Note that although this is a Windows XP SP3 system, _WIN32_WINNT is
> > defined to be 0x0600, which is Windows Vista.
> >
> > When I build and run win32-x86 applications build with asyn they link
> > OK, but they give a run-time error that WSAPoll cannot be found in the
> > Winsock DLL.
> >
> > I worked around the problem by modifying sdkddkver.h to set the value to
> > 0x0503 (XP SP3), but this is clearly not the correct solution.
> >
> > I has originally blamed Microsoft for doing something stupid with VS
> > Express, but I am coming to the conclusion that we are doing something
> > wrong in the EPICS build system.
> >
> > We are assuming that the default build with Visual Studio with the flags
> > we use will build an application that can run on the host machine. This
> > is clearly incorrect. Microsoft is letting one build an application on
> > a host OS that can run on other target OS, for example I can build an
> > application on Windows 7 that will run on XP, etc.
> >
> > I believe we need to define _WIN32_WINNT in
> > CONFIG_SITE.win32-x86.win32-x86 or a similar file to declare what
> > Windows OS we are targeting with our EPICS build. One may well want to
> > set this to 0x0503 so that the executable can run on XP, even if it is
> > being built on a Windows 7 system, for example.
> >
> > Does this seem correct?
> >
> > Janet, Jeff?
> >
> > Thanks,
> > Mark
> >
> > -----Original Message-----
> > From: Mark Rivers
> > Sent: Monday, November 15, 2010 11:07 AM
> > To: 'Dirk Zimoch'; EPICS
> > Subject: RE: asyn driver on Windows XP
> >
> > Hi Dirk,
> >
> > A similar problem has been seen by other users when using Microsoft
> > Visual C++ 2008 Express Edition.
> >
> > The problem turned out to be apparently an error in Microsoft's header
> > file. Here is a message from Anthony Owen at the Australian Synchrotron
> > with his fix.
> >
> > *******************************************************************
> > Hi Mark,
> >
> > It turns out that the issue was with the Microsoft SDK. The SDK is
> > installed as part of the Visual Studio Package.
> >
> > I tried SDK 6.0V and SDK 7.0 and got the same problem. It was narrowed
> > down to be the version being incorrectly detected in the file:
> >
> > C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\sdkddkver.h
> >
> > <snip>
> >
> > #if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
> > #define _WIN32_WINNT 0x0601
> > #endif
> >
> > <snip>
> >
> > It was defining 0x0601 which appears to be Windows 7.
> > With this changed to 0x0503 (Windows XP SP3) and ASYN reverted to its
> > original form, POLLIN is not defined and ASYN uses FAKE_POLL.
> > It compiled and executed successfully.
> >
> > Hope this helps if you have to use Visual Express!
> >
> > Best Regards,
> >
> > Anthony Owen
> > *******************************************************************
> >
> > So the header file was incorrectly setting the system version to be
> > 0x0601, which is Windows 7, even though it was an XP system. That then
> > caused POLLIN to be defined when it should not have been.
> >
> > Is there a similar problem in Visual Studio 10?
> >
> > Mark
> >
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Dirk Zimoch
> > Sent: Monday, November 15, 2010 10:58 AM
> > To: EPICS
> > Subject: asyn driver on Windows XP
> >
> > Hi all,
> >
> > I have a problem with the latest version of asyn driver on Windows XP.
> > It tries to use a function WSAPoll() that does not exist in XP, only in
> > Vista and newer. However I do not want use an old version of asyn driver
> >
> > without that function because of all the new features and bugfixes.
> >
> > The code in question is:
> >
> > #if defined(__rtems__)
> > # define USE_SOCKTIMEOUT
> > #else
> > # define USE_POLL
> > # if defined(vxWorks)
> > # define FAKE_POLL
> > # elif defined(_WIN32)
> > # if defined(POLLIN)
> > # define poll(fd,nfd,t) WSAPoll(fd,nfd,t)
> > # else
> > # define FAKE_POLL
> > # endif
> > # else
> > # include <sys/poll.h>
> > # endif
> > #endif
> >
> > It seems I have POLLIN defined but no WSAPoll.
> >
> > I am using the compiler from Visual Studio 10.
> >
> > Any idea?
> >
> > Dirk
- References:
- RE: asyn driver on Windows XP Mark Rivers
- RE: asyn driver on Windows XP Jeff Hill
- RE: asyn driver on Windows XP Mark Rivers
- Navigate by Date:
- Prev:
RE: asyn driver on Windows XP Mark Rivers
- Next:
Re: How does EPICS increment its clock for timestamp Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: asyn driver on Windows XP Mark Rivers
- Next:
RE: asyn driver on Windows XP Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|