From: Alan W. I. <ir...@be...> - 2017-10-11 02:18:01
|
On 2017-10-10 06:52-0400 Jim Dishaw wrote: [....] > I read the MSDN Documentation as well as the Intel, MinGW, and GNU compiler documentation. > > The WIN32 should not be used and appears to be an older convention The MSDN and Intel documentation define _WIN32 and _WIN64. MinGW appears to be following MSDN, which makes sense. > > Moving away from WIN32 will break builds on older platforms that we no longer support, but I don’t think that is a problem. > > I would stay away from __WIN32__ as that is not in the MSDN documentation. To Arjen and Jim: @Arjen: Thanks for running that quick check (in a different post than the above) on Cygwin which gave the expected result, but it is always good to be sure. @Jim: Thanks very much for that clear advice above. I agree with you the proposed change (to move strictly to _WIN32) will break builds for older versions of compilers that we don't support in any case. But with modern versions of Intel, MSVC, gcc, and clang compilers all providing the _WIN32 macro for their pure native Windows builds, I would frankly be amazed if modern versions of much less popular compilers (e.g., Borland and Watcom) did not provide that macro as well. So I have decided to go ahead with this proposed change. @Those here with access to Windows: Accordingly I have now replaced use of the WIN32 and __WIN32__ macros with the _WIN32 macro throughout our C and C++ source code (commit 14ecc4b). This is an intrusive change so I would appreciate tests of it on all Windows compilers and Windows platforms (e.g., MSVC, Cygwin, and MinGW-w64/MSYS2) accessible to you. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |