should _WIN32_WINNT be set to _WIN32_WINNT_WIN10 or _WIN32_WINNT_WIN7

[Nico Weber]

Hi,

we set _WIN32_WINNT to 0x0A00 here: https://cs.chromium.org/chromium/src/build/config/win/BUILD.gn?type=cs&q=_WIN32_WINNT+file:%5C.gn&sq=package:chromium&g=0&l=309

That means _WIN32_WINNT_WIN10; we changed that from _WIN32_WINNT_WIN7 in https://codereview.chromium.org/1502563003 when updating to the Win10 SDK.

Does _WIN32_WINNT identify the version of Windows that's available at build time or at runtime? To me it sounds like the latter -- should we keep setting this to _WIN32_WINNT_WIN7 (and then manually declare functions that need newer Windows versions, so that we don't forget to check if they exist)?

It looks like we have some targets that manually do this (e.g. https://cs.chromium.org/chromium/src/chrome/elevation_service/BUILD.gn?rcl=c4756c3b2567d902e33e0cfeed32042b2074f3da&l=26) but since chrome still runs on Win7, maybe the global setting should be win7?

Thanks,

Nico

[Scott Graham]

I always thought that define was just controlling what functions were exposed in headers, so what was available at compile time.

The PE has an OS version number that I think is what controls what it can run on as far as the loader is concerned, assuming that all imports it tries to acquire are available.

(My limited knowledge may be outdated though!)

[Nico Weber]

Thanks for the reply!

If it's just meant to identify the SDK version, why is it user-settable? Couldn't windows.h just set it to the latest-version-available-at-sdk-ship-time then?

[Scott Graham]

I think the intention would be to make new SDKs build-compatible with old versions.

So if you set it to WIN7, you can't accidentally use a Win10-only function. We're totes confident that we're smart though (or at least are saved by good CI), so we use the prototypes in the headers, but GetProcAddress or /delayload to make sure we can still run on older OSs.

[Christian Biesinger]

But if you call a function that's new in Windows 10 the binary won't
run on Windows 7 because the Win7 DLLs won't have it?

Christian

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CANHK6RbXi0RiAbGD-0wWM0MZ%3DzfyP9tsE10t6fD99QZkJRiWXA%40mail.gmail.com.

[Nico Weber]

Got it. So https://cs.chromium.org/chromium/src/chrome/elevation_service/BUILD.gn?type=cs&q=_win32_winnt%3D+file:%5C.gn&g=0&l=23 is a misunderstanding and shouldn't exist?

[Nico Weber]

Oh wait, the comment talks about WRL, which isn't our code. But grepping for WIN32_WINNT in win_sdk/Include/*/winrt/wrl doesn't find anything. ganesh, do you remember why the explicit _WIN32_WINNT_WIN7 was needed for WRL?

[Scott Graham]

Probably not and I should just crawl back in my hole!

I guess because WRL is header-only it uses that as a signal that it's OK to use Win10 apis (not totally unreasonably). I think we'd probably have to add quite a lot of prototype-copies (and maybe structure definitions too) if we reduced the macro to Win7 globally though.

(I will bow out now for someone who probably really knows what's going on.)

[S Ganesh]

Search for NTDDI_VERSION in the WRL sources, and you will see conditionals of the form:

#if (NTDDI_VERSION >= NTDDI_WINBLUE)

NTDDI_WINBLUE is Windows 8.1. 

_WIN32_WINNT and WINVER are also set to Windows 7 in my code for uniformity with NTDDI_VERSION.