VS2010 - Structure change in CryptoAPI - v7.0A Vs v6.0A - WinCrypt.h

Question

In C:\Program Files\Microsoft SDKs\Windows\v7.0A\Include\WinCrypt.h, the definition for CERT_CHAIN_ENGINE_CONFIG is

typedef struct _CERT_CHAIN_ENGINE_CONFIG {

    DWORD       cbSize;
    HCERTSTORE  hRestrictedRoot;
    HCERTSTORE  hRestrictedTrust;
    HCERTSTORE  hRestrictedOther;
    DWORD       cAdditionalStore;
    HCERTSTORE* rghAdditionalStore;
    DWORD       dwFlags;
    DWORD       dwUrlRetrievalTimeout;      // milliseconds
    DWORD       MaximumCachedCertificates;
    DWORD       CycleDetectionModulus;

*#if (NTDDI_VERSION >= NTDDI_WIN7)
    HCERTSTORE  hExclusiveRoot;
    HCERTSTORE  hExclusiveTrustedPeople;
#endif*

} CERT_CHAIN_ENGINE_CONFIG, *PCERT_CHAIN_ENGINE_CONFIG;

I am using visual studio 2010 in an XP sp3 machine, in which case, i expect that the following two members in the above structure gets greyed out. But this is not happening,

#if (NTDDI_VERSION >= NTDDI_WIN7)
    HCERTSTORE  hExclusiveRoot;
    HCERTSTORE  hExclusiveTrustedPeople;
#endif

NTDDI_VERSION in-turn is defined in sdkddkver.h as follows, and _WIN32_WINNT somehow takes the value of NTDDI_WIN7 which in my case is incorrect as mine is a XP SP3 machine.

#if !defined(_WIN32_WINNT) && !defined(_CHICAGO_)
#define  _WIN32_WINNT   0x0601
#endif
#ifndef NTDDI_VERSION
#ifdef _WIN32_WINNT
// set NTDDI_VERSION based on _WIN32_WINNT
#define NTDDI_VERSION   NTDDI_VERSION_FROM_WIN32_WINNT(_WIN32_WINNT)
#else
#define NTDDI_VERSION   0x06010000
#endif
#endif

The above two members of the structure CERT_CHAIN_ENGINE_CONFIG in question is not present in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\WinCrypt.hBut my 2010 visual studio project automatically pulls in the header and lib files from C:\Program Files\Microsoft SDKs\Windows\v7.0A\Include\WinCrypt.h Because of the conflicting structures, i am getting parameter is incorrect

Please advise how i can over come this issue?

Should i have to install visual studio 2010 sp1?

I found one reference in the web where it says initialising the structure will resolve the issue, but it will not, as the two parameters in question will not be greyed out and will be taken in while building.

UPDATE1:

Settings of my project:

$(VCInstalDir) - >C:\Program Files\Microsoft Visual Studio 10.0\VC

$(WindowsSdkDir) ->C:\Program Files\Microsoft SDKs\Windows\v7.0A

$(FrameworkSdkDir) ->C:\Program Files\Microsoft SDKs\Windows\v7.0A

Library file settings,

$(VCInstallDir)lib
$(VCInstallDir)atlmfc\lib
$(WindowsSdkDir)lib
$(FrameworkSDKDir)\lib

UPDATE 2: My preprocessor definitions are

WIN32;_DEBUG;_WINDOWS;_USRDLL;MY_DLL_EXPORTS;%(PreprocessorDefinitions)

%(PreprocessorDefinitions) inherited values as follows

_WINDLL
_MBCS

Thanks

Oysterman

Answer 1

The problem which you have can be very easy explained. If you use v7.0A or v7.1 you are able to compile your project so that it will run under Windows 7. So the default value for the _WIN32_WINNT is 0x0601.

If you want co compile the program so that it will run on Windows XP you can define WINVER and _WIN32_WINNT explicitly. Typically one do this in the settings of the Visual Studio project inside of the preprocessor definitions. If you will do this the corresponding part of CERT_CHAIN_ENGINE_CONFIG structure will be displayed gray like you as want.

In the most cases and in the case of CERT_CHAIN_ENGINE_CONFIG it is not really needed. The Windows API are designed mostly so, that you will have no problems in the usage of CERT_CHAIN_ENGINE_CONFIG defined for Windows 7 in case of the start of the program on Windows XP. If you do define

#define WINVER 0x0500
#define _WIN32_WINNT 0x0500

(or 0x0501 instead of 0x0500) you will be able to run your program in the Windows 7, but you will be not able to use the hExclusiveRoot and the hExclusiveTrustedPeople members. The reason is the cbSize field which you should initialize as sizeof(CERT_CHAIN_ENGINE_CONFIG). It gives for the CertCreateCertificateChainEngine function enough information about the size of the input structure CERT_CHAIN_ENGINE_CONFIG. In case of small value of cbSize, the last HCERTSTORE members hExclusiveRoot and hExclusiveTrustedPeople will be just not used.

Frampton

Answer 2

the value of NTDDI_WIN7 which in my case is incorrect as mine is a XP SP3 machine.

As I understand it, the variables are initialized according to what system you are targeting, not what system you are compiling the code on. So you need to look at your project settings and see, what is your target platform, what headers are referenced etc. .

Hubble

@Eugene, My target systems will be XP,Vista,Win7, Server2003 and server 2008. Can you please elaborate your last sentence on how to configure the project settings. or some pointers to start with? Thanks – Oysterman

@Oysterman you have the project source code and I don't know where and how the defines are set in your project. If you search for "NTDDI_WIN7" in google, the very first link is msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx , which can be helpful to you (though it targets the opposite task to yours). – Adventure

@Eugene. I have edited my original post with screen shots of my project settings. The link which you have shown is allowing me to define preprocessor directives that will restrict my target platforms rather than including them all. Is there anything you could recommend? Thanks – Oysterman

@Oysterman it's not about paths but about defines that your project has. Defines are specified on Compiler -> Preprocessor tab. Also some defines are set automatically when you choose different options. One idea: there's a page in the project properties dialog which lists all command line options. There you can see what defines are set. – Adventure

@Eugene. I couldn't get the preprocessor directives working, Instead i used the Platform Toolset and switched back to 6.0A and got it working without losing much other than the RSA_AES_XP provider name. I have added the preprocessor directive, if that gives any idea of how i can still rely on manipulating the preprocessor directives. thanks – Oysterman

You should be able to define version macro's once before the first include (eg in a precompiled header or something). Then you just change that if you change the OS you're targetting. – Buckskin