Subject: RE: [PATCH] Added Windows Cryptography API: Next Generation backend

RE: [PATCH] Added Windows Cryptography API: Next Generation backend

From: Bob Kast <>
Date: Mon, 17 Mar 2014 12:42:28 -0400

Hi Marc,

> Thanks for fixing these within the patch you send, but I would kindly like
> ask you to put individual and independent fixes into separate patches and
> post them to a separate thread on this mailinglist. This allows me to keep
> track of changes to the WinCNG code separately and other people can merge
> your general fixes without having to look through all the WinCNG code.

Now that WinCNG is in, should I post my patches on top of that?

> Regarding your changes to the Windows makefiles and VS project files:
> I guess we will have to restructure and improve them anyway, since they
> currently only support the OpenSSL backend. Just replacing OpenSSL with
> WinCNG might be a solution for your local build environment, but I think
> is not something that can be put into the main repository since it would
> backwards compatibility.

The VS files in the repository are .dsw/.dsp files. These are for a very old
version of VS and I doubt are very useful except for a starting point for
current VS support. I have not changed these files so there should not be a
backward compatibility issue. The VS files I added (.sln/.vcxproj) do make
some assumptions:
- Uses WinCNG
- Uses MSVCRT*.DLL. This implies that these have been "installed" somehow.

I could add a lot more configurations for each permutation but that might
just add to the confusion. If you think the above assumptions don't
represent the most widely used configuration, I could certainly change them.
I would think some doc file that describes how to change the config might be
the best way to go.

Style question: VS logs many warnings due to "possible data loss" (and
others), such as assigning a long to a short. This is throughout the
library, not just in WinCNG. These can be 'fixed' easily with casts, less
easily by matching data types, or I can just tell the compiler to not check
this. Should I post "fixes" to these warnings or just ignore them?

Received on 2014-03-17