- Rename VC15 -> VC14.10, VC17 -> VC14.30.
The projects directory that holds the pre-generated Visual Studio
project files uses VC<ver> to indicate the MSVC version. At some point
support for Visual Studio 2017 (Visual Studio version 15 which uses MSVC
14.10) was added as VC15. Visual Studio 2022 (Visual Studio version 17
which uses MSVC 14.30) project files were recently added and followed
that same format using VC17.
There is no such MSVC version (yet) as VC15 or VC17.
For VS 2017 for example, the name we use is correct as either VS17,
VS2017, VC14.10. I opted for the latter since we use VC for earlier
versions (eg VC10, VC12, etc).
Ref: https://github.com/curl/curl/pull/8438#issuecomment-1037070192
Closes https://github.com/curl/curl/pull/8447
- Remove Visual Studio project files for VC6, VC7, VC7.1, VC8 and VC9.
Those versions are too old to be maintained any longer.
Closes https://github.com/curl/curl/pull/8442
- Change build-wolfssl.bat to disable SSLv3, enable TLSv1.3, enable
wolfSSL_DES_ecb_encrypt (needed by NTLM) and enable alt cert chains.
- Disable warning C4214 'bit field types other than int'.
- Add include directory wolfssl\wolfssl.
wolfSSL offers OpenSSL API compatibility that libcurl uses, and some
recent change in libcurl included an include file for wolfSSL like
openssl/foo.h, which has a path like wolfssl\wolfssl\openssl\foo.h.
The include directory issue was reported in #8292 but it's currently
unclear whether this type of change is needed for other build systems.
Bug: https://github.com/curl/curl/issues/8292
Reported-by: Harry Sarson
Closes https://github.com/curl/curl/pull/8298
- Update VS project templates to use the OpenSSL lib names and include
directories for OpenSSL 1.1.x.
This change means the VS project files will now build only with OpenSSL
1.1.x when an OpenSSL configuration is chosen. Prior to this change the
project files built only with OpenSSL 1.0.x (end-of-life) when an
OpenSSL configuration was chosen.
The template changes in this commit were made by script:
libeay32.lib => libcrypto.lib
ssleay32.lib => libssl.lib
..\..\..\..\..\openssl\inc32 => ..\..\..\..\..\openssl\include
And since the output directory now contains the includes it's prepended:
..\..\..\..\..\openssl\build\Win{32,64}\VC{6..15}\{DLL,LIB}
{Debug,Release}\include
- Change build-openssl.bat to copy the build's include directory to the
output directory (as seen above).
Each build has its own opensslconf.h which is different so we can't just
include the source include directory any longer.
Note the include directory in the output directory is a full copy from
the build so technically we don't need to include the OpenSSL source
include directory in the template. However, I left it last in case the
user made a custom OpenSSL build using the old method which would put
opensslconf in the OpenSSL source include directory.
- Change build-openssl.bat to use a temporary install directory that is
different from the temporary build directory.
For OpenSSL 1.1.x the temporary paths must be separate not a descendant
of the other, otherwise pdb files will be lost between builds.
Ref: https://curl.se/mail/lib-2018-10/0049.html
Ref: https://gist.github.com/jay/125191c35bbeb894444eff827651f755
Ref; https://github.com/openssl/openssl/issues/10005
Fixes https://github.com/curl/curl/issues/984
Closes https://github.com/curl/curl/pull/6675
- s/USE_CYASSL/USE_WOLFSSL/
- Remove old compatibility macros.
Follow-up to 1c6c59a from several months ago when CyaSSL named symbols
were renamed to wolfSSL. The wolfSSL library was formerly named CyaSSL
and we kept using their old name for compatibility reasons, until
earlier this year.
All Windows APIs have been natively UTF-16 since Windows 2000 and the
non-Unicode variants are just wrappers around them. Only Windows 9x
doesn't understand Unicode without the UnicoWS DLL. As later Visual
Studio versions cannot target Windows 9x anyway, using the ANSI API
doesn't really have any benefit there.
This avoids issues like KNOWN_BUGS 6.5.
Ref: https://github.com/curl/curl/issues/2120
Closes https://github.com/curl/curl/pull/3720
Starting with Visual Studio 2017 Update 9, Visual Studio doesn't like
the MinimalRebuild option anymore and warns:
cl : Command line warning D9035: option 'Gm' has been deprecated and
will be removed in a future release
The option can be safely removed so that the default is used.
Closes https://github.com/curl/curl/pull/3425
The Visual Studio builds didn't use IPv6. Add it to all projects since
Visual Studio 2008, which is verified to build via AppVeyor.
Closes https://github.com/curl/curl/pull/3137
Visual Studio doesn't like LF line endings in solution files and always
converts them to CRLF when doing changes to the solution. Notably, this
affects the solutions in the release archive.
Closes https://github.com/curl/curl/pull/1746
After squashing most of our compiler warnings, up'ed the default
warning level from 3 to 4 in order to increase the likelyhood of
catching future warnings.
Updated the makefiles and Visual Studio project files to support moving
the authentication code to the new lib/vauth directory that was started
in commit 0d04e859e1.
As these files don't need to contain references to the source files,
although typically do, added basic files which only include three
filters and don't require the project file generator to be modified.
These files allow the source code to be viewed in the Solution Explorer
in versions of Visual Studio from 2010 onwards in the same manner as
previous versions did rather than one large view of files.
This wasn't possible with the old curlsrc project filenames, but like
commit 2a615a2b64 and 11397eb6dd for libcurl use the built in Visual
Studio macros for the output filenames.
Removed the DataExecutionPrevention directive from the project files for
Visual Studio 2008 and above. The XML value in the VC9 project files was
set to "0" (Default) whilst the VC10+ project files contained an empty
XML element.
Visual Studio 2008 introduced support for the address space layout
randomization (ASLR) feature of Windows Vista. However, upgrading the
VC8 project files to VC9 and above disabled this feature.
Removed the RandomizedBaseAddress directive to enabled the default
setting (/DYNAMICBASE). Note: This doesn't appear to have any negative
impact when compiled and ran on Windows XP.
Visual Studio 2005 and above defaults to disabling the startup banner
for the Compiler, Linker and MIDL tools (with /NOLOGO). As such there
is no need to explicitly set the SuppressStartupBanner directive, as
this is a leftover from the VC7 and VC7.1 projects being upgraded to
VC8 and above.
In preparation for adding the test suite and examples projects renamed
the top level "all" solution files to better describe what they are.
This will also enable us to use "curl" rather than "curlsrc" for the
command line tool solution and project files, which will simplify some
of the configuration.
Defined the DEBUGBUILD pre-processor variable to allow extra logging,
which is particularly useful in debug builds, as we use this and Visual
Studio typically uses _DEBUG.
We could define DEBUBBUILD, in curl_setup.h, when _MSC_VER and _DEBUG is
defined but that would also affect the makefile based builds which we
probably don't want to do.
Removed the WIN64 pre-processor definition from the libcurl project
files as:
* WIN64 is not used in our source code
* The curl projects files don't define it
* It isn't required by or used in the platform SDK
* For backwards compatability curl_setup.h defines WIN32
* The compiler automatically defines _WIN64 for x64 builds
Historically Visual Studio projects have defined WIN32, in addition to
the compiler defined _WIN32 definition, and I had incorrectly changed
that to WIN64 for the x64 libcurl builds but not in the curl projects.
As such, it is questionable whether this should be defined or not. For
more information see the following cache of a discussion that took
place on the microsoft.public.vc.mfc newsgroup:
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2008-06/msg00074.html
A left over from the VC6 project files, so mainly cosmetic in Visual
Studio .NET as it can handle both comma and semi-colon characters for
separating multiple pre-processor definitions.
However, the IDE uses semi-colons if the value is edited, and as such,
this may cause problems in future for anyone updating the files or
merging patches.
Used the Visual Studio IDE to correct the separator character.
The curl tool project files for VC8 to VC12 would set this setting to
$(IntDir) which is the Visual Studio default value. To avoid confusion
when viewing settings from within Visual Studio and for consistency
with the libcurl project files removed this setting.
Conflicts:
projects/Windows/VC10/src/curlsrc.tmpl
projects/Windows/VC11/src/curlsrc.tmpl
projects/Windows/VC12/src/curlsrc.tmpl
projects/Windows/VC8/src/curlsrc.tmpl
projects/Windows/VC9/src/curlsrc.tmpl
The curl tool project files for VC7 to VC12 would set this settings to
$(IntDir)$(TargetName).pch which is the Visual Studio default value. To
avoid confusion when viewing settings from within Visual Studio and for
consistency with the libcurl project files removed this setting.
Conflicts:
projects/Windows/VC10/src/curlsrc.tmpl
projects/Windows/VC11/src/curlsrc.tmpl
projects/Windows/VC12/src/curlsrc.tmpl
projects/Windows/VC8/src/curlsrc.tmpl
projects/Windows/VC9/src/curlsrc.tmpl
The curl tool project files for VC7 to VC12 would set these settings to
$(IntDir) which is the Visual Studio default value. To avoid confusion
when viewing settings from within Visual Studio and for consistency
with the libcurl project files removed these two settings.
The curl tool project files for VC7 to VC12 would override the default
setting with the output filename being the same as the linker PDB file.
As such the compiler file would be overwritten with the linker file
for all debug builds.
To avoid this overwrite and for consistency with the libcurl project
files, removed the setting to force the default filename to be used.
As with commit 11397eb6dd, use $(TargetDir) and $(TargetName) for the
Import Library output rather than $(OutDir)\$(ProjectName)d.lib and
$(OutDir)\$(ProjectName).lib.
