Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

missing WINVER variable

(1/3) > >>

Raijinsetsu:
I found that neither CygWin nor C::B are setting this variable during compilation time. This causes a problem when header files un-include functions(it's assumed the version of windows you're using does not support them). I found this problem when using the socket functions "getaddrinfo()" and "freeaddrinfo()", which are now the standard for name resolution when using sockets("gethostbyname()" and "gethostbyaddr()" have been deprecated in both windows and linux). After searching every header file in my CygWin install, I found this:
Line 297 of /usr/include/w32api/ws2tcpip.h
#if _WIN32_WINNT >= 0x0501
This if clause contained the definitions for the functions I was trying to use. _WIN32_WINNT is set to WINVER in a previous header file.

Maybe C::B should automatically define this variable during installation, because I certainly had a hell of a time finding out why the fully documented functions were "not defined" in C::B.

kidmosey:
http://msdn.microsoft.com/library/en-us/winprog/winprog/using_the_windows_headers.asp


--- Quote from: MSDN Library ---You can define these symbols [WINVER, WIN32_LEAN_AND_MEAN] by using the #define statement in each source file, or by specifying the /D compiler option supported by Visual C++.

--- End quote ---

You need to define this variable yourself, either in project settings or before each inclusion of the windows headers.  It works the same as WIN32_LEAN_AND_MEAN; the compiler and IDE have no way of knowing what you want to use for these variables.  Alternatively, you could create your own template to automatically define these.

Raijinsetsu:
I know that you CURRENTLY need to define these yourself, BUT, if, on installation, C::B set WINVER to your windows version, then programmers would not have to worry about why certain functions are showing up as "undefined". When using Visual Studio, these variables are in the compiler, so you don't have to define them. It would be much easier if C::B defined this automatically. Maybe in future versions of C::B?

Ceniza:
Raijinsetsu: I think the approach you're suggesting is really invasive for an IDE. Code::Blocks shouldn't define anything at your back trying to guess what's better for some people. Setting those defines is really up to the programmer and it's his/her choice to decide if the executable will only run with that Instruction Set, CPU and/or OS version because of it or if it'll be more compatible.

Using defines like those could make your executable run on 2k+ but not on 9x/ME, on a P4 but not on a PIII, .... It's really a programmer's choice.

thomas:
Ceniza explained it well. An IDE must not do such things behind the scenes.

In particular, I wonder if you fully understand what these macros are about. Or, you seem to assume that all the programs you write will only ever run on the same machine that you use for programming them, and you never plan to write any kind of thing for anybody else?
This:
--- Quote ---When using Visual Studio, these variables are in the compiler, so you don't have to define them.
--- End quote ---
is certainly not true. It cannot be true. If Visual Studio was setting WINVER=0x501 as a general rule, then you could not write programs that work on anything older than Windows XP. This is certainly not the case.
I don't know how exactly it is handled in Visual Studio (as I don't use this particular product), but very likely there is a choice box in the project settings that lets you define this variable and which defaults to either nothing or a "reasonably low value".

If you want to have this compiler switch added to all your projects, you can modify your project template, but there is no way we could add a feature that willingly and consciously breaks compatibility for the majority of Windows users.

Navigation

[0] Message Index

[#] Next page