Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
The nfoCentrale Blog Conclave
nfoCentrale Associated Sites
There are two features of the Windows Platform SDK that cast a spell of confusion on beginners: the name of the PSDK and how one chooses the versions of platform a program is targeted for.
What's in a Name?
Lately, the Platform SDKs -- all of those header files, utilities, libraries, and documents that re freely available for use in developing applications for Windows -- have been given ridiculously-long names with lots of spaces in them.
The last PSDK that I've installed, the one still recommended for users of the Visual C++ 2005 Express Edition, is named
And that's also the name of the folder it installed itself in on my computer.
A beginner who does not happen to have Windows Server 2003 and certainly is not thinking of making programs for Windows Server 2003 is given a certain basis for doubt when told this is the PSDK to download.
The most that can be done, for those who hesitate over this, is point out that (sometimes) the name of the PSDK indicates the latest version of the Windows Platform for which there is complete API support (roughly). The PSDK is still good for at least all versions of Windows that are still supported.
Even knowing this, I find myself reluctant to assume too much about the pre-eminence of two more-recent releases:
where, although the second of these is a replacement for the first, there is no word about the PSDK for Windows Server 2003 R2 having become a legacy PSDK. Don't ask me what kind of directory name these beauties install themselves into. I'm afraid to find out.
For those who do not hesitate over any of this, I can only say, "Welcome to the code-monkey school of development, where you must just do what you are told and the reward of understanding is failure. You are now on level #2." Apparently the reward for code-monkey stardom is being allowed to name a future Platform SDK.
So What Am I Compiling For?
Well yes, that could be an important existential topic.
But today I mean to say, if the Platform SDK that I have installed supports a range of Windows Platforms, how do I know which features are safe to use for those platforms I want my program to operate on? Or, let me put it another way: How do I make sure that I'm not using features that are unavailable on the platforms I want my application to run on?
Those are pretty good questions. Not particularly good for beginners though. One way is to find out all APIs that are being used and determine the platform versions those APIs (and the various options and parameters) were introduced on and supported since. The information is available but not even I am so obsessive as to figure it out for my API dependencies (although I have been so compulsive with Java, where it is easier and rather mechanical).
Actually, these are definitely not code-monkey questions. The early-stage code-monkey asks: "I am using feature x and when I compile my program I get message y" which is usually about something not being defined or not being locatable. The goal is to make the thing defined or locatable and have the message go away and have a program come out the delivery-end of the compiler. The fledgling code-monkey will do anything conceivable to achieve that end so long as it doesn't involve figuring out what is going on which is, as lesson #1 establishes, not rewarded and, as already confirmed in years of school-guppy training (and the no guppy left-behind program), won't be on the test.
Sometimes the program compiles and runs, but when copied onto another machine it then fails to execute, possibly accompanied by further mystery messages. It is at this point that the code monkey can achieve grasshopper status by realizing there may be different questions worth asking. These will not be answered by studying the much neglected built-in help or the online MSDN materials that one might think to seek. The source of difficulty and its resolution is nigh indescribable.
Well, then, one might suppose that without taking any particular action, a program will be compiled for (a) the oldest-platform supported by the PSDK, (b) the most-recent platform supported by the PSDK, (c) the platform you are running Visual C++ on, or (d) none of the above? The answer to this question is "yes."
Sometimes, features of the API are available only if you say you want them. Sometimes features of the API are unavailable only if you say you don't want them. Sometimes how you create your project may influence the gods in granting features to your program. There are certain selections by default.
How PSDK Header Files Honor Your Wishes
Like any wily and tortured genie, the Platform SDK will grant you wishes. And, unless cornered, it will not willingly admit that there are wishes you may command. In particular, it will obey wishes you don't know you've made.
This mystery is buried behind the twin gates of #include and #ifdef, the recursive incantations of which are hidden behind the all-powerful injunction, "Just use #include <windows.h>." The C/C++ Language preprocessor is used to choose those API elements that your program can reference and those that it cannot (so easily). It accomplishes this by checking pre-processor variables, some that are set up by default and others that are not. Your influence on the matter is to over-ride the defaults and/or add definitions that were not provided by default.
There is a sketchy explanation of the top-level of control (failing to identify the versions of PSDK for which it applies, so a lot of beginners will be defining NTDDI_VERSION with no effect). Raymond Chen has provided a handy narrative, although the general rule about "default version" is apparently not so general as all that.
When I first began dealing with free versions of Visual C++, I created a little utility that would let me see what the values of various preprocessor variables happened to be in my programs, whether I had done anything to set them or not. This came to mind today when someone was baffled on the Microsoft Visual C++ Express Edition Forum. In this case, a documented API flag was being reported as not defined. The Forum newcomer had tracked down the PSDK header file having the definition, which was governed by this conditional code:
Although it is a subtle clue, Visual C++ had greyed out the definition, indicating that it was being excluded (that is, the #if is not satisfied).
I compiled up a little version of my utility to see what the default situation is when using VC++ 2005 Express Edition and the Platform SDK on Windows XP SP2 (assuming that the platform I'm on might be a consideration). Here's what my little program reports concerning #include <windows.h> without addition of any special definitions:
Whatever "default" minimum target platform this relates to, it has no name. It is simply whatever windows.h comes up with given those and other initial conditions:
On this machine, the PSDK has 1,577 include files in 15 folders, taking 62 MB. You tell me how it will all sort out. To be fair, there are only 1,278 in the top level, requiring a mere 57.8 MB. When only calling for windows.h, other include files are accessed only around 100 times as part of that single #include.
Flunking Code-Monkey School
So what's a code monkey to do? Why, just let the default happen. All the examples and tutorials and most other programs do too. It must not be a problem.
I can't stand it. I want it to be definite and confirmable what the acceptable target platforms are without having to try them all. I'm flunking code-monkey school!
|You are navigating Orcmid's Lair.|