MSDN mentioned Windows 8 SDK integerated DirectX SDK. http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx
Shall developper skip the 2010 DirectX SDK installation? (I am not very sure since looks some .h file isn't shown in windows 8 SDK)
Any insight ot guide?
Here is a summary of my finding on utilizing Windows 8 SDK to build chromium windows binary, using VS2010.
In general, to build with new SDK, issues mainly come from compile time and link time. While for Chromium case, DirectX related issue looks need a standalone category to discuss it.
So, I tried to divide the major issues into 3 categories:
1) DirectX related issue (bypassed, need systematical way)
2) Compile time issue (4 issues identified)
3) Link time issue (1 issue identified)
For 1) DirectX related issues
There are 5 sub-projects depends on DirectX include and lib file, which are chrome,content_browser,content_common,gl,chrome_main_dll. Since d3dx9.h and d3dx9tex.h are missing from Windows 8 SDK, to enable the those 5 sub-projects building pass w/o Microsoft DirectX SDK (June 2010) need systematical way to decouple. XInput usage inside content_browser is located at same category.
So, I tried to add DirectX June 2010 SDK “include” and “lib” path to above 5 sub-projects, which can help to quickly identify the rest compile and link time issue. It is not mean a full solution of decoupling old DX SDK.
The rest part is mainly focus on 2) and 3), and the most solutions are not elegant enough, just an initial proven of issue and make build done.
Before start, MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props
need to be edited, to make sure new SDK’s path is correctly understood. Here are steps:
i: replace v7.0A(or v7.1 if you already replaced) by v8.0. MSbuild can understand v8.0 since corresponding registry is generated when user install new SDK.
ii: add “$(WindowsSdkDir)\bin\x86” to ExecutablePath
Iii: include files are placed into 2 paths: $(WindowsSdkDir)\Include\shared;$(WindowsSdkDir)\Include\um; add them to IncludePath
iv: add $(WindowsSdkDir)\lib\win8\um\x86; to LibraryPath
For 2) compile time error
2.1 : macro “FACILITY_VISUALCPP” is defined in both Microsoft Visual Studio 10.0\VC\include\DelayIMP.h and new windows 8 SDK, so a macro redefinition error is hit.
2.2: in src\base\win\win_util.cc, bracketed content inside #if !defined(_WIN32_WINNT_WIN8) is not effect. Looks -D_WIN32_WINNT_WIN8 is already passed in, and make macro PKEY_AppUserModel_DualMode and PKEY_AppUserModel_DualMode_UK missing
2.3: _THREAD_INFORMATION_CLASS is undocumented at firstly beginning, so Chrome has an internal definition. In windows 8 SDK, _THREAD_INFORMATION_CLASS is exposed, while limited prototype. So a re-definition error is hit. Remark Windows 8 SDK one temporarily bypassed this issue and make build continue. (remark chrome one won’t work, since prototype inside windows 8 SDK is far away from complete)
2.4: Windows 8 SDK renamed IAsyncOperation to IDataObjectAsyncCapability and renamed IID_IAsyncOperation to IID_IDataObjectAsyncCapability. ui/base/dragdrop/os_exchange_data_provider_win.h need corresponding modification
2.5 browser\importer\ie_importer.cc tried to included "pstore.h" to perform IE imported related. While "pstore.h" is removed from windows 8 SDK, so hit error. It might not reasonable to use old pstore to import IE10. I just copied "pstore.h" from SDK 7.1A to make build continue.
For 3) link time error.
3.1: “RichEd20.Lib” is removed from Windows 8 SDK, and MSFT ask user to loadlib RichEd20.dll instead of link with lib. To make a quick workaround, I just copied “RichEd20.Lib” from SDK 7.1A to make build continue.
Summary
After solving/bypassing above issue, a chromium binary can be build using windows 8 SDK + VS2010. Precisely speaking, it still used DirectX June 2010 SDK and 2 legacy files from SDK 7.1A. Hope it can be a initial input for further enabling.
Samuel
Before start, MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props need to be edited, to make sure new SDK’s path is correctly understood. Here are steps: