Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: asyn driver on Windows XP
From: "Jeff Hill" <johill@lanl.gov>
To: "'Mark Rivers'" <rivers@cars.uchicago.edu>, "'Dirk Zimoch'" <dirk.zimoch@psi.ch>, "'Eric Norum'" <wenorum@lbl.gov>, "'EPICS'" <tech-talk@aps.anl.gov>
Date: Tue, 31 May 2011 13:25:01 -0600
> 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        johill@lanl.gov
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:rivers@cars.uchicago.edu]
> 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:johill@lanl.gov]
> 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        johill@lanl.gov
> 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:rivers@cars.uchicago.edu]
> > 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: tech-talk-bounces@aps.anl.gov
> > [mailto:tech-talk-bounces@aps.anl.gov] 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  <20112012  2013  2014  2015  2016  2017  2018  2019 
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  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·