1430634 - Bump the WINVER setting in old-configure.in to 0A00 (Win10)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement)

Description

[Jonathan Kew [:jfkthame]]

Currently, old-configure sets WINVER=601, which means that post-Win7 APIs in the Windows SDK are not visible when building Gecko. Can we bump it to Win10, to make it easier to use new APIs (with runtime checks for availability, so that we can still run on older systems)?

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Bump WINVER to 0x0A00 so that new Win10 APIs are visible during the build

This seems to build successfully, with just a couple of minor fixups needed. Can we go ahead with something like this, or do we need to keep the old WINVER, and manually declare any newer interfaces etc that we want to use?

Comment 2

[Mike Hommey [:glandium]]

Comment on attachment 8942706 [details] [diff] [review]
Bump WINVER to 0x0A00 so that new Win10 APIs are visible during the build

What is not clear from the various descriptions of WINVER on msdn is whether this means the resulting build won't work on older versions of Windows, and some descriptions on e.g. stackoverflow suggest that's the case. So unless we're unsupporting Windows 7 and 8, this might not be the right move. But I don't know for sure. And I'm not even sure who would know. dmajor?

Comment 3

[Masatoshi Kimura [:emk]]

Yes, we can't unconditionally bump WINVER as long as we support Win7/8.1.

Comment 4

[Mike Hommey [:glandium]]

Comment on attachment 8942706 [details] [diff] [review]
Bump WINVER to 0x0A00 so that new Win10 APIs are visible during the build

Review of attachment 8942706 [details] [diff] [review]:
-----------------------------------------------------------------

:emk answered my question and knows this stuff.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Masatoshi Kimura [:emk] from comment #3)
> Yes, we can't unconditionally bump WINVER as long as we support Win7/8.1.

What would break if we do, out of curiosity? FWIW, I pushed a try job that appeared to pass tests OK on Win7: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4f57e2fdfe68f11734e1ef14f20351d8f60b6b98. Obviously, that's not an exhaustive test, though.

Otherwise, I guess the way forward for now is to locally #undef WINVER and redefine it as needed before #include'ing relevant Windows headers in a source file that needs to see new interfaces?

Comment 6

[Masatoshi Kimura [:emk]]

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> (In reply to Masatoshi Kimura [:emk] from comment #3)
> > Yes, we can't unconditionally bump WINVER as long as we support Win7/8.1.
> 
> What would break if we do, out of curiosity? FWIW, I pushed a try job that
> appeared to pass tests OK on Win7:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=4f57e2fdfe68f11734e1ef14f20351d8f60b6b98. Obviously,
> that's not an exhaustive test, though.

For example, WSD_SECURITY_CERT_VALIDATION will change the structure size when WINVER >= 0x0602. Although it is not used in our tree atm, Microsoft can add incompatible definitions anytime. It is not a supported configuration.

See bug 328306 about a past example in our tree.

> Otherwise, I guess the way forward for now is to locally #undef WINVER and
> redefine it as needed before #include'ing relevant Windows headers in a
> source file that needs to see new interfaces?

Yes. Do not forget take the file out of UNIFIED_SOURCES.

Comment 7

[Jonathan Kew [:jfkthame]]

OK, I guess we're not doing this, at least for now. I'll try to work around it as noted above in bug 1430632.