Re: [Plplot-devel] [plplot:bugs] #189 Using WIN32 Macro instead of _WIN32

[Alan W. I. <ir...@be...>]

Hi Arjen:

I agree its a dated table.  So, for example, it is possible
MinGW-w64 later severely changed course from the documentation
of the classical MinGW in this table.  However, if we changed
to _WIN32, and MinGW-w64 did not #define that
then your comprehensive test of MinGW-w64/MSYS2
would show problems immediately.  But I don't think
that is going to happen (i.e., I don't believe MinGW-w64
took a different course than MinGW in what WIN32-related
macros they #define).

More below.
On 2017-10-10 07:20-0000 Arjen Markus wrote:

> Hi Alan,

> I have had a look at the two discussions Alaric and you mention, and
I agree that the best choice seems to be _WIN32 to indicate the
Windows platform. I hesitate, however, to be absolutely sure, on the
following grounds:

> - The tip on detecting the operating systems mentions that there is
no 64-bits Cygwin system, but that was the case back in 2012. I have
been using Cygwin 64-bits for a couple of years now.

> - There is also mention of Cygwin in a POSIX and in a non-POSIX
variant. I have no clue as to how to determine which one I am working
with or how to specify that at install time.

My understanding is non-POSIX Cygwin is a thing of the past, i.e., you have the POSIX
version where no variant of WIN32 is #defined.  But to be absolutely
sure on this point, write a simple programme which includes the
following:

#if defined(WIN32) || defined(_WIN32) || defined (__WIN32__)
#error Cygwin defines at least one of the variants of the WIN32 macro
#endif

> - Also the table "Windows, Cygwin (non-POSIX), and MinGW" has
columns for the "Windows target" and the "MinGW target". It is unclear
to me what they mean by that.

I think the following note for the table explains it:

"Based on command-line options, the Clang/LLVM and GCC compilers can
build Windows applications or POSIX applications that run under
Windows using POSIX compatibility libraries."

I am virtually positive they are referring to the same distinction
used on MinGW-w64/MSYS2 between 
the "mingw" and "msys" repositories where the
first is native Windows while the second requires POSIX
compatibility libraries (the MSYS2 dll) in order to run under Windows.

In contrast, for modern Cygwin you build applications and libraries
that require the cygwin.dll compatibility library in order to run on
Windows.

> - Furthermore: is "MinGW" the old-style MinGW or the new one,
MinGW-w64/MSYS2? From the date of the post, I would say the former.

I agree.  But see my initial note above.

> All that does not mean that we should not consistently use _WIN32,
but perhaps some care is to be taken. The page
https://msdn.microsoft.com/en-us/library/b0084kay.aspx indicates that
Visual C++ does define _WIN32 for both the 32-bits and 64-bits
platforms. On the other hand, this page from the GNU C compiler
documentation says that macros whose name starts with two (!)
underscores are to be considered reserved and does not mention the
one-underscore macros as being special (only historical):
https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/System-specific-Predefined-Macros.html#System-specific%20Predefined%20Macros.

Nevertheless, everything I have read indicates non-Cygwin gcc on Windows does
#define _WIN32.

> I guess that only adds to the confusion :(.

Well, if we make a mistake here, it is easily rectified (assuming
testing on all 3 of your platforms).

As you can likely tell, I feel we should probably just go ahead
with this change, and just make sure it is well tested.  But before
doing that I will wait to see your response to my comments
above (as well as your results from the simple Cygwin test
I proposed above).

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
__________________________