Accessing Windows 2000 specific APIs

Having trouble accessing the new Windows 2000 APIs? This article may help.

In order to access Win2000 specific APIs etc, one needs the following #define in
the application's stdafx.h (before any other #includes)

#define _WIN32_WINNT 0x0500

With the latest platform SDK, this also has the side effect of changing the
definition for the OPENFILENAME struct; in particular it makes it larger. This
is because of the following lines in the "CommDlg.h"

Now, <afxext.h> will (indrectly) #include <CommDlg.h> and define CFileDIalog all
without the offending _WIN32_WINNT.

NOTE: This only works because the VC_EXTRALEAN stops <afxwin.h> from including
CommDlg.h earlier.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

About the Author

Comments and Discussions

After a long time reading through lots of articles about the destructor crash following using the Open file dialog and _WIN32_WINNT == 0x0500, like by Paul Dilascia, this article gave me the clue for the solution.

Not that its exactly difficult, but a little info goes a long way in this business.

Okay so implementing the define / undefine frig solves the problem, but functions like CoInitialiseEx disappear.

The solution is to follow the #undef as follows:

#undef _WIN32_WINNT
#def _WIN32_WINNT 0x400

This then brings into scope the extended function and now my app compliles.

Thanks Roger!!

The real problem with Microsoft is that they dont work for their clients, they just fuss around looking for ways to tie us forever into their nasty API´s and constant changes. Look at the IE style open dialog! There is just no easy way to get and set the view style the user sets, and not even on IE7 does it remain permanent! What a pain!

Hello Sir,
as for my school works of programming, i am writing a Java
program to speak out the text highlighted in the Web browser( IE,
or Netscape), but i encounter difficulty in getting the highlighted
text, i talked with others that suggest me to study about windows API,
i studied about windows Clipboard API, but still couldn't success.~~
if you got idea of this, could you pls tell me a bit~~
Thanks Very Much...~~
...have your good days~~

This fix worked great for me until I needed to use the CoInitializeEx() function and the compiler kindly informed me it did not exist. It seems that the file gets included a couple of levels down in the MFC include files.

To get around this, instead of undefining the _WIN32_WINNT constant, redefine it as 0x0400. This makes the standard NT COM functionality available and everything seems to be happy.

Now I haven't had a chance to check out what the implications of this are (i.e. what other interfaces (COM and non-COM) are being reverted to their NT4.0 versions or what W2K is being turned off). Does anyone know of any articles that might address this? If not, it is probably worth checking into.

You can use "delayloaded" calls to the DLLs that you are using that have new functionality. This way you do not need to manually obtain function addresses and cast them yourself.

However, although this will allow the application to get loaded by the OS, it is ultimately up to the application to also detect the OS version at runtime, and be sure not to call the functions that do not exist on that older OS

Check out my C++ Explicit Linking Framework at http://www.beginthread.com/Article/Ehsan/0000000e . Using this framework, you can easily call functions that may not be present on some versions of windows without worrying about performing a windows version checking, and also all the LoadLibrary/GetProcAddress stuff is done automatically for you.

If you had any question and/or comments on this, please email me.
Hope you'll find it useful.

Roger Onslow wrote:Yes.. I know one can check for the OS dynamically at run time, but that doesn't help with missing entry points in dlls when the app is loaded

Ok, assuming you'll only call a function in the appropriate OS, you can use delayload. VC++ can create stub functions which load the DLL only when it's called first time. It's implemented in such a way that the overhead is only in the first call. In fact, if well used, can speed up application start time.