More <windows.h> weirdness

[AbstractionAnon]

What's the trick to including <windows.h>?
I have two projects. The first has the following includes:

#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.

[Peter87]

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?

[AbstractionAnon]

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.

#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" 

[Peter87]

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

[George P]

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.

[George P]

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.

[seeplus]

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++.

[AbstractionAnon]

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.

[AbstractionAnon]

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

#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:

#include "pch.h"
#include "lib3.h"
using namespace std;

Front of VT100.h (included from lib3.h):

#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> 

[George P]

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.

[AbstractionAnon]

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.