Re: Clean up some old cruft related to Windows

Hello.

I understand that this is not for back-patching.

At Tue, 18 Feb 2020 16:44:59 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Thu, Dec 19, 2019 at 01:46:33PM +0900, Kyotaro Horiguchi wrote:
> > I found some similar places by grep'ing for windows version names the
> > whole source tree.
> >
> > - The comment for trapsig is mentioning win98/Me/NT/2000/XP.
>
> Let's refresh the comment here, as per the following:
> https://docs.microsoft.com/en-us/previous-versions/xdkz3x12(v=vs.140)

* The Windows runtime docs at
* http://msdn.microsoft.com/library/en-us/vclib/html/_crt_signal.asp
...
- * Win32 operating systems generate a new thread to specifically handle
- * that interrupt. This can cause a single-thread application such as UNIX,
- * to become multithreaded, resulting in unexpected behavior.
+ * SIGINT is not supported for any Win32 application. When a CTRL+C interrupt
+ * occurs, Win32 operating systems generate a new thread to specifically
+ * handle that interrupt. This can cause a single-thread application, such as
+ * one in UNIX, to become multithreaded and cause unexpected behavior.
*
* I have no idea how to handle this. (Strange they call UNIX an application!)
* So this will need some testing on Windows.

The unmodified section just above is griping that "Strange they call
UNIX an application". The expression "application such as UNIX" seems
corresponding to the gripe. I tried to find the soruce of the phrase
but the above URL (.._crt_signal.asp) sent me "We're sorry, the page
you requested cannot be found.":(

Thank you for checking the belows.

> > - We don't need the (only) caller site of IsWindows7OrGreater()?
>
> The compiled code can still run with Windows Server 2008.

Do we let the new PG version for already-unsupported platforms? If I
don't missing anything Windows Server 2008 is already
End-Of-Extended-Support (2020/1/14) along with Windows 7.

> > - The comment for AddUserToTokenDacl() is mentioning "XP/2K3,
> > Vista/2008".
>
> Keeping some context is still good here IMO.

I'm fine with that.

> > - InitializeLDAPConnection dynamically loads WLDAP32.DLL for Windows
> > 2000. It could either be statically loaded or could be left as it
> > is, but the comment seems to need a change in either case.
>
> Looks safer to me to keep it.

If it is still possible that the file is missing on Windows 8/ Server
2012 or later, the comment should be updatd accordingly.

> > - The comment for IsoLocaleName mentioning Vista and Visual Studio
> > 2012.
>
> It is good to keep some history in this context.

Agreed.

> > - install-windows.sgml is mentioning "XP and later" around line 117.
>
> But this still applies to XP, even if compilation is supported from
> Windows 7.

Hmm. "/xp" can be the reason to preserve it.

By the way that pharse is considering Windows environment and perhaps
cmd.exe. So the folloinwg description:

https://www.postgresql.org/docs/current/install-windows-full.html
> In recent SDK versions you can change the targeted CPU architecture,
> build type, and target OS by using the setenv command, e.g. setenv
> /x86 /release /xp to target Windows XP or later with a 32-bit
> release build. See /? for other options to setenv. All commands
> should be run from the src\tools\msvc directory.

AFAICS we cannot use "setenv command" on cmd.exe, or no such command
found in the msvc directory.

> > - installation.sgml is mentioning NT/2000/XP as platforms that don't
> > support adduser/su, command.
>
> No objections to simplify that a bit.

Sorry for the ambiguity. I meant the following part

installation.sgml
> <para>
> <productname>PostgreSQL</productname> can be expected to work on these operating
> systems: Linux (all recent distributions), Windows (Win2000 SP4 and later),
> FreeBSD, OpenBSD, NetBSD, macOS, AIX, HP/UX, and Solaris.
> Other Unix-like systems may also work but are not currently
> being tested. In most cases, all CPU architectures supported by

(The coming version of) PostgreSQL doesn't support Win2000 SP4.

> Attached is a simplified version. It is smaller than the previous
> one, but that's already a good cut. I have also done some testing
> with the service manager to check after pipe_read_line(), and that
> works.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center