This exactly, thank you. Sometimes you can’t untangle the defines in another header and they infect your own.

Modules are a nice barrier to guard against side effects.

Yes, the number of times I've had a `LoadLibrary` function name conflict with `windows.h`'s `A`/`W` suffix-switching or had to deal with X11's `#define Status int` "typedef" mucking with completely unrelated code is…sad.

Just don't include those in headers.

That's not possible. Windows.h is a requirement for anyone working on Windows. Various standard library implementations make use of macros to implement debug-only assertions, or bounds checks in containers.

Don't include it in headers = only include it in a .cpp file.

Because `void*` to pass `HANDLE` around is better how? Maybe if you're able to hermetically seal off platform-specific bits, but usually you'll have two parts that want to talk about Windows API types across their call boundaries…

It's called encapsulation.

Sure, but I also prefer talking directly about what you're talking about though. If you have some Windows implementations that need to talk to each other, I'd rather they use HANDLE and HMODULE than "void* winkwinknudgenudge" style things. Hopefully users don't need to include these headers directly (but sometimes they do), but it's still something you need to consider in the APIs and such because while the header might say LoadLibrary, the caller is going to need to include windows.h and deal with the #define anyways.

any interaction with the win32 api should be hidden within your library.

Surely you want your code to be portable to begin with?

It can be portable and still want to expose native information. SDL2 is probably something we can all agree is portable, but this still exists: https://wiki.libsdl.org/SDL2/SDL_SysWMmsg