#519 sdkddkver.h

w32api (251)
Earnie Boyd

Microsoft is now using a sdkddkver.h file to help define which versions of the OS are supported. It is mostly documented at http://msdn.microsoft.com/en-us/library/aa383745\(VS.85).aspx with a few items of the patch coming from comments on social.microsoft.com.


  • Keith Marshall

    Keith Marshall - 2012-07-07

    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

    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.

  • Earnie Boyd

    Earnie Boyd - 2012-07-12

    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.

  • Keith Marshall

    Keith Marshall - 2012-07-12

    > I've updated the patch file ...

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

  • Peter Rosin

    Peter Rosin - 2012-07-12

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

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

  • Earnie Boyd

    Earnie Boyd - 2012-07-12

    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.

  • Earnie Boyd

    Earnie Boyd - 2012-07-16
    • assigned_to: ir0nh34d --> earnie
  • Earnie Boyd

    Earnie Boyd - 2012-07-16

    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.

  • Keith Marshall

    Keith Marshall - 2012-07-17

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

    #ifndef WINVER
    # define WINVER _WIN32_WINNT

    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?

  • Earnie Boyd

    Earnie Boyd - 2012-07-17
  • Earnie Boyd

    Earnie Boyd - 2012-07-17

    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.

  • Peter Rosin

    Peter Rosin - 2012-07-17

    > 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...


  • Keith Marshall

    Keith Marshall - 2012-07-20


    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).

  • Earnie Boyd

    Earnie Boyd - 2012-07-29
    • milestone: --> IINR_-_Include_In_Next_Release
    • status: open --> open-fixed
  • Earnie Boyd

    Earnie Boyd - 2012-07-29
    • status: open-fixed --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks