RFC: Replace "WIN32" with "_WIN32" in source code

[Albrecht Schlosser]

I propose to replace the usage of the preprocessor macro "WIN32" with
"_WIN32" in source code and related documentation.

Reasons:

(1) WIN32 as a preprocessor macro seems to be deprecated. Recent
compilers seem to define only _WIN32 (not WIN32), particularly if used
with modern C++ standards (C++11, C++14 etc.). I'm not sure about the
"rules" but this sounds sensible (compilers shall #define only names
with leading underscore). We got reports that this is indeed the case
with some compilers that define _WIN32 but not WIN32 if used with
-std=c++11 or -std=c++14. GNU compilers may be an exception if the
commandline switches -std=gnu++11 or -std=gnu++14), i.e. new standard
with GNU extensions, is used. Again, not 100% sure.

(2) Most other libraries (maybe not all) seem to use _WIN32 as well.

(3) Currently we #define WIN32 when building the FLTK library under
Windows and we require the user to #define WIN32 to compile FLTK with
its headers to work correctly. We got reports that FLTK under Windows
could not be compiled (it used some Unix/Linux/X11 specific code paths)
because WIN32 was not defined. Users had to add WIN32 to "additional
preprocessor defines" etc. when using Visual Studio for their own projects.

FWIW: Windows 64-bit compilers #define _WIN32 as well, so _WIN32 is
always correct, whether the (Windows) platform is 32-bit or 64-bit.

I'm not sure though if this step (WIN32 -> _WIN32) would remove the
requirement to #define _WIN32 for some Windows toolchains, but I believe
it would so we could also remove the documentation that the definition
of (previously WIN32 and now) _WIN32 is required under Windows.

Finally, when the transition to full system driver support is complete,
we should have far less occurrences of "_WIN32" in the code anyway. My
proposal (together with the other RFC to replace WIN32 with Windows in
text and documentation) shall also simplify searches to find these
remaining occurrences in our library code.

Comments and suggestions welcome.

[imm]

On 2 February 2018 at 15:01, Albrecht Schlosser wrote:
> I propose to replace the usage of the preprocessor macro "WIN32" with
> "_WIN32" in source code and related documentation.
>

I think this is correct.

Once upon a time, many Windows compilers set both WIN32 and _WIN32
(and often _WIN32_ and __WIN32 also) , but it seems the MS compilers
no longer set WIN32 by default (though it would appear that mingw
does.)

So now it seems the _WIN32 is the most robust choice. If we us that
consistently, we probably no longer need to set WIN32 in our
configuration at all. We can "rely" on _WIN32 being set. Probably...

[Albrecht Schlosser]

Yep, that's what I believe as well. And if we get any error messages we
can still #define _WIN32 on the command line instead of WIN32 as we do now.

Again, I'm willing to do all these changes soon.

I think now (FLTK 1.4.0) is the right time to do the switch, so please
vote. My vote is definitely:

+1 to change WIN32 to _WIN32 where applicable

(for instance in "#ifdef WIN32" etc.).

[Manolo]

On Monday, 5 February 2018 17:32:23 UTC+1, Albrecht Schlosser wrote:

I think now (FLTK 1.4.0) is the right time to do the switch, so please
vote. My vote is definitely:

+1 to change WIN32 to _WIN32 where applicable

+1 to this change for my vote too.

[Greg Ercolano]

+1.

I can kinda see why someone preferred the WIN32 thing,
to avoid having scary/ugly leading underbars in the code.

But, looks like many OS platform macros have leading underbars
(__sgi, __APPLE__) and compiler macros too (__CYGWIN__, __MINGW32__, __MWERKS__)

[Ian MacArthur]

> On 5 Feb 2018, at 16:32, Albrecht Schlosser wrote:
>
>
> Yep, that's what I believe as well. And if we get any error messages we can still #define _WIN32 on the command line instead of WIN32 as we do now.
>
> Again, I'm willing to do all these changes soon.
>
> I think now (FLTK 1.4.0) is the right time to do the switch, so please vote. My vote is definitely:
>
> +1 to change WIN32 to _WIN32 where applicable
>

Yes. +1

[Albrecht Schlosser]

Okay, thanks to all: we have +4 votes now.

I'm working on it. It's almost ready, but I'd like to wait with the
commit until we agreed upon the other

RFC: Replace "WIN32" with "Windows" in text and documentation

(see that thread) and Manolo's OpenGL/texture patch because my work
would likely invalidate his patch. See STR #3450: "Draw text with OpenGL
using textures on all platforms". I think this patch is ready now.
http://www.fltk.org/str.php?L3450

There are two patches that must be combined:
http://www.fltk.org/strfiles/3450/GLtextureV4.patch
http://www.fltk.org/strfiles/3450/GLtextureV4_cygwin.patch

See also thread "Please vote about STR#3450: Draw text with OpenGL using
textures on all platforms"

[Manolo]

On Tuesday, 6 February 2018 19:04:28 UTC+1, Albrecht Schlosser wrote:

Okay, thanks to all: we have +4 votes now.

I'm working on it. It's almost ready, but I'd like to wait with the
commit until we agreed upon the other

  RFC: Replace "WIN32" with "Windows" in text and documentation

(see that thread) and Manolo's OpenGL/texture patch because my work
would likely invalidate his patch. See STR #3450: "Draw text with OpenGL
using textures on all platforms". I think this patch is ready now.
http://www.fltk.org/str.php?L3450

There are two patches that must be combined:
http://www.fltk.org/strfiles/3450/GLtextureV4.patch
http://www.fltk.org/strfiles/3450/GLtextureV4_cygwin.patch

OK. I understand you wait for the "use OpenGL textures " patch to be committed,
and will do my best to achieve that.

[Albrecht Schlosser]

On 06.02.2018 21:14 Manolo wrote:
>
> OK. I understand you wait for the "use OpenGL textures " patch to be
> committed,
> and will do my best to achieve that.

I'd appreciate that, but don't worry. The question is only whether you
or I will have to fix merge conflicts. I'll let you do the commit first
and fix the merge commits in my work locally.

PS: I seem to be ready, at least I could compile and link on Windows
(MinGW, VS, and Cygwin/X11) and on Linux. More tests to come, but it
looks good so far...

[Manolo]

On Wednesday, 7 February 2018 18:09:37 UTC+1, Albrecht Schlosser wrote:

On 06.02.2018 21:14 Manolo wrote:
>
> OK. I understand you wait for the "use OpenGL textures " patch to be
> committed,
> and will do my best to achieve that.

I'd appreciate that, but don't worry. The question is only whether you
or I will have to fix merge conflicts. I'll let you do the commit first
and fix the merge commits in my work locally.   

The  "use OpenGL textures " patch is now committed to svn (r.12650).

[Albrecht Schlosser]

Thanks. I see we're now at r12652. Are you still working on other
changes, i.e. are there other commits to be expected?

Note: I'm working on a patch for the latest MinGW version. See thread
"fltk 1.3.4-2 compile error on windows 7" in fltk.general. I'll postpone
my other work until this is fixed.

[Manolo]

On Thursday, 8 February 2018 16:51:04 UTC+1, Albrecht Schlosser wrote:

On 07.02.2018 18:14 Manolo wrote:
>
> The  "use OpenGL textures " patch is now committed to svn (r.12650).

Thanks. I see we're now at r12652. Are you still working on other
changes, i.e. are there other commits to be expected?

I have another commit planned to complete scaling support on the MacOS
platform, where fl_read_image() stil does not scale correctly.
But that's no reason to prevent you from moving to _WIN32 use.
 

Note: I'm working on a patch for the latest MinGW version. See thread
"fltk 1.3.4-2 compile error on windows 7" in fltk.general. I'll postpone
my other work until this is fixed.

I understand.
 

[Albrecht Schlosser]

On 09.02.2018 09:57 Manolo wrote:
>
> I have another commit planned to complete scaling support on the MacOS
> platform, where fl_read_image() stil does not scale correctly.
> But that's no reason to prevent you from moving to _WIN32 use.

It's done now. svn r12655 is the large commit with all changes I found
and this commit is tested (as usual) under Linux and Windows
(MinGW/configure, MinGW/CMake, and Visual Studio).

FYI: Excerpt from the commit log:
-----
Replace compiler/preprocessor/platform macro "WIN32" with "_WIN32".
Replace "WIN32" in text and documentation with "Windows".
Replace "MSWindows" with "Windows".

To do: README.Windows.txt (and maybe other documentation as well)
needs updates.
-----

I also renamed README.MSWindows.txt to README.Windows.txt for
consistency (is there another "Windows"? ;-))

> Note: I'm working on a patch for the latest MinGW version. See thread
> "fltk 1.3.4-2 compile error on windows 7" in fltk.general. I'll
> postpone my other work until this is fixed.

I'm still waiting for feedback in the fltk.coredev thread "Latest MinGW:
build errors (undefined: __FD_ISSET)" which is the logical continuation
of the fltk.general thread mentioned above.

Meanwhile I committed the WIN32 changes, and I see that you (Manolo)
committed r12656, so we're obviously in sync again.