Closed Bug 1430634 Opened 3 years ago Closed 3 years ago

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

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set
normal

Tracking

(firefox59 affected)

RESOLVED WONTFIX
Tracking Status
firefox59 --- affected

People

(Reporter: jfkthame, Unassigned)

Details

Attachments

(1 file)

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)?
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?
Attachment #8942706 - Flags: review?(mh+mozilla)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
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?
Attachment #8942706 - Flags: review?(mh+mozilla) → review?(dmajor)
Yes, we can't unconditionally bump WINVER as long as we support Win7/8.1.
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.
Attachment #8942706 - Flags: review?(dmajor)
(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?
Flags: needinfo?(VYV03354)
(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.
Flags: needinfo?(VYV03354)
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.
Assignee: jfkthame → nobody
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
No longer blocks: 1430632
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.