Why won’t this code compile on my system?
#include <windows.h>
#include <winbase.h>
#include <stdio.h>
(snip …)
mpDev[0] = ‘F’;
mpDev[1] = ‘:’;
mpDev[2] = ‘\’;
mpDev[3] = 0;
DeleteVolumeMountPoint( (LPCTSTR) &mpDev[ 0 ] );
(snip …)
The compiler says: DeleteVolumeMountPoint: undeclared identifier.
Any ideas?
From your link
And to answer the follow up question (“why do I have to do that?”), this allows you to write code which will compile to be run on older versions of windows that don’t have that particular API. If you’re writing a program that’s supposed to run on Win98, then you want to get an error if you try to use an API that doesn’t exist there. You use the _WIN32_WINNT macro to indicate the minimum platform you’re writing for.
Cool, thanks.
But, did that, same problem.
Did you define the macro before the ‘include’ directives?
Yes I did. I double and triple checked I had it typed in right too.
I installed the “general” SDK this morning. I have been programming for over 20 years.
I can’t figure it out. It finds windows.h and winbase.h, why not DeleteVolumeMountPoint?
Thanks for the ideas.
No typo?
#define _WIN32_WINNT 0x0500
Are you using precompiled headers (e.g. stdafx.h)?
Well I cut and paste the #define out of the documentation. I don’t believe I am using any pre-compiled headers, just the 3 .h files I listed.
[assuming you’re using Visual Studio…]
A good way to troubleshoot this if you’re really stumped is to go into the properties dialog for the source file, look at the compiler settings, and look at the bottom of the window where it shows the actual command line it is going to use to compile. Copy that command line, open a “Visual Studio Command Prompt”, cd to the directory with your source file, and paste the command line into your shell. You should get the exact same error. Now paste the command line into notepad, add a /P option to it, and paste it into your shell again. This time, the compiler will create a .i file that matches your .cpp or .c file (e.g. foobar.cpp -> foobar.i). This file will be very large, but also very informative. It is what results from running your source file through the preprocessor, and you can see what all the macros got converted into, and you can see what parts of header files have been skipped over because they got ifdef’d out. Examining this file should give you clues for determining if your _WIN32_WINNT macro is set correctly.
Maybe it’s LPCTSTR giving me the problem? I will try using that elsewhere and see if it complains.
Seems highly unlikely, given the error message you cited. If you haven’t already, try doing a clean build.
Just throwing a few more silly things out:
I cut and pasted this example into a source file:
I created a project under VC++ and tried to build it.
Same error.
I guess I’d find the declaration of DeleteVolumeMountPoint and make sure it’s not wrapped in some other #ifdef/#ifndef section.
OK, sounds good. I can use my editor to search files. Back later.
I have just gone into Visual Studio and created a console app from the source linked above and it compiled for me with no problems at all. Looking at winbase.h, the only #define I see around DeleteVolumeMountPoint is the version one mentioned previously.
I suspect that something is set up in your search paths so that an older version of winbase.h is being used.
Indeed that is the problem, multiple .h files. I think if I can get my paths setup right I should eventually get this to work. Thanks.
Did that work ccwaterback?
I haven’t had a lot of time to work on it. But, I did a build with everything I know of pointing in the right direction, and it still didn’t work. I think the next thing I will try is shipping the “old” .h files to some other country before I try another build!!!
One of the problems is, I have several compilers on this machine. We have to support all kinds of systems at several different version levels.
I haven’t given up yet.
This isn’t a big mystery if you just do some legwork. Go into the properties dialog for the .cpp file in question. Look at the compiler settings, particularly the bottom part that shows the actual command line that compiles the file. One of the options on the command line will be responsible for including an incorrect include path (probably a /I option) that gets you the wrong winbase.h (or possibly some other wrong header which fails to include winbase.h – you can find out for sure if you follow my advice and painstakingly plow through the preprocessor output). Figure out which option is causing this, and then figure out which thing in the compiler settings (e.g. “additional include directories”) is causing that option to be added to the command line.