My application requires Microsoft DirectX June (2010)/lib/x86 however the only things that appears when opening the folder are DirectX Utility folders.
My theory is that the download must have been updated or something because when I downloaded Detours again the files were different.
Anyone know how to get the lib file?
The legacy DirectX SDK is available from download from the Microsoft Downloads site. The self-extracting EXE itself is now SHA-256 signed, but the content is unchanged from the June 2010 release.
http://go.microsoft.com/fwlink/?LinkId=226640
The legacy DirectSetup REDIST image is available here:
http://go.microsoft.com/fwlink/p/?LinkId=159853
http://go.microsoft.com/fwlink/?LinkID=194352
The self-extracting EXE, DSETUP EXEs/DLLs, and CABS are now SHA-256 signed, but the content is unchanged from the April 2011 refresh.
Keep in mind there are numerous known issues with these old bits. In particular, your original report sounds like you may have hit this issue:
https://walbourn.github.io/known-issue-directx-sdk-june-2010-setup-and-the-s1023-error/
https://learn.microsoft.com/en-US/troubleshoot/windows/win32/s1023-error-when-you-install-directx-sdk
Finally, if you are trying to use the legacy DirectX SDK with VS 2012 or later, the integration instructions are different. See https://learn.microsoft.com/en-us/windows/win32/directx-sdk--august-2009
Note that you really shouldn't need to use the legacy DirectX SDK at all.
The Windows SDK already includes the include headers and link libraries for d3d9.lib, d3d10.lib, d3d11.lib, dxgi.lib, dxguid.lib, etc. See https://walbourn.github.io/directx-sdks-of-a-certain-age/
If you need d3dx9, d3dx10, or d3dx11, you should use this NuGet instead which provides the headers, link libraries, and a simple side-by-side REDIST for those DLLs. They are also SHA-256 signed. See https://walbourn.github.io/legacy-d3dx-on-nuget/
If you need XAudio2 for Windows 7, then use this NuGet instead. See https://aka.ms/xaudio2redist
If you need dxerr.lib, build it yourself. See https://walbourn.github.io/wheres-dxerr-lib/
If you use the legacy Managed DirectX 1.1 assemblies, use SharpDX or SlimDX instead. https://walbourn.github.io/directx-and-net/
The only scenarios where you still have to use the legacy DirectX SDK are (a) to target Windows XP or (b) to use XACT.
Related
I am working on a software product that goes waaaay back. Part of our source code is a project that builds baseclasses. This is supposedly a project that ships with the Windows SDK and is used for developing apps that reference DirectShow.
Unfortunately the version we have checked in to our repository is out of date and issues many warnings when we build (all related to warning C4996: 'GetVersionExW': was declared deprecated).
Personally, I cannot find any information about how to find the newest (or indeed any) version of this little nugget of Windows goodness. As recently as a few days ago Microsoft Learn published a tutorial about this very topic (https://learn.microsoft.com/en-us/windows/win32/directshow/directshow-base-classes). But, it is essentially useless.
For example, if I click here: https://learn.microsoft.com/en-us/windows/win32/directshow/using-the-directshow-base-classes it tells me:
The base class library is provided as a SDK sample in the Microsoft
Windows Software Development Kit (SDK)
(https://go.microsoft.com/fwlink/p/?linkid=62332). The exact location
depends on the version of the SDK that you have installed, but the
relative path is:
(SDK samples root)\DirectShow\BaseClasses
I have Visual Studio 2022 installed and there is no such path in its directory tree, nor in C:\Program Files (x86)\Windows Kits. However, if I click on the link quoted, it sends me to a page that basically tells me that all I need to do to get the Windows SDK is download Visual Studio. Hmmmm....
Does anyone know how to get a contemporary version of the DirectShow base classes? Microsoft is not being very helpful on this point.
This is a classic Microsoft: Moving things around but failing to update references.
If you navigate to DirectShow sample apps, you'll find the link to the new GitHub home under Windows-classic-samples/Samples/Win7Samples/multimedia/directshow/, including the baseclasses directory.
Since you are explicitly asking for a "contemporary" version of the DirectShow base classes, that's what the GitHub repository contains. They haven't been (to my knowledge) updated since. DirectShow is in maintenance mode, and Microsoft encourage clients to use more recent technologies instead (such as Microsoft Media Foundation or the Windows Runtime types under the Windows.Media.Capture namespace).
For this reason I copied the directshow baseclasses and included them in the project, when I implemented GraphStudioNext. I didn't touch the project in a while but maybe this helps: https://github.com/cplussharp/graph-studio-next/tree/master/baseclasses
PS: I just saw, Roman has a more updated version of the base classes: https://alax.info/blog/2157
I'm trying to learn DirectX 12 and i found out these tutorials on github. I downloaded everything and i tried to run the HelloWindow project. I linked the d3d12.lib in Debug->Options->Linker->Input. Unfortunately, it gives me a bunch of errors from d3dx12.h. For most of them, Intellisense says to include d3d12.h even if i already did it. For example, D3D12_RESOURCE_DESC1 is undefined and all his attributes too etc. Did i missed something if yes pls help me.
You are using the 'latest' copy of D3DX12.H which requires you use the 'latest' version of the Windows 10 SDK (19041). If D3D12_RESOURCE_DESC1 is undefined, you are using an older Windows 10 SDK.
Note that there are three different options for fixing this mismatch:
Install the latest Windows 10 SDK (19041). For VS 2019, this is done by running Visual Studio Installer and selecting the new Windows 10 SDK as a component. For VS 2017, you need to run the standalone installer. VS 2015 and earlier are not supported.
Use a version of the D3DX12.H utility header that supports older SDKs. I maintain a version of the 'latest' D3DX12.H header that contains a bunch of preprocessor conditionals so that it will support Windows 10 SDK (14393) or later. That happens to be last version of the Windows 10 SDK to support VS 2015. Obtain it from GitHub: directx-vs-templates.
Use GitHub DirectX-Headers: A new option is to get the latest headers including D3DX12.H as a set from GitHub. You still need a Windows 10 SDK for the link libraries.
See this blog post for details on why D3DX12.H is not part of the Windows 10 SDK.
The samples on DirectX-Graphics-Samples in the main/master branch assume you are using the latest Windows 10 SDK (19041).
As you are new to DirectX 12, you may want to take a look at DirectX Tool Kit for DX12 as a more gentle introduction to the latest version of the API.
We're moving to Visual Studio 2017 and VS2017 prompts us to retarget the projects for 2 things: Windows SDK Version and Platform Toolset.
Currently our application can run on older Windows versions (at least to Server 2003, possibly older), and we need to retain the same (I know they're not supported anymore, but that's the customer's requirement).
Assuming that our code (which is all C++ in case it makes a difference) does not use any APIs which are only available on newer versions of Windows, will re-targeting to a newer version of the Windows SDK restrict or limit the versions of Windows that our app will run on?
And while on the subject, will re-targeting to a newer version of the Windows SDK have any pros or cons (ex. performance) (again, assuming we don't use any of the new APIs that are only available on newer Windows)?
No, using a newer SDK allows use of newer funcntionality but it does not require doing so. So long as you are careful to only use functionality that is present on the version of windows you are interested in your program will continue to work. You will, however, likely need to install the vs2017 runtime on the client systems.
You will need the VC++ runtime for the development kit that you are building from. Statically linking this library will remove this requirement, as the runtime is embedded in your binary.
I haven't been able to find any information on this issue:
I have a C++ Windows Phone 8.1 library project, I would like to convert it into a portable library without having to recreate the project and set all parameters.
I guess it should be possible to do it by editing the vcxproj file, but I don't know how to modify it to make it work.
I meet several issues:
What is the equivalent of Portable Library (C#) for C++?
How to change an existing Windows Phone 8.1 C++ project into this equivalent?
Thanks :)
In general, Windows Phone 8.x doesn't support sharing of binaries with Windows desktop because the import libraries are different between the two (eg, desktop apps link against kernel32.dll but that DLL doesn't exist on Windows Phone). You could share between Windows Phone 8.0 and 8.1 though (provided you only used features available in 8.0).
In theory you might be able to make a static lib that was shared if it didn't depend on any Windows APIs, but it's not really supported. You could try creating a new Static Library project and diffing it against your current project to see what settings have changed.
This changes in Windows 10, where shared binaries are fully supported (obviously you still need ARM vs x86 vs x64 builds depending on CPU architecture).
According to Maximize code reuse between Windows Phone 8 and Windows 8 C++ is not supported as PCL language as this is a .net framework technology.
Note that Portable Class Libraries are a .NET Framework concept and don’t support C++
I also looked into Visual Studio to confirm that and couldn't find a template.
I'd rather not install the entire VS 2008 installation given that I'm not going to be using anything other than the compiler. Will VS 2010's multitargeting work correctly using only the Platform SDK instead of the full VS2008 install?
The custom setup options are not nearly fine-grained enough to allow you to leave the big chunks like the IDE out. It isn't just the SDK that's used, at least the VC subdirectory needs to be there. And bits of Common7, also the folder that contains the IDE. Rename the folders, delete them later if it works out.
You can directly call the .net 3.5 MSBuild from command line by digging it out of the frameworks folder within windows. I am not certain if you could repoint Visual Studio at a different copy though. More importantly, unless you have found a bug, the copy of MSBuild included in the .Net 4 framework should properly build a project targeting the 3.5 framework. So you might be jumping through some unnecessary hoops in the first place.