Windows GUI Preprocessing

How, using the proprocessor, can I find out if a program is being compiled as a Windows GUI Program? I have a set of headers that I use, and a couple of them deal with Windows GUI programs specifically. How would I be able to prevent their code from being included, if the program is just a normal Console application? If this is compiler specific, I'm interested in info for all compilers that you know of. Thanks.

Ahh. Change GUI to API. My bad.

Well, here are the first lines of my <windows.h> header: (I'm using Visual Studio 2003, but that shouldn't matter, as Microsoft = backwards compatibility :-))

Code:

#ifndef _WINDOWS_
#define _WINDOWS_


#ifndef WINVER
#define WINVER 0x0501
#else
#if defined(_WIN32_WINNT) && (WINVER < 0x0400) && (_WIN32_WINNT > 0x0400)
#error WINVER setting conflicts with _WIN32_WINNT setting
#endif
#endif

#ifndef _INC_WINDOWS
#define _INC_WINDOWS

So, as I see, you can #ifdef-test either of the _WINDOWS_, WINVER or _INC_WINDOWS definitions.

I've already looked into windows.h, winver.h, winnt.h, etc. All the definitions I found were either defined or not defined by the compiler and did not change, regardless of whether I was compiling as an API or as a console. And all of those are defined by the actualy header. I'm looking for something defined by the compiler, only when you're compiling as an API application.

There's nothing standard for detecting this at compile time. The only close is the VisualStudio practice of using "_CONSOLE" for console applications and "_WINDOWS" for non-console applications. These aren't even used by the MS headers. It's just a VisualStudio thing.

Why do you need to distinguish between the two at compile time? Who cares if some GUI headers get included with a console app.

gg

It doesn't really matter, no. I just thought it was possible. If it isn't, ahh well. Thanks for helping.