Setting WINVER for MFC Applications

re: Setting WINVER for MFC Applications

S. Colcord — Fri, 23 Mar 2012 16:47:22 GMT

This recommendation makes sense if a developer's top priority is to move quickly to take advantage of the latest, greatest, OS APIs, such that they're willing to expend a fair amount of effort supporting simultaneous old and new API usage within the same product. I can see why it's in Microsoft's interests to move people to new APIs ASAP, so I can believe that this is recommended practice for MS teams.

However, for most development shops, it doesn't make sense to spend a lot of effort developing features that only customers on recent OS versions can take advantage of. It's much more cost effective to develop for the lowest common denominator, unless the new APIs offer something incredibly compelling.

re: Setting WINVER for MFC Applications

Marcello F. — Thu, 22 Mar 2012 18:47:25 GMT

BTW, I have found a serious bug in at least one of the collection classes of the MFC that yields wrong results, when building my application with optimizations enabled. This doesn't happen when I build the app with the optimizations disabled (ie: debug build). I have verified this with MFC 4.2 dynamically linked. I haven't tested yet what happens when compiled with the latest version of the MFC but I am very concerned.

re: Setting WINVER for MFC Applications

Marcello F. — Thu, 22 Mar 2012 03:01:34 GMT

I have checked the source files in VS2008 and many if not all of the WINVER defines are in the headers files, in structures and inline functions. I wonder how if the MFC is built targeting Windows Server 2003, there wouldn't be problems when loading the libraries in a different OS ie: Windows XP? Maybe this is another good reason to program in .NET: so we don't have to worry about these issues? There are not #defines in .NET.

re: Setting WINVER for MFC Applications

GregM — Fri, 16 Mar 2012 14:33:48 GMT

Rob, I know, i've found one of those myself. I reported it in connect, and it was fixed in a future version. Do you know if that one has been logged in connect?

re: Setting WINVER for MFC Applications

RobM — Fri, 16 Mar 2012 10:40:03 GMT

GregM: Option a: set the WINVER to the lowest value, and load functions that aren't available to you using GetProcAddress when the compiler tells you that it isn't available.

Warning - not all functions are protected by WINVER #defines.

StrFormatByteSizeEx is one example of a function which is not protected.

re: Setting WINVER for MFC Applications

GregM — Thu, 15 Mar 2012 15:42:07 GMT

JLO, or even worse, X + 1.

re: Setting WINVER for MFC Applications

JLO — Thu, 15 Mar 2012 08:49:46 GMT

Maybe because of the "best practice" MS platform SDK includes are buggy and some API is marked as available only starting OS X while it is actually available starting OS X minus one.

re: Setting WINVER for MFC Applications

GregM — Thu, 15 Mar 2012 03:12:09 GMT

Option a: set the WINVER to the lowest value, and load functions that aren't available to you using GetProcAddress when the compiler tells you that it isn't available.

Option b: set the WINVER to the highest value, and load functions that aren't available to you using GetProcAddress when you look up in the documentation and find that it's not available to you.

Hrm, which is more error prone? I guess it's Option b! I'll stick with Option a thank you.

Pat, can you explain what automated methods you have for doing Option b that the rest of us obviously don't know about? I assume that you must have some.

re: Setting WINVER for MFC Applications

jalf — Wed, 14 Mar 2012 22:23:04 GMT

So, a naive question:

If the "best practice" from Microsoft really is to actively *prevent* the compiler from detecting errors, shouldn't the compiler team step in and create some more powerful tools? Say, extend the /analyze switch to detect and flag all API calls to functions defined in higher versions of Windows than some specified value, allowing me to flag, for example, all API calls that rely on Vista or newer.

re: Setting WINVER for MFC Applications

Adrian — Wed, 14 Mar 2012 19:42:10 GMT

This certainly wasn't considered the best practice when I worked at Microsoft. It seems contrary to the immense effort Microsoft has historically put into backward compatibility. We always set the macros to the oldest supported version. Where ever you want to uses a newer API, you called LoadLibrary/GetProcAddress and locally declared any missing structures. That kept the newer structure definitions from leaking back into the general purpose code and ensured nobody ever unknowingly called an unsupported API.

The best advice along these lines that I've ever heard is to develop on the oldest version of the OS you plan to support, and test (primarily) on the most recent. Unless the developers experience the pain points that their users will experience first hand, it's hard to understand the priorities of fixing these. I used to work on a large team, and we had developers on a wide variety of the supported OSes and hardware. This was a while ago, so we had some developers on Windows 3.1, some on NT4, some on 95, etc. It was great for discovering and debugging platform-specific issues.