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
wolfSSL configure script relevant changes from 3.10 to 3.11:
- Async threading support added; disabled by default without async
crypto, which continues to be disabled by default.
wolfSSL configure script relevant changes from 3.11 to 3.11.1 (beta):
- TLS 1.3 beta support added; disabled by default.
For experimenting I put in a comment block the defines needed to enable
TLS 1.3 support (ie the equivalent of --enable-tls13).
wolfSSL configure script relevant changes from 3.9 to 3.10:
- DES3 no longer enabled by default
- Shamir no longer enabled by default
- Extended master secret enabled by default
- RSA and ECC timing protections enabled by default
For backwards compatibility I enabled DES3 and ECC shamir config options
(ie no change from 3.9), and the other changes are included.
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.
This is an update to the build-time options used to build wolfSSL in
Visual Studio for greater compatibility, and make it behave similar to
the way OpenSSL 1.0.2 behaves. Starting in wolfSSL v3.6.6 static ciphers
and SSLv3 are disabled by default at build time, but we can use both.
- Enable static cipher suites TLS_ECDH_ and TLS_RSA_.
- Enable SSLv3 hello. Though in libcurl we disable it by default at
runtime, we make it available so the user can manually select it if
necessary.
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.
- Do not use wolfSSL's sample user-setting files.
wolfSSL starting in v3.9.0 has added their own sample user settings that
are applied by default, but we don't use them because we have our own
settings.
- Do not use wolfSSL's Visual Studio Unicode character setting.
wolfSSL Visual Studio projects use the Unicode character set however our
settings and options imitate mingw build which does not use the Unicode
character set. This does not appear to have any effect at the moment but
better safe than sorry.
These changes are backwards compatible with earlier versions.
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.
Remove NOTES section, it's no longer needed since we aren't setting the
errorlevel and more importantly the recently updated URL in the comments
is causing some unusual behavior that breaks the script.
Closes https://github.com/curl/curl/issues/649
Ensure that there isn't a mismatch between setlocal and endlocal calls,
which could have happened due to setlocal being called after certain
error conditions were checked for.
Added the wolfSSL build script, based on build-openssl.bat, as well as
the property sheet and header file required for the upcoming additions
to the Visual Studio project 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.
Advise that WinSSL in versions <= XP will not be able to connect to
servers that no longer support the legacy handshakes and algorithms used
by those versions, and to use an alternate backend like OpenSSL instead.
Bug: https://github.com/bagder/curl/issues/253
Reported-by: zenden2k <zenden2k@gmail.com>
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
As the curl command-line tool now includes it's own version of strdup(),
for platforms that don't have it, fixed up the git respository Visual
Studio project file generator to not include the version from lib in the
tool project files, rather than having both lib\strdup.[c|h] and
src\tool_strdup.[c|h] present.
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.
..when working from the git repository. This is particularly useful
for single development environments where the project files for all
supported versions of Visual Studio may not be required.
I use the curl repo mainly on Windows with the typical Windows git
checkout which converts the LF line endings in the curl repo to CRLF
automatically on checkout. The automatic conversion is not done on files
in the repo with mixed line endings. I recently noticed some weird
output with projects/build-openssl.bat that I traced back to mixed line
endings, so I scanned the repo and there are files (excluding the
test data) that have mixed line endings.
I used this command below to do the scan. Unfortunately it's not as easy
as git grep, at least not on Windows. This gets the names of all the
files in the repo's HEAD, gets each of those files raw from HEAD, checks
for mixed line endings of both LF and CRLF, and prints the name if
mixed. I excluded path tests/data/test* because those can have mixed
line endings if I understand correctly.
for f in `git ls-tree --name-only --full-tree -r HEAD`;
do if [ -n "${f##tests/data/test*}" ];
then git show "HEAD:$f" | \
perl -0777 -ne 'exit 1 if /([^\r]\n.*\r\n)|(\r\n.*[^\r]\n)/';
if [ $? -ne 0 ];
then echo "$f";
fi;
fi;
done
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
