Remove support for Visual Studio 2013

Started by Michael Paquierover 3 years ago16 messages
#1Michael Paquier
michael@paquier.xyz
1 attachment(s)

Hi all,

Cutting support for now-unsupported versions of Windows is in the air
for a couple of months, and while looking at the code a first cleanup
that looked rather obvious to me is the removal of support for VS
2013, as of something to do for v16~.

The website of Microsoft has only documentation for VS >= 2015 as far
as I can see. Note also that VS can be downloaded down to 2012 on
their official website, and that the buildfarm members only use VS >=
2017.

The patch attached cleans up the following things proper to VS 2013:
- Locale handling.
- MIN_WINNT assignment.
- Some strtof() business, as of win32_port.h.
- Removal of _set_FMA3_enable() in main.c related to floating-point
operations.
- MSVC scripts, but that's less interesting considering the work done
with meson.

A nice result is that this completely removes all the checks related
to the version number of _MSC_VER from the core code, making the code
depend only on the definition if the flag.

Thanks,
--
Michael

Attachments:

0001-Remove-support-for-VS-2013.patchtext/x-diff; charset=us-asciiDownload
From 7502f8c9a114ac483e553f444301a23e5c65cc2c Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Mon, 16 May 2022 15:20:26 +0900
Subject: [PATCH] Remove support for VS 2013

---
 src/include/port/win32.h          | 10 ++++----
 src/include/port/win32_port.h     |  7 +-----
 src/backend/main/main.c           | 22 -----------------
 src/backend/utils/adt/float.c     |  6 +----
 src/backend/utils/adt/pg_locale.c | 40 -------------------------------
 src/port/chklocale.c              | 16 +------------
 doc/src/sgml/install-windows.sgml | 10 ++++----
 src/tools/msvc/MSBuildProject.pm  | 27 +--------------------
 src/tools/msvc/README             |  8 +++----
 src/tools/msvc/Solution.pm        | 28 ----------------------
 src/tools/msvc/VSObjectFactory.pm | 12 ++--------
 11 files changed, 19 insertions(+), 167 deletions(-)

diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index c6213c77c3..539f3ec6d1 100644
--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -11,12 +11,12 @@
 
 /*
  * Make sure _WIN32_WINNT has the minimum required value.
- * Leave a higher value in place. When building with at least Visual
- * Studio 2015 the minimum requirement is Windows Vista (0x0600) to
- * get support for GetLocaleInfoEx() with locales. For everything else
- * the minimum version is Windows XP (0x0501).
+ * Leave a higher value in place. When building with Visual Studio the
+ * minimum requirement is Windows Vista (0x0600) to get support for
+ * GetLocaleInfoEx() with locales. For everything else the minimum
+ * version is Windows XP (0x0501).
  */
-#if defined(_MSC_VER) && _MSC_VER >= 1900
+#ifdef _MSC_VER
 #define MIN_WINNT 0x0600
 #else
 #define MIN_WINNT 0x0501
diff --git a/src/include/port/win32_port.h b/src/include/port/win32_port.h
index dbbf88f8e8..c0225603f2 100644
--- a/src/include/port/win32_port.h
+++ b/src/include/port/win32_port.h
@@ -531,13 +531,8 @@ typedef unsigned short mode_t;
 
 #endif							/* _MSC_VER */
 
-#if (defined(_MSC_VER) && (_MSC_VER < 1900)) || \
-	defined(__MINGW32__) || defined(__MINGW64__)
+#if  defined(__MINGW32__) || defined(__MINGW64__)
 /*
- * VS2013 has a strtof() that seems to give correct answers for valid input,
- * even on the rounding edge cases, but which doesn't handle out-of-range
- * input correctly. Work around that.
- *
  * Mingw claims to have a strtof, and my reading of its source code suggests
  * that it ought to work (and not need this hack), but the regression test
  * results disagree with me; whether this is a version issue or not is not
diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index c43a527d3f..bb782fa1ec 100644
--- a/src/backend/main/main.c
+++ b/src/backend/main/main.c
@@ -30,11 +30,6 @@
 #include <sys/param.h>
 #endif
 
-#if defined(_M_AMD64) && _MSC_VER == 1800
-#include <math.h>
-#include <versionhelpers.h>
-#endif
-
 #include "bootstrap/bootstrap.h"
 #include "common/username.h"
 #include "port/atomics.h"
@@ -290,23 +285,6 @@ startup_hacks(const char *progname)
 		_CrtSetReportFile(_CRT_ASSERT, _CRTDBG_FILE_STDERR);
 		_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
 		_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDERR);
-
-#if defined(_M_AMD64) && _MSC_VER == 1800
-
-		/*----------
-		 * Avoid crashing in certain floating-point operations if we were
-		 * compiled for x64 with MS Visual Studio 2013 and are running on
-		 * Windows prior to 7/2008R2 SP1 on an AVX2-capable CPU.
-		 *
-		 * Ref: https://connect.microsoft.com/VisualStudio/feedback/details/811093/visual-studio-2013-rtm-c-x64-code-generation-bug-for-avx2-instructions
-		 *----------
-		 */
-		if (!IsWindows7SP1OrGreater())
-		{
-			_set_FMA3_enable(0);
-		}
-#endif							/* defined(_M_AMD64) && _MSC_VER == 1800 */
-
 	}
 #endif							/* WIN32 */
 
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index 63bb0f2277..fc8f39a7a9 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -249,13 +249,9 @@ float4in(PG_FUNCTION_ARGS)
 			 * precision).  We'd prefer not to throw error for that, so try to
 			 * detect whether it's a "real" out-of-range condition by checking
 			 * to see if the result is zero or huge.
-			 *
-			 * Use isinf() rather than HUGE_VALF on VS2013 because it
-			 * generates a spurious overflow warning for -HUGE_VALF.  Also use
-			 * isinf() if HUGE_VALF is missing.
 			 */
 			if (val == 0.0 ||
-#if !defined(HUGE_VALF) || (defined(_MSC_VER) && (_MSC_VER < 1900))
+#if !defined(HUGE_VALF)
 				isinf(val)
 #else
 				(val >= HUGE_VALF || val <= -HUGE_VALF)
diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c
index a0490a7522..34bd8d424e 100644
--- a/src/backend/utils/adt/pg_locale.c
+++ b/src/backend/utils/adt/pg_locale.c
@@ -960,7 +960,6 @@ cache_locale_time(void)
  * [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
  */
 
-#if _MSC_VER >= 1900
 /*
  * Callback function for EnumSystemLocalesEx() in get_iso_localename().
  *
@@ -1110,7 +1109,6 @@ get_iso_localename(const char *winlocname)
 
 	return NULL;
 }
-#endif							/* _MSC_VER >= 1900 */
 
 static char *
 IsoLocaleName(const char *winlocname)
@@ -1125,46 +1123,8 @@ IsoLocaleName(const char *winlocname)
 		return iso_lc_messages;
 	}
 	else
-	{
-#if (_MSC_VER >= 1900)			/* Visual Studio 2015 or later */
 		return get_iso_localename(winlocname);
-#else
-		_locale_t	loct;
 
-		loct = _create_locale(LC_CTYPE, winlocname);
-		if (loct != NULL)
-		{
-			size_t		rc;
-			char	   *hyphen;
-
-			/* Locale names use only ASCII, any conversion locale suffices. */
-			rc = wchar2char(iso_lc_messages, loct->locinfo->locale_name[LC_CTYPE],
-							sizeof(iso_lc_messages), NULL);
-			_free_locale(loct);
-			if (rc == -1 || rc == sizeof(iso_lc_messages))
-				return NULL;
-
-			/*
-			 * Since the message catalogs sit on a case-insensitive
-			 * filesystem, we need not standardize letter case here.  So long
-			 * as we do not ship message catalogs for which it would matter,
-			 * we also need not translate the script/variant portion, e.g.
-			 * uz-Cyrl-UZ to uz_UZ@cyrillic.  Simply replace the hyphen with
-			 * an underscore.
-			 *
-			 * Note that the locale name can be less-specific than the value
-			 * we would derive under earlier Visual Studio releases.  For
-			 * example, French_France.1252 yields just "fr".  This does not
-			 * affect any of the country-specific message catalogs available
-			 * as of this writing (pt_BR, zh_CN, zh_TW).
-			 */
-			hyphen = strchr(iso_lc_messages, '-');
-			if (hyphen)
-				*hyphen = '_';
-			return iso_lc_messages;
-		}
-#endif							/* Visual Studio 2015 or later */
-	}
 #endif							/* defined(_MSC_VER) */
 	return NULL;				/* Not supported on this version of msvc/mingw */
 }
diff --git a/src/port/chklocale.c b/src/port/chklocale.c
index c85d8da3c8..fdb137640c 100644
--- a/src/port/chklocale.c
+++ b/src/port/chklocale.c
@@ -211,22 +211,9 @@ static char *
 win32_langinfo(const char *ctype)
 {
 	char	   *r = NULL;
-
-#if defined(_MSC_VER) && (_MSC_VER < 1900)
-	_locale_t	loct = NULL;
-
-	loct = _create_locale(LC_CTYPE, ctype);
-	if (loct != NULL)
-	{
-		r = malloc(16);			/* excess */
-		if (r != NULL)
-			sprintf(r, "CP%u", loct->locinfo->lc_codepage);
-		_free_locale(loct);
-	}
-#else
 	char	   *codepage;
 
-#if defined(_MSC_VER) && (_MSC_VER >= 1900)
+#if defined(_MSC_VER)
 	uint32		cp;
 	WCHAR		wctype[LOCALE_NAME_MAX_LENGTH];
 
@@ -279,7 +266,6 @@ win32_langinfo(const char *ctype)
 			}
 		}
 	}
-#endif
 
 	return r;
 }
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index bcfd5a1a10..ef30e797e3 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
   <productname>Windows</productname>. The simplest way to build with
   Microsoft tools is to install <productname>Visual Studio 2022</productname>
   and use the included compiler. It is also possible to build with the full
-  <productname>Microsoft Visual C++ 2013 to 2022</productname>.
+  <productname>Microsoft Visual C++ 2015 to 2022</productname>.
   In some cases that requires the installation of the
   <productname>Windows SDK</productname> in addition to the compiler.
  </para>
@@ -77,19 +77,17 @@
  <para>
   Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
   32-bit PostgreSQL builds are possible with
-  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2015</productname> to
   <productname>Visual Studio 2022</productname>,
   as well as standalone Windows SDK releases 8.1a to 10.
   64-bit PostgreSQL builds are supported with
   <productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
-  <productname>Visual Studio 2013</productname> and above. Compilation
+  <productname>Visual Studio 2015</productname> and above. Compilation
   is supported down to <productname>Windows 7</productname> and
   <productname>Windows Server 2008 R2 SP1</productname> when building with
-  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2015</productname> to
   <productname>Visual Studio 2022</productname>.
    <!--
-       For 2013 requirements:
-       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
        For 2015 requirements:
        https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
        For 2017 requirements:
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index f24d9e5348..62acdda3a1 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -4,7 +4,7 @@
 package MSBuildProject;
 
 #
-# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2015 or greater)
 #
 # src/tools/msvc/MSBuildProject.pm
 #
@@ -405,31 +405,6 @@ EOF
 	return;
 }
 
-package VC2013Project;
-
-#
-# Package that encapsulates a Visual C++ 2013 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver}           = '12.00';
-	$self->{PlatformToolset} = 'v120';
-	$self->{ToolsVersion}    = '12.0';
-
-	return $self;
-}
-
 package VC2015Project;
 
 #
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index 473d6f425b..1c36925258 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
 ==========
 
 This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
+Microsoft Visual Studio 2015 - 2022. This builds the whole backend, not just
 the libpq frontend library. For more information, see the documentation
 chapter "Installation on Windows" and the description below.
 
@@ -67,7 +67,7 @@ Install.pm             module containing the install logic
 Mkvcbuild.pm           module containing the code to generate the Visual
                        Studio build (project/solution) files
 MSBuildProject.pm      module containing the code to generate MSBuild based
-                       project files (Visual Studio 2013 or greater)
+                       project files (Visual Studio 2015 or greater)
 Project.pm             module containing the common code to generate the
                        Visual Studio project files. Also provides the
                        common interface of all project file generators
@@ -88,10 +88,10 @@ config_default.pl to create the configuration arguments.
 These configuration arguments are passed over to Mkvcbuild::mkvcbuild
 (Mkvcbuild.pm) which creates the Visual Studio project and solution files.
 It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either VS2013Solution,
+implementing the Solution interface (this could be either
 VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in
 Solution.pm, depending on the user's build environment) and adding objects
-implementing the corresponding Project interface (VC2013Project,
+implementing the corresponding Project interface (
 VC2015Project, VC2017Project, VC2019Project or VC2022Project from
 MSBuildProject.pm) to it. When Solution::Save is called, the implementations
 of Solution and Project save their content in the appropriate format.
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index d30e8fcb11..a4a2c637ff 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -1218,34 +1218,6 @@ sub GetFakeConfigure
 	return $cfg;
 }
 
-package VS2013Solution;
-
-#
-# Package that encapsulates a Visual Studio 2013 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion}        = '12.00';
-	$self->{vcver}                      = '12.00';
-	$self->{visualStudioName}           = 'Visual Studio 2013';
-	$self->{VisualStudioVersion}        = '12.0.21005.1';
-	$self->{MinimumVisualStudioVersion} = '10.0.40219.1';
-
-	return $self;
-}
-
 package VS2015Solution;
 
 #
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 9f9712b793..975ccf2ee5 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -33,11 +33,7 @@ sub CreateSolution
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '12.00')
-	{
-		return new VS2013Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '14.00')
+	if ($visualStudioVersion eq '14.00')
 	{
 		return new VS2015Solution(@_);
 	}
@@ -87,11 +83,7 @@ sub CreateProject
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '12.00')
-	{
-		return new VC2013Project(@_);
-	}
-	elsif ($visualStudioVersion eq '14.00')
+	if ($visualStudioVersion eq '14.00')
 	{
 		return new VC2015Project(@_);
 	}
-- 
2.36.0

#2Thomas Munro
thomas.munro@gmail.com
In reply to: Michael Paquier (#1)
Re: Remove support for Visual Studio 2013

On Mon, May 16, 2022 at 6:58 PM Michael Paquier <michael@paquier.xyz> wrote:

Cutting support for now-unsupported versions of Windows is in the air
for a couple of months, and while looking at the code a first cleanup
that looked rather obvious to me is the removal of support for VS
2013, as of something to do for v16~.

Not a Windows person so I couldn't comment on the details without more
research, but this general concept seems good to me. That's a nice
reduction in (practically) untestable/dead code (no CI, no build
farm).

For comparison, I picked 3 random C/C++ (OK, C++) projects I could
think of to see how they deal with VS versions, and all require 2017+:

* MariaDB supports the last two major versions, so currently VS 2019
and VS 2022, 2022 is preferred[1]https://mariadb.com/kb/en/Building_MariaDB_on_Windows/
* Chrome requires VS 2017+ but currently 2019 is preferred[2]https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#Visual-Studio
* OpenJDK requires VS 2017+[3]https://openjdk.java.net/groups/build/doc/building.html

Looking at the published lifecycle info, 2017 is the oldest still in
'mainstream' support[4]https://docs.microsoft.com/en-us/visualstudio/productinfo/vs-servicing, so it wouldn't be too crazy to drop VS 2015
too, just like those other projects. That said, it sounds like there
is no practical benefit to being more aggressive than you are
suggesting currently (as in, we wouldn't get to delete any more crufty
untestable dead code by dropping 2015, right?), so maybe that'd be
enough for now.

[1]: https://mariadb.com/kb/en/Building_MariaDB_on_Windows/
[2]: https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#Visual-Studio
[3]: https://openjdk.java.net/groups/build/doc/building.html
[4]: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs-servicing

#3Michael Paquier
michael@paquier.xyz
In reply to: Thomas Munro (#2)
Re: Remove support for Visual Studio 2013

On Mon, May 16, 2022 at 08:46:31PM +1200, Thomas Munro wrote:

Looking at the published lifecycle info, 2017 is the oldest still in
'mainstream' support[4], so it wouldn't be too crazy to drop VS 2015
too, just like those other projects. That said, it sounds like there
is no practical benefit to being more aggressive than you are
suggesting currently (as in, we wouldn't get to delete any more crufty
untestable dead code by dropping 2015, right?), so maybe that'd be
enough for now.

FWIW, one of my environments is using VS2015, because I have set it up
years ago and I am lazy to do this setup except if I really have to :)

The code works as far as I know, still I am not really excited about
cutting support for more versions than necessary, particularly as this
does not simplify the C code more.
--
Michael

#4Andrew Dunstan
andrew@dunslane.net
In reply to: Michael Paquier (#3)
Re: Remove support for Visual Studio 2013

On 2022-05-16 Mo 06:34, Michael Paquier wrote:

On Mon, May 16, 2022 at 08:46:31PM +1200, Thomas Munro wrote:

Looking at the published lifecycle info, 2017 is the oldest still in
'mainstream' support[4], so it wouldn't be too crazy to drop VS 2015
too, just like those other projects. That said, it sounds like there
is no practical benefit to being more aggressive than you are
suggesting currently (as in, we wouldn't get to delete any more crufty
untestable dead code by dropping 2015, right?), so maybe that'd be
enough for now.

FWIW, one of my environments is using VS2015, because I have set it up
years ago and I am lazy to do this setup except if I really have to :)

The code works as far as I know, still I am not really excited about
cutting support for more versions than necessary, particularly as this
does not simplify the C code more.

Yeah, I'm ok with this. The only older version I have is currawong, but
it runs on NT and so only builds release 10 and will probably be retired
around the end of the year.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#3)
Re: Remove support for Visual Studio 2013

Michael Paquier <michael@paquier.xyz> writes:

On Mon, May 16, 2022 at 08:46:31PM +1200, Thomas Munro wrote:

Looking at the published lifecycle info, 2017 is the oldest still in
'mainstream' support[4], so it wouldn't be too crazy to drop VS 2015
too, just like those other projects. That said, it sounds like there
is no practical benefit to being more aggressive than you are
suggesting currently (as in, we wouldn't get to delete any more crufty
untestable dead code by dropping 2015, right?), so maybe that'd be
enough for now.

FWIW, one of my environments is using VS2015, because I have set it up
years ago and I am lazy to do this setup except if I really have to :)

The code works as far as I know, still I am not really excited about
cutting support for more versions than necessary, particularly as this
does not simplify the C code more.

The argument about removing untested code doesn't apply if there is
no code to remove, so it seems like continuing to support VS2015 is
reasonable. Of course, if anyone came and complained that it's broken,
we'd probably just drop the support claim ...

regards, tom lane

#6Juan José Santamaría Flecha
juanjo.santamaria@gmail.com
In reply to: Michael Paquier (#1)
1 attachment(s)
Re: Remove support for Visual Studio 2013

On Mon, May 16, 2022 at 8:58 AM Michael Paquier <michael@paquier.xyz> wrote:

The patch attached cleans up the following things proper to VS 2013:
- Locale handling.
- MIN_WINNT assignment.
- Some strtof() business, as of win32_port.h.
- Removal of _set_FMA3_enable() in main.c related to floating-point
operations.
- MSVC scripts, but that's less interesting considering the work done
with meson.

When building on MinGW with NLS enabled I get some errors:

c:/cirrus/src/backend/utils/adt/pg_locale.c: In function
'search_locale_enum':
c:/cirrus/src/backend/utils/adt/pg_locale.c:989:13: warning: implicit
declaration of function 'GetLocaleInfoEx'; did you mean 'GetLocaleInfoA'?
[-Wimplicit-function-declaration]
989 | if (GetLocaleInfoEx(pStr, LOCALE_SENGLISHLANGUAGENAME,
| ^~~~~~~~~~~~~~~
| GetLocaleInfoA

This is because current MinGW defaults to Windows 2003 [1]https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/sdkddkver.h, maybe we should
fix Windows' minimal version to Vista (0x0600) unconditionally also. I have
seen a couple of compilation warnings while testing that setting on MinGW,
please find attached a patch for so.

[1]: https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/sdkddkver.h
https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/sdkddkver.h

Regards,

Juan José Santamaría Flecha

Attachments:

0001-MinGW-Windows-Vista-Warnings.patchapplication/octet-stream; name=0001-MinGW-Windows-Vista-Warnings.patchDownload
diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c
index a0490a7..5595760 100644
--- a/src/backend/utils/adt/pg_locale.c
+++ b/src/backend/utils/adt/pg_locale.c
@@ -1757,7 +1757,7 @@ get_collation_actual_version(char collprovider, const char *collcollate)
 							collcollate,
 							GetLastError())));
 		}
-		collversion = psprintf("%d.%d,%d.%d",
+		collversion = psprintf("%ld.%ld,%ld.%ld",
 							   (version.dwNLSVersion >> 8) & 0xFFFF,
 							   version.dwNLSVersion & 0xFF,
 							   (version.dwDefinedVersion >> 8) & 0xFFFF,
#7Michael Paquier
michael@paquier.xyz
In reply to: Juan José Santamaría Flecha (#6)
Re: Remove support for Visual Studio 2013

On Tue, May 17, 2022 at 06:26:20PM +0200, Juan José Santamaría Flecha wrote:

This is because current MinGW defaults to Windows 2003 [1], maybe we should
fix Windows' minimal version to Vista (0x0600) unconditionally also. I have
seen a couple of compilation warnings while testing that setting on MinGW,
please find attached a patch for so.

[1]
https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/sdkddkver.h

Ah, right. I have forgotten about this business with MinGW.

@@ -1757,7 +1757,7 @@ get_collation_actual_version(char collprovider, const char *collcollate)
                             collcollate,
                             GetLastError())));
         }
-        collversion = psprintf("%d.%d,%d.%d",
+        collversion = psprintf("%ld.%ld,%ld.%ld",
                                (version.dwNLSVersion >> 8) & 0xFFFF,
                                version.dwNLSVersion & 0xFF,
                                (version.dwDefinedVersion >> 8) & 0xFFFF,

Is this change still required even if we bump MIN_WINNT to 0x0600 for
all the environments that include win32.h? At the end, this would
mean dropping support for Windows XP and Windows Server 2003 as
run-time environments as listed in [1]https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 -- Michael, which are not supported
officially since 2014 (even if there have been some patches for
some critical issues). So I'd be fine to raise the bar for v16~,
particularly as this would allow us to get rid of this code related to
locales.

[1]: https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 -- Michael
--
Michael

#8Juan José Santamaría Flecha
juanjo.santamaria@gmail.com
In reply to: Michael Paquier (#7)
Re: Remove support for Visual Studio 2013

On Wed, May 18, 2022 at 2:27 AM Michael Paquier <michael@paquier.xyz> wrote:

@@ -1757,7 +1757,7 @@ get_collation_actual_version(char collprovider,
const char *collcollate)
collcollate,
GetLastError())));
}
-        collversion = psprintf("%d.%d,%d.%d",
+        collversion = psprintf("%ld.%ld,%ld.%ld",
(version.dwNLSVersion >> 8) & 0xFFFF,
version.dwNLSVersion & 0xFF,
(version.dwDefinedVersion >> 8) & 0xFFFF,

Is this change still required even if we bump MIN_WINNT to 0x0600 for
all the environments that include win32.h?

Right now we are ifdefing that code out for MinGW, so it's not a visible
issue, but it'll be when we do.

At the end, this would
mean dropping support for Windows XP and Windows Server 2003 as
run-time environments as listed in [1], which are not supported
officially since 2014 (even if there have been some patches for
some critical issues). So I'd be fine to raise the bar for v16~,
particularly as this would allow us to get rid of this code related to
locales.

Even Windows Server 2008 [1]https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-server-eos-faq/end-of-support-windows-server-2008-2008r2 is at its End of Life, so this should surprise
no one.

[1]: https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-server-eos-faq/end-of-support-windows-server-2008-2008r2
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-server-eos-faq/end-of-support-windows-server-2008-2008r2

Regards,

Juan José Santamaría Flecha

Show quoted text
#9Michael Paquier
michael@paquier.xyz
In reply to: Juan José Santamaría Flecha (#8)
Re: Remove support for Visual Studio 2013

On Wed, May 18, 2022 at 10:06:50AM +0200, Juan José Santamaría Flecha wrote:

Right now we are ifdefing that code out for MinGW, so it's not a visible
issue, but it'll be when we do.

OK. Thanks, got it.
--
Michael

#10Michael Paquier
michael@paquier.xyz
In reply to: Juan José Santamaría Flecha (#8)
Re: Remove support for Visual Studio 2013

On Wed, May 18, 2022 at 10:06:50AM +0200, Juan José Santamaría Flecha wrote:

On Wed, May 18, 2022 at 2:27 AM Michael Paquier <michael@paquier.xyz> wrote:

At the end, this would
mean dropping support for Windows XP and Windows Server 2003 as
run-time environments as listed in [1], which are not supported
officially since 2014 (even if there have been some patches for
some critical issues). So I'd be fine to raise the bar for v16~,
particularly as this would allow us to get rid of this code related to
locales.

Even Windows Server 2008 [1] is at its End of Life, so this should surprise
no one.

[1]
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-server-eos-faq/end-of-support-windows-server-2008-2008r2

Btw, I am going to spawn a new thread for this specific change rather
than forcing people to dig into this one as it is independent. Better
to do that a bit in advance of the development cycle for v16, as it
is usually good to clean up such things sooner than later..
--
Michael

#11Justin Pryzby
pryzby@telsasoft.com
In reply to: Michael Paquier (#1)
Re: Remove support for Visual Studio 2013

Maybe consider removing this workaround? The original problem report indicated
that it didn't affect later versions:

src/backend/optimizer/path/costsize.c: /* This apparently-useless variable dodges a compiler bug in VS2013: */

I'm not sure if it's worth removing this one, though:

src/port/strtof.c: * On Windows, there's a slightly different problem: VS2013 has a strtof()

#12Michael Paquier
michael@paquier.xyz
In reply to: Justin Pryzby (#11)
Re: Remove support for Visual Studio 2013

On Thu, May 26, 2022 at 10:43:11AM -0500, Justin Pryzby wrote:

Ah, thanks. I forgot to grep for those patterns. Good catches.

Maybe consider removing this workaround? The original problem report indicated
that it didn't affect later versions:

src/backend/optimizer/path/costsize.c: /* This apparently-useless variable dodges a compiler bug in VS2013: */

Hence reverting 3154e16. Sure!

I'm not sure if it's worth removing this one, though:

src/port/strtof.c: * On Windows, there's a slightly different problem: VS2013 has a strtof()

Yeah.. I am not completely sure if all the patterns mentioned for
VS2013 apply to Cygwin/Mingw, so keeping it around could be more
beneficial.
--
Michael

#13Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#12)
Re: Remove support for Visual Studio 2013

Michael Paquier <michael@paquier.xyz> writes:

On Thu, May 26, 2022 at 10:43:11AM -0500, Justin Pryzby wrote:

Maybe consider removing this workaround? The original problem report indicated
that it didn't affect later versions:

src/backend/optimizer/path/costsize.c: /* This apparently-useless variable dodges a compiler bug in VS2013: */

Hence reverting 3154e16. Sure!

+1

I'm not sure if it's worth removing this one, though:

src/port/strtof.c: * On Windows, there's a slightly different problem: VS2013 has a strtof()

Yeah.. I am not completely sure if all the patterns mentioned for
VS2013 apply to Cygwin/Mingw, so keeping it around could be more
beneficial.

The comments about that in win32_port.h and cygwin.h only date back
to 2019, so it seems unlikely that the situation has changed much.
We could try removing HAVE_BUGGY_STRTOF to see if the buildfarm
complains, but I wouldn't bet money on that succeeding. What we
*do* need to do is update the #if tests and comments to make clear
that HAVE_BUGGY_STRTOF is only needed for Mingw and Cygwin, not
for any supported MSVC release.

regards, tom lane

#14Michael Paquier
michael@paquier.xyz
In reply to: Tom Lane (#13)
1 attachment(s)
Re: Remove support for Visual Studio 2013

On Thu, May 26, 2022 at 05:50:40PM -0400, Tom Lane wrote:

The comments about that in win32_port.h and cygwin.h only date back
to 2019, so it seems unlikely that the situation has changed much.
We could try removing HAVE_BUGGY_STRTOF to see if the buildfarm
complains, but I wouldn't bet money on that succeeding. What we
*do* need to do is update the #if tests and comments to make clear
that HAVE_BUGGY_STRTOF is only needed for Mingw and Cygwin, not
for any supported MSVC release.

After looking at that again, the whole comment related to VS in
strtof.c can be removed. I have noticed while on it more places that
still referred to VS2013 in ./configure[.ac] and win32_langinfo() got
an overall incorrect description. This leads to v2 as of the
attached.
--
Michael

Attachments:

v2-0001-Remove-support-for-VS-2013.patchtext/x-diff; charset=us-asciiDownload
From 86b838c70b30998a981f6e53cacb0885963eda66 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Mon, 30 May 2022 16:44:22 +0900
Subject: [PATCH v2] Remove support for VS 2013

---
 src/include/port/win32.h              | 10 +++----
 src/include/port/win32_port.h         |  7 +----
 src/backend/main/main.c               | 22 ---------------
 src/backend/optimizer/path/costsize.c |  4 +--
 src/backend/utils/adt/float.c         |  6 +---
 src/backend/utils/adt/pg_locale.c     | 40 ---------------------------
 src/port/chklocale.c                  | 33 ++++------------------
 src/port/strtof.c                     |  9 ------
 doc/src/sgml/install-windows.sgml     | 10 +++----
 configure                             |  7 ++---
 configure.ac                          |  7 ++---
 src/tools/msvc/MSBuildProject.pm      | 27 +-----------------
 src/tools/msvc/README                 |  8 +++---
 src/tools/msvc/Solution.pm            | 28 -------------------
 src/tools/msvc/VSObjectFactory.pm     | 12 ++------
 15 files changed, 30 insertions(+), 200 deletions(-)

diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index c6213c77c3..539f3ec6d1 100644
--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -11,12 +11,12 @@
 
 /*
  * Make sure _WIN32_WINNT has the minimum required value.
- * Leave a higher value in place. When building with at least Visual
- * Studio 2015 the minimum requirement is Windows Vista (0x0600) to
- * get support for GetLocaleInfoEx() with locales. For everything else
- * the minimum version is Windows XP (0x0501).
+ * Leave a higher value in place. When building with Visual Studio the
+ * minimum requirement is Windows Vista (0x0600) to get support for
+ * GetLocaleInfoEx() with locales. For everything else the minimum
+ * version is Windows XP (0x0501).
  */
-#if defined(_MSC_VER) && _MSC_VER >= 1900
+#ifdef _MSC_VER
 #define MIN_WINNT 0x0600
 #else
 #define MIN_WINNT 0x0501
diff --git a/src/include/port/win32_port.h b/src/include/port/win32_port.h
index dbbf88f8e8..c0225603f2 100644
--- a/src/include/port/win32_port.h
+++ b/src/include/port/win32_port.h
@@ -531,13 +531,8 @@ typedef unsigned short mode_t;
 
 #endif							/* _MSC_VER */
 
-#if (defined(_MSC_VER) && (_MSC_VER < 1900)) || \
-	defined(__MINGW32__) || defined(__MINGW64__)
+#if  defined(__MINGW32__) || defined(__MINGW64__)
 /*
- * VS2013 has a strtof() that seems to give correct answers for valid input,
- * even on the rounding edge cases, but which doesn't handle out-of-range
- * input correctly. Work around that.
- *
  * Mingw claims to have a strtof, and my reading of its source code suggests
  * that it ought to work (and not need this hack), but the regression test
  * results disagree with me; whether this is a version issue or not is not
diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index c43a527d3f..bb782fa1ec 100644
--- a/src/backend/main/main.c
+++ b/src/backend/main/main.c
@@ -30,11 +30,6 @@
 #include <sys/param.h>
 #endif
 
-#if defined(_M_AMD64) && _MSC_VER == 1800
-#include <math.h>
-#include <versionhelpers.h>
-#endif
-
 #include "bootstrap/bootstrap.h"
 #include "common/username.h"
 #include "port/atomics.h"
@@ -290,23 +285,6 @@ startup_hacks(const char *progname)
 		_CrtSetReportFile(_CRT_ASSERT, _CRTDBG_FILE_STDERR);
 		_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
 		_CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDERR);
-
-#if defined(_M_AMD64) && _MSC_VER == 1800
-
-		/*----------
-		 * Avoid crashing in certain floating-point operations if we were
-		 * compiled for x64 with MS Visual Studio 2013 and are running on
-		 * Windows prior to 7/2008R2 SP1 on an AVX2-capable CPU.
-		 *
-		 * Ref: https://connect.microsoft.com/VisualStudio/feedback/details/811093/visual-studio-2013-rtm-c-x64-code-generation-bug-for-avx2-instructions
-		 *----------
-		 */
-		if (!IsWindows7SP1OrGreater())
-		{
-			_set_FMA3_enable(0);
-		}
-#endif							/* defined(_M_AMD64) && _MSC_VER == 1800 */
-
 	}
 #endif							/* WIN32 */
 
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index fcc26b01a4..5e5732f6e1 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -5445,10 +5445,8 @@ calc_joinrel_size_estimate(PlannerInfo *root,
 						   double outer_rows,
 						   double inner_rows,
 						   SpecialJoinInfo *sjinfo,
-						   List *restrictlist_in)
+						   List *restrictlist)
 {
-	/* This apparently-useless variable dodges a compiler bug in VS2013: */
-	List	   *restrictlist = restrictlist_in;
 	JoinType	jointype = sjinfo->jointype;
 	Selectivity fkselec;
 	Selectivity jselec;
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index 63bb0f2277..fc8f39a7a9 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -249,13 +249,9 @@ float4in(PG_FUNCTION_ARGS)
 			 * precision).  We'd prefer not to throw error for that, so try to
 			 * detect whether it's a "real" out-of-range condition by checking
 			 * to see if the result is zero or huge.
-			 *
-			 * Use isinf() rather than HUGE_VALF on VS2013 because it
-			 * generates a spurious overflow warning for -HUGE_VALF.  Also use
-			 * isinf() if HUGE_VALF is missing.
 			 */
 			if (val == 0.0 ||
-#if !defined(HUGE_VALF) || (defined(_MSC_VER) && (_MSC_VER < 1900))
+#if !defined(HUGE_VALF)
 				isinf(val)
 #else
 				(val >= HUGE_VALF || val <= -HUGE_VALF)
diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c
index a0490a7522..34bd8d424e 100644
--- a/src/backend/utils/adt/pg_locale.c
+++ b/src/backend/utils/adt/pg_locale.c
@@ -960,7 +960,6 @@ cache_locale_time(void)
  * [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
  */
 
-#if _MSC_VER >= 1900
 /*
  * Callback function for EnumSystemLocalesEx() in get_iso_localename().
  *
@@ -1110,7 +1109,6 @@ get_iso_localename(const char *winlocname)
 
 	return NULL;
 }
-#endif							/* _MSC_VER >= 1900 */
 
 static char *
 IsoLocaleName(const char *winlocname)
@@ -1125,46 +1123,8 @@ IsoLocaleName(const char *winlocname)
 		return iso_lc_messages;
 	}
 	else
-	{
-#if (_MSC_VER >= 1900)			/* Visual Studio 2015 or later */
 		return get_iso_localename(winlocname);
-#else
-		_locale_t	loct;
 
-		loct = _create_locale(LC_CTYPE, winlocname);
-		if (loct != NULL)
-		{
-			size_t		rc;
-			char	   *hyphen;
-
-			/* Locale names use only ASCII, any conversion locale suffices. */
-			rc = wchar2char(iso_lc_messages, loct->locinfo->locale_name[LC_CTYPE],
-							sizeof(iso_lc_messages), NULL);
-			_free_locale(loct);
-			if (rc == -1 || rc == sizeof(iso_lc_messages))
-				return NULL;
-
-			/*
-			 * Since the message catalogs sit on a case-insensitive
-			 * filesystem, we need not standardize letter case here.  So long
-			 * as we do not ship message catalogs for which it would matter,
-			 * we also need not translate the script/variant portion, e.g.
-			 * uz-Cyrl-UZ to uz_UZ@cyrillic.  Simply replace the hyphen with
-			 * an underscore.
-			 *
-			 * Note that the locale name can be less-specific than the value
-			 * we would derive under earlier Visual Studio releases.  For
-			 * example, French_France.1252 yields just "fr".  This does not
-			 * affect any of the country-specific message catalogs available
-			 * as of this writing (pt_BR, zh_CN, zh_TW).
-			 */
-			hyphen = strchr(iso_lc_messages, '-');
-			if (hyphen)
-				*hyphen = '_';
-			return iso_lc_messages;
-		}
-#endif							/* Visual Studio 2015 or later */
-	}
 #endif							/* defined(_MSC_VER) */
 	return NULL;				/* Not supported on this version of msvc/mingw */
 }
diff --git a/src/port/chklocale.c b/src/port/chklocale.c
index c85d8da3c8..2aaf2ae8c0 100644
--- a/src/port/chklocale.c
+++ b/src/port/chklocale.c
@@ -191,19 +191,10 @@ static const struct encoding_match encoding_match_list[] = {
 /*
  * On Windows, use CP<code page number> instead of the nl_langinfo() result
  *
- * Visual Studio 2012 expanded the set of valid LC_CTYPE values, so have its
- * locale machinery determine the code page.  See comments at IsoLocaleName().
- * For other compilers, follow the locale's predictable format.
- *
- * Visual Studio 2015 should still be able to do the same, but the declaration
- * of lc_codepage is missing in _locale_t, causing this code compilation to
- * fail, hence this falls back instead on GetLocaleInfoEx. VS 2015 may be an
- * exception and post-VS2015 versions should be able to handle properly the
- * codepage number using _create_locale(). So, instead of the same logic as
- * VS 2012 and VS 2013, this routine uses GetLocaleInfoEx to parse short
- * locale names like "de-DE", "fr-FR", etc. If those cannot be parsed correctly
- * process falls back to the pre-VS-2010 manual parsing done with
- * using <Language>_<Country>.<CodePage> as a base.
+ * This routine uses GetLocaleInfoEx() to parse short locale names like
+ * "de-DE", "fr-FR", etc.  If those cannot be parsed correctly process falls
+ * back to the pre-VS-2010 manual parsing done with using
+ * <Language>_<Country>.<CodePage> as a base.
  *
  * Returns a malloc()'d string for the caller to free.
  */
@@ -211,22 +202,9 @@ static char *
 win32_langinfo(const char *ctype)
 {
 	char	   *r = NULL;
-
-#if defined(_MSC_VER) && (_MSC_VER < 1900)
-	_locale_t	loct = NULL;
-
-	loct = _create_locale(LC_CTYPE, ctype);
-	if (loct != NULL)
-	{
-		r = malloc(16);			/* excess */
-		if (r != NULL)
-			sprintf(r, "CP%u", loct->locinfo->lc_codepage);
-		_free_locale(loct);
-	}
-#else
 	char	   *codepage;
 
-#if defined(_MSC_VER) && (_MSC_VER >= 1900)
+#if defined(_MSC_VER)
 	uint32		cp;
 	WCHAR		wctype[LOCALE_NAME_MAX_LENGTH];
 
@@ -279,7 +257,6 @@ win32_langinfo(const char *ctype)
 			}
 		}
 	}
-#endif
 
 	return r;
 }
diff --git a/src/port/strtof.c b/src/port/strtof.c
index 7da05be687..314fcc9851 100644
--- a/src/port/strtof.c
+++ b/src/port/strtof.c
@@ -54,15 +54,6 @@ strtof(const char *nptr, char **endptr)
 
 #elif HAVE_BUGGY_STRTOF
 /*
- * On Windows, there's a slightly different problem: VS2013 has a strtof()
- * that returns the correct results for valid input, but may fail to report an
- * error for underflow or overflow, returning 0 instead. Work around that by
- * trying strtod() when strtof() returns 0.0 or [+-]Inf, and calling it an
- * error if the result differs. Also, strtof() doesn't handle subnormal input
- * well, so prefer to round the strtod() result in such cases. (Normally we'd
- * just say "too bad" if strtof() doesn't support subnormals, but since we're
- * already in here fixing stuff, we might as well do the best fix we can.)
- *
  * Cygwin has a strtof() which is literally just (float)strtod(), which means
  * we can't avoid the double-rounding problem; but using this wrapper does get
  * us proper over/underflow checks. (Also, if they fix their strtof(), the
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index bcfd5a1a10..ef30e797e3 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
   <productname>Windows</productname>. The simplest way to build with
   Microsoft tools is to install <productname>Visual Studio 2022</productname>
   and use the included compiler. It is also possible to build with the full
-  <productname>Microsoft Visual C++ 2013 to 2022</productname>.
+  <productname>Microsoft Visual C++ 2015 to 2022</productname>.
   In some cases that requires the installation of the
   <productname>Windows SDK</productname> in addition to the compiler.
  </para>
@@ -77,19 +77,17 @@
  <para>
   Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
   32-bit PostgreSQL builds are possible with
-  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2015</productname> to
   <productname>Visual Studio 2022</productname>,
   as well as standalone Windows SDK releases 8.1a to 10.
   64-bit PostgreSQL builds are supported with
   <productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
-  <productname>Visual Studio 2013</productname> and above. Compilation
+  <productname>Visual Studio 2015</productname> and above. Compilation
   is supported down to <productname>Windows 7</productname> and
   <productname>Windows Server 2008 R2 SP1</productname> when building with
-  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2015</productname> to
   <productname>Visual Studio 2022</productname>.
    <!--
-       For 2013 requirements:
-       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
        For 2015 requirements:
        https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
        For 2017 requirements:
diff --git a/configure b/configure
index 7dec6b7bf9..e77fa2ca34 100755
--- a/configure
+++ b/configure
@@ -16909,10 +16909,9 @@ fi
 
 if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
 	# Cygwin and (apparently, based on test results) Mingw both
-	# have a broken strtof(), so substitute the same replacement
-	# code we use with VS2013. That's not a perfect fix, since
-	# (unlike with VS2013) it doesn't avoid double-rounding, but
-	# we have no better options. To get that, though, we have to
+	# have a broken strtof(), so substitute its implementation.
+	# That's not a perfect fix, since it doesn't avoid double-rounding,
+	# but we have no better options. To get that, though, we have to
 	# force the file to be compiled despite HAVE_STRTOF.
 	case " $LIBOBJS " in
   *" strtof.$ac_objext "* ) ;;
diff --git a/configure.ac b/configure.ac
index d093fb88dd..a6fd901141 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1927,10 +1927,9 @@ fi
 
 if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
 	# Cygwin and (apparently, based on test results) Mingw both
-	# have a broken strtof(), so substitute the same replacement
-	# code we use with VS2013. That's not a perfect fix, since
-	# (unlike with VS2013) it doesn't avoid double-rounding, but
-	# we have no better options. To get that, though, we have to
+	# have a broken strtof(), so substitute its implementation.
+	# That's not a perfect fix, since it doesn't avoid double-rounding,
+	# but we have no better options. To get that, though, we have to
 	# force the file to be compiled despite HAVE_STRTOF.
 	AC_LIBOBJ([strtof])
 	AC_MSG_NOTICE([On $host_os we will use our strtof wrapper.])
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index f24d9e5348..62acdda3a1 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -4,7 +4,7 @@
 package MSBuildProject;
 
 #
-# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2015 or greater)
 #
 # src/tools/msvc/MSBuildProject.pm
 #
@@ -405,31 +405,6 @@ EOF
 	return;
 }
 
-package VC2013Project;
-
-#
-# Package that encapsulates a Visual C++ 2013 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver}           = '12.00';
-	$self->{PlatformToolset} = 'v120';
-	$self->{ToolsVersion}    = '12.0';
-
-	return $self;
-}
-
 package VC2015Project;
 
 #
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index 473d6f425b..1c36925258 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
 ==========
 
 This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
+Microsoft Visual Studio 2015 - 2022. This builds the whole backend, not just
 the libpq frontend library. For more information, see the documentation
 chapter "Installation on Windows" and the description below.
 
@@ -67,7 +67,7 @@ Install.pm             module containing the install logic
 Mkvcbuild.pm           module containing the code to generate the Visual
                        Studio build (project/solution) files
 MSBuildProject.pm      module containing the code to generate MSBuild based
-                       project files (Visual Studio 2013 or greater)
+                       project files (Visual Studio 2015 or greater)
 Project.pm             module containing the common code to generate the
                        Visual Studio project files. Also provides the
                        common interface of all project file generators
@@ -88,10 +88,10 @@ config_default.pl to create the configuration arguments.
 These configuration arguments are passed over to Mkvcbuild::mkvcbuild
 (Mkvcbuild.pm) which creates the Visual Studio project and solution files.
 It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either VS2013Solution,
+implementing the Solution interface (this could be either
 VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in
 Solution.pm, depending on the user's build environment) and adding objects
-implementing the corresponding Project interface (VC2013Project,
+implementing the corresponding Project interface (
 VC2015Project, VC2017Project, VC2019Project or VC2022Project from
 MSBuildProject.pm) to it. When Solution::Save is called, the implementations
 of Solution and Project save their content in the appropriate format.
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index d30e8fcb11..a4a2c637ff 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -1218,34 +1218,6 @@ sub GetFakeConfigure
 	return $cfg;
 }
 
-package VS2013Solution;
-
-#
-# Package that encapsulates a Visual Studio 2013 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion}        = '12.00';
-	$self->{vcver}                      = '12.00';
-	$self->{visualStudioName}           = 'Visual Studio 2013';
-	$self->{VisualStudioVersion}        = '12.0.21005.1';
-	$self->{MinimumVisualStudioVersion} = '10.0.40219.1';
-
-	return $self;
-}
-
 package VS2015Solution;
 
 #
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 9f9712b793..975ccf2ee5 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -33,11 +33,7 @@ sub CreateSolution
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '12.00')
-	{
-		return new VS2013Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '14.00')
+	if ($visualStudioVersion eq '14.00')
 	{
 		return new VS2015Solution(@_);
 	}
@@ -87,11 +83,7 @@ sub CreateProject
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '12.00')
-	{
-		return new VC2013Project(@_);
-	}
-	elsif ($visualStudioVersion eq '14.00')
+	if ($visualStudioVersion eq '14.00')
 	{
 		return new VC2015Project(@_);
 	}
-- 
2.36.1

#15Michael Paquier
michael@paquier.xyz
In reply to: Michael Paquier (#14)
1 attachment(s)
Re: Remove support for Visual Studio 2013

On Mon, May 30, 2022 at 04:48:22PM +0900, Michael Paquier wrote:

After looking at that again, the whole comment related to VS in
strtof.c can be removed. I have noticed while on it more places that
still referred to VS2013 in ./configure[.ac] and win32_langinfo() got
an overall incorrect description. This leads to v2 as of the
attached.

And with 495ed0e now in place, attached is a rebased version.
--
Michael

Attachments:

v3-0001-Remove-support-for-VS-2013.patchtext/x-diff; charset=us-asciiDownload
From c685a8f1617e585e88a16689f7b4f4e338417bca Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Thu, 7 Jul 2022 16:45:32 +0900
Subject: [PATCH v3] Remove support for VS 2013

---
 src/include/port/win32_port.h         |  7 +----
 src/backend/main/main.c               |  5 ----
 src/backend/optimizer/path/costsize.c |  4 +--
 src/backend/utils/adt/float.c         |  6 +---
 src/backend/utils/adt/pg_locale.c     | 40 ---------------------------
 src/port/chklocale.c                  | 33 ++++------------------
 src/port/strtof.c                     |  9 ------
 doc/src/sgml/install-windows.sgml     |  8 ++----
 configure                             |  7 ++---
 configure.ac                          |  7 ++---
 src/tools/msvc/MSBuildProject.pm      | 27 +-----------------
 src/tools/msvc/README                 |  8 +++---
 src/tools/msvc/Solution.pm            | 28 -------------------
 src/tools/msvc/VSObjectFactory.pm     | 12 ++------
 14 files changed, 24 insertions(+), 177 deletions(-)

diff --git a/src/include/port/win32_port.h b/src/include/port/win32_port.h
index dbbf88f8e8..5121c0c626 100644
--- a/src/include/port/win32_port.h
+++ b/src/include/port/win32_port.h
@@ -531,13 +531,8 @@ typedef unsigned short mode_t;
 
 #endif							/* _MSC_VER */
 
-#if (defined(_MSC_VER) && (_MSC_VER < 1900)) || \
-	defined(__MINGW32__) || defined(__MINGW64__)
+#if defined(__MINGW32__) || defined(__MINGW64__)
 /*
- * VS2013 has a strtof() that seems to give correct answers for valid input,
- * even on the rounding edge cases, but which doesn't handle out-of-range
- * input correctly. Work around that.
- *
  * Mingw claims to have a strtof, and my reading of its source code suggests
  * that it ought to work (and not need this hack), but the regression test
  * results disagree with me; whether this is a version issue or not is not
diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index dd82722ee3..bb782fa1ec 100644
--- a/src/backend/main/main.c
+++ b/src/backend/main/main.c
@@ -30,11 +30,6 @@
 #include <sys/param.h>
 #endif
 
-#if defined(_M_AMD64) && _MSC_VER == 1800
-#include <math.h>
-#include <versionhelpers.h>
-#endif
-
 #include "bootstrap/bootstrap.h"
 #include "common/username.h"
 #include "port/atomics.h"
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index fcc26b01a4..5e5732f6e1 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -5445,10 +5445,8 @@ calc_joinrel_size_estimate(PlannerInfo *root,
 						   double outer_rows,
 						   double inner_rows,
 						   SpecialJoinInfo *sjinfo,
-						   List *restrictlist_in)
+						   List *restrictlist)
 {
-	/* This apparently-useless variable dodges a compiler bug in VS2013: */
-	List	   *restrictlist = restrictlist_in;
 	JoinType	jointype = sjinfo->jointype;
 	Selectivity fkselec;
 	Selectivity jselec;
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index 63bb0f2277..fc8f39a7a9 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -249,13 +249,9 @@ float4in(PG_FUNCTION_ARGS)
 			 * precision).  We'd prefer not to throw error for that, so try to
 			 * detect whether it's a "real" out-of-range condition by checking
 			 * to see if the result is zero or huge.
-			 *
-			 * Use isinf() rather than HUGE_VALF on VS2013 because it
-			 * generates a spurious overflow warning for -HUGE_VALF.  Also use
-			 * isinf() if HUGE_VALF is missing.
 			 */
 			if (val == 0.0 ||
-#if !defined(HUGE_VALF) || (defined(_MSC_VER) && (_MSC_VER < 1900))
+#if !defined(HUGE_VALF)
 				isinf(val)
 #else
 				(val >= HUGE_VALF || val <= -HUGE_VALF)
diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c
index 5cf5dd5f87..607a4b7340 100644
--- a/src/backend/utils/adt/pg_locale.c
+++ b/src/backend/utils/adt/pg_locale.c
@@ -950,7 +950,6 @@ cache_locale_time(void)
  * [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
  */
 
-#if _MSC_VER >= 1900
 /*
  * Callback function for EnumSystemLocalesEx() in get_iso_localename().
  *
@@ -1100,7 +1099,6 @@ get_iso_localename(const char *winlocname)
 
 	return NULL;
 }
-#endif							/* _MSC_VER >= 1900 */
 
 static char *
 IsoLocaleName(const char *winlocname)
@@ -1115,46 +1113,8 @@ IsoLocaleName(const char *winlocname)
 		return iso_lc_messages;
 	}
 	else
-	{
-#if (_MSC_VER >= 1900)			/* Visual Studio 2015 or later */
 		return get_iso_localename(winlocname);
-#else
-		_locale_t	loct;
 
-		loct = _create_locale(LC_CTYPE, winlocname);
-		if (loct != NULL)
-		{
-			size_t		rc;
-			char	   *hyphen;
-
-			/* Locale names use only ASCII, any conversion locale suffices. */
-			rc = wchar2char(iso_lc_messages, loct->locinfo->locale_name[LC_CTYPE],
-							sizeof(iso_lc_messages), NULL);
-			_free_locale(loct);
-			if (rc == -1 || rc == sizeof(iso_lc_messages))
-				return NULL;
-
-			/*
-			 * Since the message catalogs sit on a case-insensitive
-			 * filesystem, we need not standardize letter case here.  So long
-			 * as we do not ship message catalogs for which it would matter,
-			 * we also need not translate the script/variant portion, e.g.
-			 * uz-Cyrl-UZ to uz_UZ@cyrillic.  Simply replace the hyphen with
-			 * an underscore.
-			 *
-			 * Note that the locale name can be less-specific than the value
-			 * we would derive under earlier Visual Studio releases.  For
-			 * example, French_France.1252 yields just "fr".  This does not
-			 * affect any of the country-specific message catalogs available
-			 * as of this writing (pt_BR, zh_CN, zh_TW).
-			 */
-			hyphen = strchr(iso_lc_messages, '-');
-			if (hyphen)
-				*hyphen = '_';
-			return iso_lc_messages;
-		}
-#endif							/* Visual Studio 2015 or later */
-	}
 #endif							/* defined(_MSC_VER) */
 	return NULL;				/* Not supported on this version of msvc/mingw */
 }
diff --git a/src/port/chklocale.c b/src/port/chklocale.c
index c85d8da3c8..2aaf2ae8c0 100644
--- a/src/port/chklocale.c
+++ b/src/port/chklocale.c
@@ -191,19 +191,10 @@ static const struct encoding_match encoding_match_list[] = {
 /*
  * On Windows, use CP<code page number> instead of the nl_langinfo() result
  *
- * Visual Studio 2012 expanded the set of valid LC_CTYPE values, so have its
- * locale machinery determine the code page.  See comments at IsoLocaleName().
- * For other compilers, follow the locale's predictable format.
- *
- * Visual Studio 2015 should still be able to do the same, but the declaration
- * of lc_codepage is missing in _locale_t, causing this code compilation to
- * fail, hence this falls back instead on GetLocaleInfoEx. VS 2015 may be an
- * exception and post-VS2015 versions should be able to handle properly the
- * codepage number using _create_locale(). So, instead of the same logic as
- * VS 2012 and VS 2013, this routine uses GetLocaleInfoEx to parse short
- * locale names like "de-DE", "fr-FR", etc. If those cannot be parsed correctly
- * process falls back to the pre-VS-2010 manual parsing done with
- * using <Language>_<Country>.<CodePage> as a base.
+ * This routine uses GetLocaleInfoEx() to parse short locale names like
+ * "de-DE", "fr-FR", etc.  If those cannot be parsed correctly process falls
+ * back to the pre-VS-2010 manual parsing done with using
+ * <Language>_<Country>.<CodePage> as a base.
  *
  * Returns a malloc()'d string for the caller to free.
  */
@@ -211,22 +202,9 @@ static char *
 win32_langinfo(const char *ctype)
 {
 	char	   *r = NULL;
-
-#if defined(_MSC_VER) && (_MSC_VER < 1900)
-	_locale_t	loct = NULL;
-
-	loct = _create_locale(LC_CTYPE, ctype);
-	if (loct != NULL)
-	{
-		r = malloc(16);			/* excess */
-		if (r != NULL)
-			sprintf(r, "CP%u", loct->locinfo->lc_codepage);
-		_free_locale(loct);
-	}
-#else
 	char	   *codepage;
 
-#if defined(_MSC_VER) && (_MSC_VER >= 1900)
+#if defined(_MSC_VER)
 	uint32		cp;
 	WCHAR		wctype[LOCALE_NAME_MAX_LENGTH];
 
@@ -279,7 +257,6 @@ win32_langinfo(const char *ctype)
 			}
 		}
 	}
-#endif
 
 	return r;
 }
diff --git a/src/port/strtof.c b/src/port/strtof.c
index 7da05be687..314fcc9851 100644
--- a/src/port/strtof.c
+++ b/src/port/strtof.c
@@ -54,15 +54,6 @@ strtof(const char *nptr, char **endptr)
 
 #elif HAVE_BUGGY_STRTOF
 /*
- * On Windows, there's a slightly different problem: VS2013 has a strtof()
- * that returns the correct results for valid input, but may fail to report an
- * error for underflow or overflow, returning 0 instead. Work around that by
- * trying strtod() when strtof() returns 0.0 or [+-]Inf, and calling it an
- * error if the result differs. Also, strtof() doesn't handle subnormal input
- * well, so prefer to round the strtod() result in such cases. (Normally we'd
- * just say "too bad" if strtof() doesn't support subnormals, but since we're
- * already in here fixing stuff, we might as well do the best fix we can.)
- *
  * Cygwin has a strtof() which is literally just (float)strtod(), which means
  * we can't avoid the double-rounding problem; but using this wrapper does get
  * us proper over/underflow checks. (Also, if they fix their strtof(), the
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 66567d17a0..afb004b5cf 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
   <productname>Windows</productname>. The simplest way to build with
   Microsoft tools is to install <productname>Visual Studio 2022</productname>
   and use the included compiler. It is also possible to build with the full
-  <productname>Microsoft Visual C++ 2013 to 2022</productname>.
+  <productname>Microsoft Visual C++ 2015 to 2022</productname>.
   In some cases that requires the installation of the
   <productname>Windows SDK</productname> in addition to the compiler.
  </para>
@@ -77,15 +77,13 @@
  <para>
   Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
   32-bit PostgreSQL builds are possible with
-  <productname>Visual Studio 2013</productname> to
+  <productname>Visual Studio 2015</productname> to
   <productname>Visual Studio 2022</productname>,
   as well as standalone Windows SDK releases 8.1a to 10.
   64-bit PostgreSQL builds are supported with
   <productname>Microsoft Windows SDK</productname> version 8.1a to 10 or
-  <productname>Visual Studio 2013</productname> and above.
+  <productname>Visual Studio 2015</productname> and above.
    <!--
-       For 2013 requirements:
-       https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
        For 2015 requirements:
        https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
        For 2017 requirements:
diff --git a/configure b/configure
index da177403ef..e64f5c4802 100755
--- a/configure
+++ b/configure
@@ -16904,10 +16904,9 @@ fi
 
 if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
 	# Cygwin and (apparently, based on test results) Mingw both
-	# have a broken strtof(), so substitute the same replacement
-	# code we use with VS2013. That's not a perfect fix, since
-	# (unlike with VS2013) it doesn't avoid double-rounding, but
-	# we have no better options. To get that, though, we have to
+	# have a broken strtof(), so substitute its implementation.
+	# That's not a perfect fix, since it doesn't avoid double-rounding,
+	# but we have no better options. To get that, though, we have to
 	# force the file to be compiled despite HAVE_STRTOF.
 	case " $LIBOBJS " in
   *" strtof.$ac_objext "* ) ;;
diff --git a/configure.ac b/configure.ac
index 6c6f997ee3..f6e831ee26 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1927,10 +1927,9 @@ fi
 
 if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
 	# Cygwin and (apparently, based on test results) Mingw both
-	# have a broken strtof(), so substitute the same replacement
-	# code we use with VS2013. That's not a perfect fix, since
-	# (unlike with VS2013) it doesn't avoid double-rounding, but
-	# we have no better options. To get that, though, we have to
+	# have a broken strtof(), so substitute its implementation.
+	# That's not a perfect fix, since it doesn't avoid double-rounding,
+	# but we have no better options. To get that, though, we have to
 	# force the file to be compiled despite HAVE_STRTOF.
 	AC_LIBOBJ([strtof])
 	AC_MSG_NOTICE([On $host_os we will use our strtof wrapper.])
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index f24d9e5348..62acdda3a1 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -4,7 +4,7 @@
 package MSBuildProject;
 
 #
-# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2015 or greater)
 #
 # src/tools/msvc/MSBuildProject.pm
 #
@@ -405,31 +405,6 @@ EOF
 	return;
 }
 
-package VC2013Project;
-
-#
-# Package that encapsulates a Visual C++ 2013 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{vcver}           = '12.00';
-	$self->{PlatformToolset} = 'v120';
-	$self->{ToolsVersion}    = '12.0';
-
-	return $self;
-}
-
 package VC2015Project;
 
 #
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index 473d6f425b..1c36925258 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
 ==========
 
 This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2013 - 2022. This builds the whole backend, not just
+Microsoft Visual Studio 2015 - 2022. This builds the whole backend, not just
 the libpq frontend library. For more information, see the documentation
 chapter "Installation on Windows" and the description below.
 
@@ -67,7 +67,7 @@ Install.pm             module containing the install logic
 Mkvcbuild.pm           module containing the code to generate the Visual
                        Studio build (project/solution) files
 MSBuildProject.pm      module containing the code to generate MSBuild based
-                       project files (Visual Studio 2013 or greater)
+                       project files (Visual Studio 2015 or greater)
 Project.pm             module containing the common code to generate the
                        Visual Studio project files. Also provides the
                        common interface of all project file generators
@@ -88,10 +88,10 @@ config_default.pl to create the configuration arguments.
 These configuration arguments are passed over to Mkvcbuild::mkvcbuild
 (Mkvcbuild.pm) which creates the Visual Studio project and solution files.
 It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either VS2013Solution,
+implementing the Solution interface (this could be either
 VS2015Solution, VS2017Solution, VS2019Solution or VS2022Solution, all in
 Solution.pm, depending on the user's build environment) and adding objects
-implementing the corresponding Project interface (VC2013Project,
+implementing the corresponding Project interface (
 VC2015Project, VC2017Project, VC2019Project or VC2022Project from
 MSBuildProject.pm) to it. When Solution::Save is called, the implementations
 of Solution and Project save their content in the appropriate format.
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index d30e8fcb11..a4a2c637ff 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -1218,34 +1218,6 @@ sub GetFakeConfigure
 	return $cfg;
 }
 
-package VS2013Solution;
-
-#
-# Package that encapsulates a Visual Studio 2013 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine);    ## no critic
-
-sub new
-{
-	my $classname = shift;
-	my $self      = $classname->SUPER::_new(@_);
-	bless($self, $classname);
-
-	$self->{solutionFileVersion}        = '12.00';
-	$self->{vcver}                      = '12.00';
-	$self->{visualStudioName}           = 'Visual Studio 2013';
-	$self->{VisualStudioVersion}        = '12.0.21005.1';
-	$self->{MinimumVisualStudioVersion} = '10.0.40219.1';
-
-	return $self;
-}
-
 package VS2015Solution;
 
 #
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 9f9712b793..975ccf2ee5 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -33,11 +33,7 @@ sub CreateSolution
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '12.00')
-	{
-		return new VS2013Solution(@_);
-	}
-	elsif ($visualStudioVersion eq '14.00')
+	if ($visualStudioVersion eq '14.00')
 	{
 		return new VS2015Solution(@_);
 	}
@@ -87,11 +83,7 @@ sub CreateProject
 		$visualStudioVersion = DetermineVisualStudioVersion();
 	}
 
-	if ($visualStudioVersion eq '12.00')
-	{
-		return new VC2013Project(@_);
-	}
-	elsif ($visualStudioVersion eq '14.00')
+	if ($visualStudioVersion eq '14.00')
 	{
 		return new VC2015Project(@_);
 	}
-- 
2.36.1

#16Michael Paquier
michael@paquier.xyz
In reply to: Michael Paquier (#15)
Re: Remove support for Visual Studio 2013

On Fri, Jul 08, 2022 at 07:38:23AM +0900, Michael Paquier wrote:

And with 495ed0e now in place, attached is a rebased version.

Hearing nothing about this one, and because it is a nice cleanup
overall, I have gone ahead and applied it:
14 files changed, 24 insertions(+), 177 deletions(-)

This removes the dependency on the value of _MSC_VER.
--
Michael