15

I get some fatal error on my project, the error is coming from sspi.h, i have to define something but i am not what and why, please someone explain.

sspi.h(60): fatal error C1189: #error :   You must define one of SECURITY_WIN32, SECURITY_KERNEL, or SECURITY_MAC
IInspectable
  • 46,945
  • 8
  • 85
  • 181
Cooker
  • 421
  • 1
  • 9
  • 19

3 Answers3

21

While the diagnostic is clear about having to define one of SECURITY_WIN32, SECURITY_KERNEL, or SECURITY_MAC, it doesn't help much in determining which one to use and why. To my knowledge, none of those are officially documented in the MSDN, so the only source of information are the actual header files.

  • SECURITY_MAC: This symbol only ever appears in <sspi.h>, a file with a copyright notice of 1992-1999. Presumably, this symbol was introduced to support compiling for "Classic" Mac OS, back when MFC was still planned to be a cross-platform framework targeting both Windows and Mac. The symbol doesn't appear to be of any practical use today.

  • SECURITY_KERNEL: The most enlightening comment here is from <NTSecPKG.h>, reading // Can't use the windows.h def'ns in kernel mode.. That appears to indicate that the SECURITY_KERNEL symbol needs to be defined, when accessing the security package from a module running in kernel mode.

  • SECURITY_WIN32: There are no comments on this symbol throughout the entire Windows SDK at all. It seems plausible, that this symbol should be used when accessing the security API from a user-mode application.

Assuming all of the above are correct, the following guideline can be used in determining the symbol to define:

  • Define SECURITY_WIN32 when compiling a user-mode application.
  • Define SECURITY_KERNEL when compiling a kernel-mode module.
  • Never define the obsolete SECURITY_MAC preprocessor symbol.
IInspectable
  • 46,945
  • 8
  • 85
  • 181
5

Just add 

#define SECURITY_WIN32

before all includes

Cooker
  • 421
  • 1
  • 9
  • 19
  • 4
    If anybody wants to provide more details on this (e.g., why this is necessary, what it does / what it means, and what the other `SECURITY_*` defines mean) that would be helpful, I haven't been able to find much information on this so far. – jrh May 08 '17 at 19:24
  • 1
    @jrh: I started digging for information myself, but came up empty handed as well. I did compile my findings into an answer, which is at least a bit more complete than recommending to *"Do this (and pray)"*. – IInspectable Oct 20 '17 at 08:27
0

Just to add to the existing answers, the preferable way to define it would be 

#ifndef SECURITY_WIN32 
#define SECURITY_WIN32 
#endif

You could add this just before you #include the offending header file, or globally by adding it to you your stdafx.h (if you are using one) before your first call to windows.h or afxwin.h or whatever, at the same point that you define WINVER and _WIN32_WINNT, or you could of course just add it to your project settings.

InsanityPants
  • 121
  • 2
  • 5
  • The preferred way to set global preprocessor symbols is indeed on the command line. It's the safest way that can prevent ODR violations, which lead to IFNDR (ill-formed, no diagnostic required) bugs, which lead to pain. Once we better understand how C++20 modules pan out, moving preprocessor symbols there is another sane option. Note that the `#ifndef` guard doesn't properly guard against having both `SECURITY_WIN32` and `SECURITY_KERNEL` defined at the same time. – IInspectable Apr 20 '20 at 13:53