So, I've got Windows 10.0.18358.1 installed, latest Visual Studio (17, not bothering with 19 as of yet), updated (Insider) Windows SDK which should include the DX12 SDK.
And, yet, I have no DXSDK_DIR environment variable set.
I can see all of the DX and D3D headers and libs in the windows kits folder, but their distribution doesn't really correspond to a typical include/bin/lib structure.
Suggestions on how to correct this? I'd settle for copy of anyone's set output
that has this working.
(DirectML tag is because that is the feature that I require, and the source of all of this insanity.)
The DXSDK_DIR variable was only used by the legacy DirectX SDK and the 'beta DirectX 12 SDK' test vehicle, it's not used by the Windows 10 SDK as the standard WindowsSDKDir already includes the required headers & libraries.
If you are building with the Visual Studio build system, you don't have any special setup to use the DirectX 12 headers as they are all in the path already. Likely, your project is set to use the 10.0.17763 Windows 10 SDK by default, so to use the Windows 10 Insider SDK, you'll need to modify the project settings <WindowsTargetPlatformVersion> element to reference the newer 10.0.18xxx version.
If you are using some more manual build system, then you should use the include paths for the Windows 10 SDK side-by-side structure:
%WindowsSdkDir% is typically "C:\Program Files (x86)\Windows Kits\10\"
%WindowsSDKVersion% is something like "10.0.17763.0\"
%arch% is "arm", "arm64", "x64", or "x86'
INCLUDE=%WindowsSdkDir%include\%WindowsSDKVersion%shared;
%WindowsSdkDir%include\%WindowsSDKVersion%um;
%WindowsSdkDir%include\%WindowsSDKVersion%winrt;
%WindowsSdkDir%include\%WindowsSDKVersion%cppwinrt
LIB=%WindowsSdkDir%lib\%WindowsSDKVersion%um\%arch%
See Microsoft Docs and this blog post
The Windows 10 SDK does not include utilities which are instead shared source. For D3DX12, you can obtain the latest header from here
You may also want to look at DirectX Tool Kit for DX12, DirectXTex, and DirectXMesh
For historic and usability reasons, DirectXMath is part of the Windows 10 SDK, but you can also get the latest version from GitHub. The recent Windows 10 SDKs also include the HLSL compiler/D3DCompile API including both the older FXC.EXE and the new Shader Model 6 DXC.EXE.
You may also find the Visual Studio templates on directx-vs-templates useful.
I would suggest reverting to the previous build and flagging the issue in the Feedback Hub. Also, if you haven't already, run chkdsk before and after install, just in case.
Related
Is there any compatibility matrix as to what Visual Studio Versions (Say, ranging 2005 - 2017) are compatible with which Windows SDK Versions?
Should any Windows SDK be fully compatible with "any" C++ compiler, or are the different Windows SDK versions bound to certain compiler versions?
For example(!), we have a legacy C++ application that is still compiled with VS2005. We found that we'd like to use GetDpiForMonitor from this application. But to use this function, would require to use the headers+libs from at least an SDK supporting Windows 8.1 (e.g. the 8.1 SDK headers at C:\Program Files (x86)\Windows Kits\8.1\Include\um)
Generally, should a developer expect to be able to switch to a newer Windows SDK version without upgrading his compiler / Visual Studio?
Please refrain from suggesting to upgrade VS: This question tries to establish what you should do when upgrading VS is not an option for now, but you want to use stuff from (and depend on) functionality only available in newer Windows (SDK) versions.
concerning the "compatibility matrix": I don't think anybody made the effort to up to create one, also I'm not sure if this is really needed.
Rule of thumb: those API headers don't change quite often, and when they do, they are usually pretty much backward compatible.
The tricky part may be to teach your older VS to get along with a new SDK, you may need to change the VC+ include/source/lib directories for your solution/project manually.
(if it complies & links in your old VS, you should be fine)
Is Inspect a part of the Windows 10 standalone SDK?
Is there any alternative application to "inspect" for windows 10?
I want to install "inspect" tool on my machine running windows 10 build 10586 (for testing purpose).
According to Inspect documentation on MSDN it is not described if it is a part of win 10 sdk also or only upto win 8.1.
Also is there any alternative tool for "Inspect" to debug on windows 10?
Since 10.0.15063 the directory of the tools has changed. See the changelog:
To improve the developer experience, tools and metadata will lay down in versioned folders.
This will allow developers to isolate the SDK and tools between
releases.
You have to put the version of the Windows SDK between bin and x64 (or x86 or arm)
For me inspect is in the folder C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
The folder C:\Program Files (x86)\Windows Kits\10\bin\x64 (without the SDK version) exists, but does not contain the inspect tool.
Needed Components for "Inspect":
Inspect is, indeed, included in the Windows 10 "standalone SDK" available from Microsoft here. Note the installer stub allows you to download several "features" (additional toolkits and utility packages) besides the Windows SDK proper. If all you want is Inspect, you can save yourself downloading about 300MB (650MB installed) of unnecessary packages by deselecting everything except "Windows Software Development Kit":
As for an alternative to Inspect, this answer suggests Windows Detective. Not having used the tool, I can't speak personally to its safety or suitability for the purpose, so caveat emptor, YMMV, May the Force Be With You and all that.
If you are using Visual Studio 2017, you can also install Inspect via the Visual Studio Installer.
All you need is to install the following feature, or a later version:
Windows 10 SDK (10.0.15063.0) for UWP: C#, VB, JS
After doing that you should find inspect.exe in the following location:
C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64
In windows 10, Inspect.exe is available at C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\arm64.
Steps in Jul 2022
https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/
Download the 22621.1.220506-1250.ni_release_WindowsSDK.iso and launch it, windows 10 will automatically mount it as D.
Install this: d:\Installers\Windows SDK for Windows Store Apps Tools-x86_en-us.msi
After that, inspect.exe will be available in C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x86\inspect.exe
If you can't find the tool in the Windows 10 SDK, you should be able to download and install the Windows 8.1 SDK from the SDK archive page:
Windows and Windows Phone SDK archive
Inspect is available here: C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64. Based on version changes you can find it in one of the versions under the x64 folder.
Regarding the second part of the question, about an alternative, I've tested an interesting one that works very well, FlaUInspect. Is targeted for an "automation perspective", giving details useful for writing automated tests for example.
Is open source under an MIT license. Can be found on GitHub.
On loading up a direct x 11 SDK project example, after linking all Libs./includes ETC that I was given an error from; I came across the following within an fx file.
VS version : VS ultimate 2013
Example name : 'DepthOfFeild10.1'
SDK : 'Microsoft DirectX SDK (February 2010)'
fx file name : 'DepthOfField10.1.fx'
error : Error 1 error X3000: syntax error: unexpected token 'cb0'
Perhaps I'm missing a lib/tool/set-up procedure ?
(Running Debug, X64)
Advice appreciated.
First of all, if you are trying to use VS 2013 and the legacy DirectX SDK together, be sure to read MSDN.
You need to use a different include/lib/executable path order with VS 2012 and later than the default VS 2010 projects that come with the legacy DirectX SDK February 2010 and June 2010 releases.
Many of the legacy DirectX SDK samples have been updated to remove the need to use the legacy DirectX SDK at all since VS 2013 and the Windows 8.1 SDK are generally sufficient. These are published to GitHub. See DirectX SDK Samples Catalog. DepthOfField10.1, however, is not one of these because it's an AMD sample. You can find AMD's version of it in their archive.
Start with the DirectX SDK (June 2010) version of DepthOfField10.1 (install it from the sample browser).
Open the DepthOfField10.1_2010.sln file and let it Upgrade the VC++ Tools and Libraries to v120.
Edit the Project Properties -> VC++ Directories:
For all configurations and the Win32 Platform, set it to:
Executable Directories: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x86
For all configurations and the x64 Platform, set it to:
Executable Directories: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86;
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x64
If you were using VS 2015, then you also need to add the blog version of DXERR and remove the legacy DirectX SDK version of dxerr.lib from the project. A quick hack of DXUT is needed to resolve the ASCII/UNICODE differences. This is needed because VS 2015 includes some C99 related standard library changes that fail to link with the old version of strsafe.h used to build the legacy DirectX SDK.
Once this is done, it builds and runs as is.
Note: Most of the Direct3D 10 samples in the legacy DirectX SDK make use of the old Effects (FX) system. There's a Direct3D 11 version of Effects available, but the HLSL compiler support for Effects is officially deprecated. See Effects for Direct3D 11.
If the problem is happening in our own projects, then likely you have mis-configured the FXC command-line for building that .fx file.
Running the WindowsSdkVer.exe shipped with Platform SDK 7.1 does not work.
None of the .BAT files in VS 2005 get updated.
can anyone please tell me how to correct this?
Also, how do I verify that VS2005 is using Platform SDK 7.1?
There are several articles for this in MSDN but none of them for above configuration.
Also, none of them describe the concrete way / definate way of verifying this
You could try to manually set the include and lib paths of the VS environment under
Tools->Options->VC++ Directories
or something like that (it's been a while).
For verification, you can add the /showIncludes parameter to the additional compiler options of the project, and /verbose:lib to the additional linker options to double check that the correct headers/libraries are being used when compiling/linking the project.
IIRC there was some kind of incompatibility between one of the newer versions of the SDK (could have been version 7) and using VS2005, but I can't recall off hand what that was.
You can use below method for using Windows SDK 7.1 with Visual Studio 2005.
Configuring Visual Studio for Visual C++ Development with the Windows SDK
In the link , you can find the contents with
"To use the Windows SDK Configuration Tool in Visual Studio 2008".
Even though it has such title, you can use the same procedure also for VS2005.
Start the Windows SDK Configuration Tool by clicking Start, then All Programs, then Microsoft Windows SDK v7.1, and then Visual Studio Registration.
Right-click Windows SDK Configuration Tool and then click Run as
administrator.
In the Windows SDK Configuration Tool, in the list, select v7.1.
Click Make Current.
I'm using Microsoft Visual Studio 2008 (VC9) to compile a project that has a .dsw file. I already have the 2010 and would prefer to use it, but it seems this dsw was built for 2008.
I'd like to compile and produce a binary that's also compatible with Windows 7. My questions:
if I compile with 2008, will the resulting binary be compatible with Windows 7? I'm not sure at which version of VS did Windows 7 support start.
or does this have nothing to do with the VS version, and is instead related to the Windows SDK? If that's the case, can I use VS2008 with a newer Windows SDK?
Can someone please clarify.
Microsoft has a great backwards compatibility "story", so pretty much anything you compile with any version of Visual Studio/Visual C++ will be compatible with Windows 7. The same may not neccessarily apply in reverse, i.e. if you use an API that's introduced in Windows 7, your application will error when you try to run it on prior versions of Windows.
There are a couple of things to consider though:
If the project was originally written to target Windows XP or earlier, it may fall foul of UAC
There are changes to directory structures (such as %systemdrive%\Documents and Settings becoming %systemdrive%\Users) that are fairly well handled by the link that Windows 7 creates in the root of `%systemdrive%, but you may fall foul of these.
VS2010 includes version 7.0 of the Windows SDK and VS2008 does not. You need Windows SDK v7.0 if you want your app to take advantage of Windows 7 features like jump lists.
Since you already have VS2010 installed, you can just change your include file / lib file paths in VS2008 to point to the Windows SDK v7.0 instead of the default one provided with VS2008. This is assuming you need that version of the SDK.
You do not need the latest Windows SDK if you do not plan to use the latest Windows 7 features like ribbons and jump lists. If you are building your app for the lowest-common-denominator OS (i.e. Windows XP), then really you should be fine using VS 2008 with default settings.
The other concern is, if your code was originally written before Windows Vista came out, it is likely that it will not work properly on Windows 7 unless it is run in Administrator mode, which is something you want to avoid. The only way to fix that is to rewrite much of your code to avoid writing to certain protected directories and avoid using certain APIs that require Administrator privileges.
Windows SDK is well backward compatible. See binary compatibility report between Windows 6.0 and Windows 7.0 on x86_64 generated by the abi-compliance-checker tool for the detailed comparison.
Reports for other Windows versions are here: https://abi-laboratory.pro/index.php?view=windows