sdkddkver.h

Looks good to me, but there are two aspects which don't seem quite right: as I read MSDN, (and Raymond Chen's blog, at http://blogs.msdn.com/b/oldnewthing/archive/2007/04/11/2079137.aspx\), Microsoft's current intent is that we should no longer define WINVER or _WIN32_WINNT, but rather we should define only NTDDI_VERSION, and leave sdkddkver.h to provide appropriately consistent definitions for all of WINVER, _WIN32_WINNT, and even _WIN32_IE; (at least, in theory -- some community comments suggest that it doesn't quite work,in practice). Your implementation omits _WIN32_IE entirely, and, unless I'm missing something, reverses the associativity of the relationship between NTDDI_VERSION and _WIN32_WINNT/WINVER.

Additionally, this

+#ifndef WINVER
+# ifdef _WIN32_WINNT
+# define WINVER _WIN32_WINNT
+# else
+# warning WINVER is defaulting to _WIN32_WINNT_WIN2K
+# define WINVER _WIN32_WINNT_WIN2K
+# endif
+#endif

block can never be reached with _WIN32_WINNT remaining undefined, (it is immediately preceded by a block which ensures that it is defined), so the inner #Ifdef ... #else is redundant: the #else clause can NEVER be reached. You may wish to revise this logic.

I found hints on social [1] suggesting some more constants to add:
NTDDI_WINXPSP4
NTDDI_WS03SP3
NTDDI_WS03SP4
NTDDI_WIN6
NTDDI_WIN6SP1
NTDDI_WIN6SP2
NTDDI_WIN6SP3
NTDDI_WIN6SP4
NTDDI_VISTASP2
NTDDI_VISTASP3
NTDDI_VISTASP4
NTDDI_WS08SP2
NTDDI_WS08SP3
NTDDI_WS08SP4

[1] http://social.msdn.microsoft.com/Forums/nl/visualfoxprogeneral/thread/ea486c53-2198-4b1c-a4fe-ffd5c6b7974e

I've updated the patch file to check for a defined NTDDI_VERSION to default _WIN32_WINNT. If both are defined but not matching I give an error stating so. I also added NTDDI_WIN6 and NTDDI_WIN6SP1 but the other macros are meaningless since the service pack they represent do not exist.

> I've updated the patch file ...

I don't see that here; perhaps you've just not yet gotten around to uploading it?

> ...but the other macros are meaningless...

Even so, they are there in the PSDK. Not that I care all that much...

Guess I must have forgot to click the Upload button. The file is changed now, I removed the older version.

We cannot just copy PSDK.

I found evidence of VISTA SP2 at http://windows.microsoft.com/en-US/windows/downloads/service-packs so I've included it.

> We cannot just copy PSDK.

Which we wouldn't, we're picking up hints in Pascal sources on social.msdn.microsoft.com. See the reference in my comment from 2012-07-10.

http://social.msdn.microsoft.com/Forums/nl/visualfoxprogeneral/thread/ea486c53-2198-4b1c-a4fe-ffd5c6b7974e

Any other comments on this? I prefer not to add MACRO for service packs that do not exist. I would like to commit this to CVS soon.

Better, but logic for ensuring WINVER is defined is still redundant:

#ifndef WINVER
# define WINVER _WIN32_WINNT
#endif

is all you need, because there's no way to get there without _WIN32_WINNT having been defined beforehand.

You may wish to consider issuing a warning, (or raising an error), if a user predefined WINVER conflicts with user defined NTDDI_VERSION or _WIN32_WINNT; what do MS do in this case?

Ok, I simplified the setting of WINVER as suggested. I'm not sure what MS does with it, I would need their compiler to find out. I believe they are default WINVER to _WIN32_WINNT if it isn't defined as you've suggested.

> I prefer not to add MACRO for service packs that do not exist.

They do not exist yet. But they might appear, and what is the point of requireing bleeding edge w32api to target a freshly released SP? Sure, an older w32api will not have anything activated in the headers for the new SP, but it is also not sure that the sources of some project will use anything that is introduced by the new SP, but the project might still define NTDDI_VERSION to require the most recent SP for some obscure political reason.

Anyway, I don't know of any such project and don't care all that much, but the easy path seems to be to add the future proofing defines and forget about it. I guess what I'm trying to say is that I don't understand the reluctance...

Cheers,
Peter

Peter,

I can see both sides here, but on balance, I stand on Earnie's side of the fence. Sure, we can invent and include pre-emptive definitions for any number of imagined future service packs. Where would we stop? More importantly, what REAL benefit would accrue? If the API exposes no new functionality, there is no advantage to users, in requiring the newer service pack definition; pragmatically, the absence of the definition serves as an alert that nothing specific to its associated service pack is currently supported.

Time enough to add the definition, when there's actually something to support, and which is dependent on the service pack, (which implies that the service pack must actually exist).