More <windows.h> weirdness

What's the trick to including <windows.h>?
I have two projects. The first has the following includes:
1
2
#define WIN32_LEAN_AND_MEAN             // Exclude rarely-used stuff from Windows headers
#include <Windows.h> 

The project compiles just fine.

I tried adding the above includes to the second project and I get the following errors:

1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um\winnt.h(12874,10): error C2467: illegal declaration of anonymous 'struct'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um\winnt.h(18837,6): error C2467: illegal declaration of anonymous 'struct'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um\winnt.h(21055,24): error C2133: '_IMAGE_POLICY_METADATA::Policies': unknown size
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um\winioctl.h(4337,10): error C2467: illegal declaration of anonymous 'struct'


I suspect there is some difference in the project properties, but I don't see it.

What I'm trying to to is add a call to MessageBox (which requires winuser.h>) to project2.
Last edited on
Are you sure it's not what you have before the include that is cause the error? E.g. some missing semicolon or you #defining some name that is used internally inside the windows.h header?
Yes, I'm certain.
The two lines in the code block above are in pch.h which is compiled by itself.
pch.h in it's entirety.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#pragma once

#define WIN32_LEAN_AND_MEAN             // Exclude rarely-used stuff from Windows 
#include <Windows.h> 

//	STL
#include <array>
#include <bitset>
#include <cassert>
#include <chrono>
#include <cstdlib>
#include <deque>
#include <exception>
#include <forward_list>
#include <fstream>
#include <iostream>
#include <iomanip>
#include <ostream> 
#include <random>
#include <set>
#include <sstream>
#include <streambuf>
#include <vector> 


pch.cpp:
 
#include "pch.h" 

Last edited on
Searching for the error message seems to suggest it might be related to the /Za flag.

https://stackoverflow.com/questions/58034068/c-issues-with-windows-h-illegal-declaration-of-anonymous-struct-in-vs17
If you are using Visual Studio check the project's properties: Configuration Properties -> C/C++ -> Language -> Disable Language Extensions. The project requires to not disable language extensions because of the <windows.h> inclusion, set the property to No. The /Za flag.
If you are using Visual Studio check the project's properties: Configuration Properties -> C/C++ -> Language -> Disable Language Extensions. The project requires to not disable language extensions because of the <windows.h> inclusion, set the property to No. The /Za flag.

Windows is a major, massive deviation of the C language standard, it is a language extension.
MS's language extensions MUST be enabled for windows.h to compile OK. The extensions were created in the first place for Windows....

Also, you might want to have also #define NOMINMAX which stops windows.h defining the min/max macros when you have better ones in C++.
Thanks for the suggestion about the /Za flag.

I was able to solve this in a round about way. I created a new static library project. Copied all the .cpp and .h files to the new project. The include of <windows.h> then worked like a charm. The new project had the /Za flag off by default, while the old project has the /Za flag set for some reason.
More <windoows.h> oddities.

I have a third project that is also a static libraary. This library has a VT100 class.
The pch.h file is as shown below. The pch.cpp file compiles without error.
Yet, in the VT100 class all Windows references are undefined even though the
#include <windows.h> is at line 4 of the pch.h file.
I add #include <windows.h> to the front of the VT100 class and it compiles fine.
It's as if the the #include <windows.h> is missing from the pch.h file.
I've tried cleaning and rescanning, but neither makes any difference.
This was working at one point.

lib3/pch.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#pragma once

#define WIN32_LEAN_AND_MEAN             // Exclude rarely-used stuff from Windows headers
#include <Windows.h>

//	STL
#include <bitset>
#include <deque>
#include <exception>
#include <forward_list>
#include <fstream>
#include <iostream>
#include <random>
#include <set>
#include <string>
#include <sstream>
#include <streambuf> 

lib3/pch.cpp
 
#include "pch.h" 


Front of VT100.cpp:
1
2
3
#include "pch.h"
#include "lib3.h"
using namespace std;


Front of VT100.h (included from lib3.h):
1
2
3
4
5
6
#pragma once

//	The following two lines are necessary because the #include <windows.h>
//	in pch.h is being ignored.
#define WIN32_LEAN_AND_MEAN             // Exclude rarely-used stuff from Windows headers
#include <Windows.h> 

Last edited on
Check the project's properties and see if you are using precompiled headers. Just because you are using pch.h it might be a hold-over that is no longer valid.

Configuration Properties->C/C++->Precompiled Headers.

https://docs.microsoft.com/en-us/cpp/build/creating-precompiled-header-files?view=msvc-170

I look at the options in VS 2022 for a project that doesn't use precompiled headers and the precompiled header is stdafx.h.

Yet I create a new project that does use compiled header and it is pch.h.

*shrug*

Personally I never use that option, precompiled headers, it can screw up, whenever. No rhyme nor reason. I'll take the hit on compile time so I don't have to deal with a buggy compile time using it.

Try doing a complete from scratch rebuild to see if that kicks VS in the butt.
Yes, I'm using precompiled headers. They significantly shorten my build times.
I struggled with trying to get them setup initially. The MS documentation is not that great.

I've done a complete rebuild and that did not fix the problem.
I have heard stories of precompiled headers being flaky, but up until now had not had
any problems with them.

It took me a while to figure out I had to have a pch.cpp file that contained only the
#include "pch.h" and only that cpp file needed to have the /Yc option. The project needed to have the /Yu option.
Topic archived. No new replies allowed.