Add support for the Windows 10 SDK

RESOLVED WONTFIX

Status

mozilla.org
MozillaBuild
RESOLVED WONTFIX
2 years ago
6 months ago

People

(Reporter: RyanVM, Unassigned)

Tracking

(Blocks: 1 bug)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Right now, only the Windows SDK 8.1 is detected. We need to be able to detect SDK10 and default to it if found.
(Reporter)

Comment 1

2 years ago
In my Windows 10 VM w/ the MSVC 2015 & Win10 SDK release candidate installed, I can't help but notice that HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Products doesn't show any real differences from the Win8.1 SDK. HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots does show a KitsRoot10 value which corresponds to the KitsRoot81 used for SDK 8.1.

So this has me thinking if the current method of SDK detection is overly-complicated. Right now, it looks for the Installed Products key first, then querys the KitsRootXX value if found. Then, it checks for the presence of Windows.h to make sure that SDK is REALLY there (and not previously uninstalled). It seems to me that with the Windows.h check we're using, we could save some complexity and query directly for KitsRootXX instead. Seems less fragile to me anyway.

I also need to decide if it's worth adding back support for setting a max SDK version to use. It was supported in 1.x and removed during all the refactoring work done during the 2.0 development cycle. I'm inclined not to and just go with the newest one detected since that's by far the simplest option. The SDK setting logic is all guarded on an |IF NOT DEFINED SDKDIR| check, so someone could just as easily go that route if they want to use a certain version rather than specifying a max version.

So I think the basic gameplan here is:
1) Change the SDK detection logic to look for KitsRootXX directly and use it if found.
2) Look for supported SDKs in descending order with no option for setting a max version to use (but still allowing for a custom SDKDIR when invoking the start script to begin with).
(Reporter)

Comment 2

2 years ago
Oh, and the Windows.h check will need changing since the 10 SDK puts it in Include\10.0.10069.0\um, which is exciting. I hope that doesn't change very often...
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #2)
> Oh, and the Windows.h check will need changing since the 10 SDK puts it in
> Include\10.0.10069.0\um, which is exciting. I hope that doesn't change very
> often...

So the stated aim of MS is that this is the "last" version of Windows.

In practice, it's plausible that if they change core features, the patchlevels/minor numbers will change, potentially - a bit like OS X? Obviously we have no way of knowing. We have some contacts at MS now who've been helpful with our win10 prep already, so I could ask, but it's possible that they can't tell us...

That, or they leave out the intermediate versioned directory once the SDK gets to stable. :-\

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #1)
> In my Windows 10 VM w/ the MSVC 2015 & Win10 SDK release candidate
> installed, I can't help but notice that HKLM\SOFTWARE\Microsoft\Windows
> Kits\Installed Products doesn't show any real differences from the Win8.1
> SDK. HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots does show a
> KitsRoot10 value which corresponds to the KitsRoot81 used for SDK 8.1.
> 
> So this has me thinking if the current method of SDK detection is
> overly-complicated. Right now, it looks for the Installed Products key
> first, then querys the KitsRootXX value if found. Then, it checks for the
> presence of Windows.h to make sure that SDK is REALLY there (and not
> previously uninstalled). It seems to me that with the Windows.h check we're
> using, we could save some complexity and query directly for KitsRootXX
> instead. Seems less fragile to me anyway.

Yes, I looked at updating this locally (against 1.11, IIRC) and had a long boring fight with that bat script which I lost and gave up on. But yes, leaving out the uuid checks seems sensible to me.

> I also need to decide if it's worth adding back support for setting a max
> SDK version to use. It was supported in 1.x and removed during all the
> refactoring work done during the 2.0 development cycle. I'm inclined not to
> and just go with the newest one detected since that's by far the simplest
> option. The SDK setting logic is all guarded on an |IF NOT DEFINED SDKDIR|
> check, so someone could just as easily go that route if they want to use a
> certain version rather than specifying a max version.

I would not add it back for now, and if people have issues we can fix it. I'm happy to play beta-tester here, as noted I had some issues with what I thought would be a trivial change...

> So I think the basic gameplan here is:
> 1) Change the SDK detection logic to look for KitsRootXX directly and use it
> if found.
> 2) Look for supported SDKs in descending order with no option for setting a
> max version to use (but still allowing for a custom SDKDIR when invoking the
> start script to begin with).

Right. How do we set the INCLUDE and LIB things from there, though, given that vcvars for 2013 doesn't do this for us, and with the directory magic? Might need some manual poking specific to the win10 SDK.
Blocks: 1077146
I wonder if we shouldn't think about putting all this compiler/SDK detection into configure instead of MozillaBuild. We could just write a Python script that does all the same logic here, and use it if the user hasn't explicitly specified compiler/SDK paths.
FWIW, as someone who just got bitten by the difference between how we create INCLUDE paths in mozilla build (vcvars) and on our build slaves (hardcoded in the build/ mozconfig files), I would be happy if we unify this by using configure.in everywhere as per Ted's suggestion (though I guess using configure.in would not preclude us from treating build machines specially per se...).

Comment 6

2 years ago
http://blogs.windows.com/buildingapps/2015/06/22/getting-ready-for-windows-10-sdks-compatibility-bridges/

Comment 7

2 years ago
http://blogs.windows.com/buildingapps/2015/06/30/windows-10-sdk-preview-build-10158-released/
(In reply to YF (Yang) from comment #7)
> http://blogs.windows.com/buildingapps/2015/06/30/windows-10-sdk-preview-
> build-10158-released/

Yes. I can confirm that the new release just adds another dot-separated subfolder under the "Include" directory, so now I have both:

%SDKPATH%/Include/10.0.10069
and
%SDKPATH%/Include/10.0.10158

installed.

Selecting the newest might be interesting... :-\

Updated

2 years ago
Depends on: 1190146
Created attachment 8643430 [details] [diff] [review]
patch v0.1

Here's a hacky patch I made to get SpiderMonkey compiling using Windows 10 SDK.

Notes:
- I do not know the UUID of 32-bit Windows 10 to fill in WIN10SDKKEY, so the UUID in the patch is wrong. Any suggestions?
- I did not refactor the detection of SDK into something simpler, just used the existing logic. Is the refactoring strictly needed at this stage?
- I hardcoded the directory where Windows.h resides in, namely "Include\10.0.10240.0\um\Windows.h". Not sure how forward thinking we should be, here.
- I set SDKVER to 10 and SDKMINORVER to 0. I presume this is the information we need from the version (10.0.10240), else suggestions welcome.

I had installed:

- Microsoft Visual Studio 2015 Community Edition
- Selected:
  * Common Tools for Visual C++ 2015
  * Tools and Windows SDK 10.0.10240
  * Git for Windows (not strictly needed unless using Git)

I also separately installed Debugging Tools for Windows. (not strictly needed)

This combination works with SpiderMonkey from m-c rev f3b757156f69, tested by:

- Clone https://github.com/MozillaSecurity/funfuzz.git
- Run start-shell-msvc2015.bat after installing the above.
- Run `funfuzz/js/compileShell.py -b "--enable-debug --enable-more-deterministic --enable-nspr-build --32"

Haven't tested Firefox - I welcome testers!

Not sure if I'll have time to move this forward, so not assigning to myself for now. Someone should feel free to take this to completion.
Attachment #8643430 - Flags: feedback?(ryanvm)
(Reporter)

Comment 10

2 years ago
Can we justify dropping support for the 8.1 SDK?
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #10)
> Can we justify dropping support for the 8.1 SDK?

I don't think we have strong enough reason to do so.
(Reporter)

Comment 12

2 years ago
Comment on attachment 8643430 [details] [diff] [review]
patch v0.1

I agree. This patch doesn't work then.
Attachment #8643430 - Flags: feedback?(ryanvm) → feedback-
Do we have to support for Windows 8.1 to add support for Windows 10?
(Reporter)

Comment 14

7 months ago
The vcvars scripts actually handle Windows SDK detection these days (what we do in start-shell.bat is basically dead code and will be getting removed eventually). On top of that, we're moving more of our compiler & SDK toolchain detection into the build system proper, so there's nothing for us to do here.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
(In reply to Ryan VanderMeulen [:RyanVM] from comment #14)
> On top of that, we're moving more of our compiler & SDK
> toolchain detection into the build system proper, so there's nothing for us
> to do here.

Bug #s for this?
Flags: needinfo?(ryanvm)
Flags: needinfo?(ryanvm)
bug 1289286, FWIW.
You need to log in before you can comment on or make changes to this bug.