Hi Paul,
Attached is a proposed Gnulib patch to fix some occurrences of
the "win" terminology problem.
It mostly just substitutes "Woe32" for "Win32", except that for
"Win32 API" it substitutes "Windows API".
It's good to clean up some of these terms once in a decade, yes.
I'm largely responsible of this issue: I started using "Woe32"
instead of "Win32", out of frustration when porting GNU clisp to
this platform, and mimicking the word "MS-DOG" found in Emacs.
Then I mentioned it to RMS, who subsequently added some wording
about it to the GNU Coding Standards. Some time later, I grew up
and found it a bit childish; so I used this word only in comments
and READMEs but not in function names or real code.
The phrase "Windows Operating Environment" is new to me. Rarely seen.
The Microsoft overview of the API
<http://msdn.microsoft.com/en-us/library/aa383723.aspx> says,
"Note that this was formerly called the Win32 API. The name
Windows API more accurately reflects its roots in 16-bit Windows
and its support on 64-bit Windows."
Thanks for this info.
There is also Wikipedia [1] which says:
"The Windows API, informally WinAPI, is Microsoft's core set of application
programming interfaces (APIs) available in the Microsoft Windows operating
systems. It was formerly called the Win32 API;..."
But "Win32" also carries four other pieces of information:
1) It contrasts with the NtDll API.[2] For example, file names passed
to NtDll functions can use a different syntax than file names
passed to Win32 functions.[3] This distinction matters because
programs build with gnulib should also work in WINE, and WINE
implements kernel32.dll but not NtDll.dll. Also, the NtDll API is
basically undocumented and subject to change.[4]
2) It contrasts with Windows 3.1 (16-bit Windows), that was in use from
ca. 1991 to ca. 1997. Nowadays it is not a portability target any
more, so this distinction is no longer necessary.
3) It is disjoint from Cygwin.
4) It was not meant to be 64-bit. But now, Microsoft has adopted the same
API with minor modifications also for 64-bit Windows.[5]
For gnulib, what's interesting is:
* When talking about the operating system, we don't care about 32-bit
or 64-bit. But we do care about the distinction between executables
that link with kernel32.dll and executables that use cygwin1.dll.
* When talking about the API we use (from kernel32.dll, winsock2, etc.)
we also care about this distinction.
* In the preprocessor statements, we have to use _WIN32 and __WIN32__
because that's what the compilers define.
So, what I suggest for gnulib code and comments is:
* Don't use terms like "WinAPI", "WinFOO", "WinXP", because "win" is a
praise word.
* Don't increase the use of the term "Woe32", because it's childish.
* Don't say "Windows-NT" because the operating system versions
Windows 95/98/ME/2000/XP/Vista/7 all implement the Win32 API as well.
In current speak, "Windows NT" was just the version 3.5 and 4 of
Windows (in use ca. 1993-2000).
* Don't edit past ChangeLog entries. That's pointless.
* Use "native Windows" to denote the brand of executables, if it's clear
from context that Cygwin is excluded. Or "Windows, except Cygwin" if
it needs to be made explicit.
* Use "native Windows API" or "Windows API" to denote the API (in code).
Or "documented Windows API" or "Windows API, excluding system internals",
if we need to be clear about NtDll.
* The abbreviation "w32-" or "w-" can be used when an abbreviation
makes sense. For example, in file names.
Here's my counter-proposal (attached).
A second, separate patch could be applied to reduce the number of uses
of the term "Woe32" (optional).
Bruno
[1] http://en.wikipedia.org/wiki/Win32
[2] http://msdn.microsoft.com/en-us/library/bb432380(v=vs.85).aspx
[3] http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx#maxpath
[4] http://msdn.microsoft.com/en-us/library/bb432200(v=vs.85).aspx
[5] http://msdn.microsoft.com/en-us/library/bb427430%28v=VS.85%29.aspx