#29 Old eay libs referenced in Visual Studio project

[Nigel Hathaway]

The two .props files still reference the eay libs, whereas it should be libcrypto and libssl. This can be fixed with a simple text edit.

In addition, createprimary.vcxproj and startup.vcxproj override the defaults set in the .props files with incorrect eay libraries. These are in lines marked <additionaldependencies>. Those lines should be deleted (which can be done with a text editor.</additionaldependencies>

One further problem I have: x509v3.h generates loads of syntax errors. This is because X509_NAME is defined in wincrypt.h which conflicts. I am yet to get to the bottom of why this is and how to fix it.

[Ken Goldman]

I can answer the second problem quickly. It appeared with Windows 10. From the not yet released documentation update:

"The Windows 10 crypto library has function names that clash with OpenSSL, particularly in the area of X.509 support. Visual Studio includes it by default when using. To remove those headers, define WIN32_LEAN_AND_MEAN. "

Files that currently need it include loadexternal.c, sign.c, createek.c ekutils.c, signapp.c and tssproperties.h.

I'm in the process of factoring all the openssl dependencies to a small number of files to make this easier.

Also, since you may be using Windows 10:

"Windows blocks executables with the strings setup, install, update, and patch in the name. Thus, TPM utilities like sequenceupdate.exe will not run.

One work around is to run the commands shell as administrator. Right click "Command Prompt" and select "Run as administrator". "

[Nigel Hathaway]

Thanks for this. Defining WIN32_LEAN_AND_MEAN solves this.

However, new errors appear.

In tssproperties.h, line 66 typedef SOCKET TSS_SOCKET_FD; fails as SOCKET is undefined.

In tssproperties.c, TSS_CONTEXT claims to be undefined. Simarly in tsstransmit.c

[Nigel Hathaway]

It looks like we need to add the line:

#include <winsock.h>
after
#include <windows.h>

at line 52 of tssproperties.h

[Ken Goldman]

Done, thanks.

[Nigel Hathaway]

Actually, instead of defining WIN32_LEAN_AND_MEAN, define NOCRYPT instead. In this way, you don't need to include winsock.h.

See https://stackoverflow.com/questions/11040133/what-does-defining-win32-lean-and-mean-exclude-exactly

[Ken Goldman]

My inclination is to stay with WIN32_LEAN_AND_MEAN and explicitly include winsock. The WIN32_XXX macros seem somewhat official. NOCRYPT may work today, but it feels more like 'Microsoft internal use only'. It also has the same namespace issue that caused the problem in the first place. Who knows that other software might use NOCRYPT?