I am looking to create a portable version of a program for Windows 8 that requires VCRedist 2010 and DirectX 10 to run properly. However, I am unable to use the installers because they attempt to install to the system path and, while the computer I am working on has administrator rights, I do not have it on the computers I will be transferring it to. After a lot of research, It seems I can include the VCRedist 2010 and DirectX 10 dll files in the application folder, but I have been unable to find a list of all the required dlls. If this is true could someone provide me with a list of them, and if it's not true does anyone know of an alternative way to do this?
System info: 32 bit OS, Windows 8
The first thing to say here is that you never redistribute DirectX. It is part of the operating system and can only be updated by a service pack, upgrading the OS, or through Windows Update. That has been true since Windows XP Service Pack 2, but it is a poorly understood fact.
The DirectX End-User Runtime packages (aka DXSETUP and DXWSETUP) never installs any version of DirectX on any version of the operating system! That has been true for over a decade.
If your application makes use of one of the side-by-side optional components that ship in the legacy DirectX SDK such as D3DX9, D3DX10, D3DX11, D3DCompile #43, XAudio 2.7, XInput 1.3, or XACT, then you must use the legacy DirectSetup package to redist those DLLs as they are never part of the operating system. Using DirectSetup always requires administrator rights.
See Not So DirectSetup for a fuller explanation.
For Windows 8 standard user only application, a better option is to use DirectX 11 and make use of one of the many open source replacements for D3DX functionality. If you need XAudio, you can use XAudio 2.8. If you use D3DCompile, you can include it side-by-side with your application from the Windows 8 SDK. If you use XInput, you can use XInput 1.4 or the older XInput 9.1.0.
Note that Windows 8.0 is now end-of-life. While still supported as a target for Visual Studio 2015, those users are expected to upgrade to either Windows 8.1 or Windows 10 to maintain support. In Windows 8.1, the D3DCompile #47 DLL is already part of the operating system.
Visual C++ 2010, 2012, 2013, and 2015 DLLs can be included side-by-side (aka application local deployment). You can use the Windows 8.1 SDK with VS 2010 using props files, but I'd recommend moving to a newer version of Visual Studio which can more easily make use of Windows 8.1 SDK content.
Another option here is to use VS 2013, target Windows 8 Store, and use that to handle all the deployment which does not require admin rights. You still have to use Direct3D 11 and avoid all use of legacy DirectX SDK components including D3DX9/D3DX10/D3DX11.
See Where is the DirectX SDK?.
Related
I am really rusty when it comes to writing code on Windows. From what I know for 2015 there was a change in the way even the standard library is shipped (UCRT in particular).
So now I am standing in front of a Visual Studio 2015 project targeting Windows 8.1 SDK with build toolset v140 that doesn't compile due to a library (part of the project) not being able to find sstream, memory, excpt. I even checked excpt and the error comes from Windows.h.
I also have Visual Studio 2017. I went on using the installer to install Windows SDK. The problem is there are many versions of it...
Currently I have (quoting 1:1 what Visual Studio 2017 installer is giving me):
VC++ 2015.3 v14.00 (v140) toolset
VC++ 2017 version 15.9 v14.16 latest v141 tools
Windows Universal CRT SDK
Visual C++ ATL for x86 and x64
Visual C++ MFL for x86 and x64
Windows 10 SDK (10.0.10240.0)
Windows 10 SDK (10.0.10586.0)
Windows 10 SDK (10.0.14393.0)
Windows 10 SDK (10.0.15063.0) for Desktop C++ [x86 and x64]
Windows 10 SDK (10.0.15063.0) for UWP: C#, VB, JS
Windows 10 SDK (10.0.15063.0) for UWP: C++
Windows 10 SDK (10.0.16299.0) for Desktop C++ [x86 and x64]
Windows 10 SDK (10.0.16299.0) for UWP: C#, VB, JS
Windows 10 SDK (10.0.16299.0) for UWP: C++
Windows 10 SDK (10.0.17134.0)
Windows 10 SDK (10.0.17763.0)
Windows 8.1 SDK
Windows Universal C Runtime
I'm assuming Windows 8.0 SDK is not listed, since it's an essential component that gets shipped with Windows 10 upon installing the OS.
When looking for memory.h it appears that it's only in the ucrt subdirectory of each Windows 10 SDK (e.g. C:\Program Files (x86)\Windows Kits\10\Include\10.0.14393.0\ucrt\memory.h.
I come from Linux where in all honesty things appear to be simpler when it comes to setting up a development environment (I can only imagine what it is to develop cross-platform on Windows -_-) so I am probably missing something rather obvious here.
Can I mix includes from different SDKs? (here: Windows 10 and 8.1 SDK) Upgrade is currently not an option. If that's not possible how do I deal with the situation?
You're coming from Linux, where things are mixed up. Windows is actually a lot cleaner.
The Windows OS headers come from the SDK.
The language headers come from the language implementation
C++ has headers such as <memory> (note the lack of .h). These will come from Visual Studio. This is not the same header as memory.h. Similarly, <sstream> is another C++ and therefore Visual Studio header.
The UCRT is a bit of a special case - it's a Universal C RunTime. C as a language is stable (which is a nice way to say there's not much improvement anymore). Windows ships a fairly decent chunk of the C standard library in the UCRT. Since C++ includes the C Standard Library in its own, Visual Studio can build on top of the UCRT.
Another major difference is that the Windows SDK's are SDK's for a particular Windows version and many preceding versions. There's no need to use the Windows 8.1 SDK; everything in there is also in all the Windows 10 SDK's. Also, the Windows SDK's are not tied to Windows itself. You can develop for Windows 10 using the Windows 10 SDK on Windows 8. There would never be a reason to mix two SDK's.
I'm using Visual Studio 2017 to develop console applications in standard C++. When installing VS2017, I can install both Win 8.1 SDK and Win 10 SDK. VS2017 seems to offer Win 10 SDK by default, but I keep coming across projects that are configured to use Win 8.1 SDK (e.g., MPIR or projects created in previous versions of VS). Thus, I'm wondering:
Which SDK is preferable to use for standard C and C++?
Can I safely link together libraries that use different versions of Windows SDK? E.g., can I have MPIR compiled against Win 8.1 SDK and call it in an application that uses Win 10 SDK?
This Microsoft page suggests that it usually doesn't matter which you use. In particular, it says,
When you deploy your application, you can link it with /MT option to completely avoid CRT related dynamic link libraries and in most cases you don't even need the redistributable run-time then. All the toolset functions are then present in your module and don't need any other dependencies.
I have Windows 7 installed, and I would like to use OpenGL. So I want to use the opengl32.lib(I wrote DLL before, but it's .lib).
My problem is, this library is in a folder named Windows Kits -> 8.0 or 8.1 but I don't find anything about 7.x.
Is this a problem, or can I use this opengl32.dll to start developing with OpenGL?
The folder you are talking about is created whenever you install a Windows SDK or WDK folder. For example the default folder for WInodows 8 is:
Program Files\Windows Kits\8.0\ or Program Files (x86)\Windows Kits\8.0\
Note: Your operating system does not have to be Windows 8 in order to use the SDK (though Windows 8 features may not workin a backwards compatible way).
In addition, the current version of OpenGL32.dll is compatible with WInodws 7 and 8.
https://www.khronos.org/opengl/wiki/Getting_Started#Windows
Just to confirm everything is okay with your system, check if your computer has the required prerequisites for the SDK. It looks OS-wise like you will be fine as Windows 7 is among the compatible operating systems.
For the 8.0 library MSDN says:
The Windows SDK requires the following software and hardware on the computer:
One of the following operating systems: Windows 7, Windows Server 2008 R2, Windows 8, or Windows Server 2012
To install the .NET Framework 4.5 Software Development Kit feature, you must install the .NET Framework 4.5 redistributable package before you install the Windows SDK. You can download the redistributable package from Microsoft Download Center.
10 megabytes (MB) to 1 gigabyte (GB) hard disk space for installation, depending on the features that you want.
https://msdn.microsoft.com/en-us/library/ms717422%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396
I was just told that the SDK that I was using (Jun 2010) is not to be used anymore and that I need to use whatever new one they have included to Win10. Well where is it?
I am trying to start a graphics demo solution and I can't call D3D11 functions because of Linker errors which to me means I need to include libraries and such.
If anyone can help me figure this out so I can get the ball rolling then I'll be good.
The Microsoft Doc page Where is the DirectX SDK? tells you to use the Windows SDK, specifically the Windows 8.0 SDK, Windows 8.1 SDK, or Windows 10 SDK to do DirectX development (which is assumed to be Direct3D 11 or Direct2D/DirectWrite). Direct3D 12 requires the Windows 10 SDK.
If you are using Visual Studio 2013 or later, then you already have the Windows 8.1 SDK and optionally the Windows 10 SDK.
An important detail is that the D3DX library (D3DX9, D3DX10, and D3DX11) is deprecated and only available in the legacy DirectX SDK. That means D3DX11 is not part of the Windows SDK, and you shouldn't use it.
UPDATE: For older projects, the legacy DirectX SDK 'end-of-life' June 2010 release of the D3DX9, D3DX10, and D3DX11 library is provided in this NuGet package which is to be combined with the Windows 10 SDK. See this blog post for the full details.
For HLSL, you use D3DCompile directly or the FXC that comes with the Windows SDK. For math, you use DirectXMath that comes with the Windows SDK. If you are using legacy Effects 11, you can use the version from GitHub. I recommend you also take a look at DirectX Tool Kit for DirectX 11 and it's tutorials. For a complete list of replacements for D3DX, see Living without D3DX.
If you really want to continue to use the legacy DirectX SDK components with Visual Studio 2012 or later, you can but you should note the details at the bottom of the MSDN page above. Notably you have to reverse the include/lib path order when you add the legacy DirectX SDK to your project.
For a complete catalog of where the various bits of the old DirectX SDK ended up, see DirectX SDKs of a certain age, DirectX SDK Tools Catalog, DirectX SDK Samples Catalog, as well as the Living without D3DX article above.
The Direct3D 11 Debug Device for Windows 10 is not installed by any Windows SDK or by the legacy DirectX SDK. It is a windows optional feature. See Direct3D SDK Debug Layer Tricks.
The actual "DirectX Runtime" has been part of the operating system since Windows XP Service Pack 2. The legacy DirectX SDK never installs "DirectX" on any modern version of Windows, and only deploys some optional side-by-side stuff. It's not required at all if you using the Windows SDK. See Not So Direct Setup.
I am very confused on what I need in order to use the latest version of the DirectX SDK.
There is the DirectX SDK (June 2010), which is apparently deprecated and there is the Windows SDK for Windows 8.1.
What is so confusing is that I can't figure out if the Windows SDK for 8.1 will work using Windows 7 and Visual Studio 2013 for Desktop, or if I have to use the DirectX SDK (June 2010) with Windows 7 and Visual Studio 2013 for Desktop.
Also, if I use Windows SDK for 8.1, how do I include it in my Visual Studio Projects. Any help?
The DirectX SDK has been rolled into the Windows SDK starting with version 7.0. Unless you need certain deprecated features such as DXUT, specifically the runtime shader compiler, you'll be fine just running with the Windows SDK.
If, however, you want to use the deprecated features of the DirectX SDK, you'll need to include both SDKs, with the Windows SDK set to have higher priority than the DX SDK. If you include both and see a redefinition warning, then you included them in the wrong order.
If you have Visual Studio 2013 Express for Windows Desktop (or VS 2013 Pro or better), then you have the Windows 8.1 SDK and will use it for any C++ project by default. To support 'down-level' systems such as Windows 8.0, Windows 7 and/or Windows Vista, you need to set the _WIN32_WINNT preprocessor symbol appropriately (_WIN32_WINNT=0x0601 for Windows 7 or later). There's nothing else special you need to do, and you can use DirectX 11.0, DirectXMath, XInput 9.1.0, etc. on all these platforms without any need to use the legacy DirectX SDK. The HLSL compiler (D3DCompile #47) DLL is available in the Windows 8.x SDK to just copy into your apps folder for Win32 desktop apps, although on Windows 8.1 it is already part of the OS as well.
Where is the DirectX SDK (2013 Edition)?
Where is the DirectX SDK?
Ideally you would avoid using D3DX11 and use any of the many alternatives available that support Win32 desktop apps on Windows Vista or later.
You can of course still also use the legacy DirectX SDK with the Windows 8.x SDK (which unfortunately you have to for XAudio 2.7 on Windows Vista/Windows 7; XAudio 2.8 is part of Windows 8.x), but you need to remember that the include/lib path order is reversed since the headers in the DirectX SDK are now older than those in the Windows 8.x SDK. This is covered on MSDN. Remember that if you use the legacy DirectX SDK components like D3DX, XAudio 2.7, XInput 1.3, XACT, D3DCompiler #43, etc. then you also need to rely on the legacy DirectSetup deployment. In this case, it is recommended you make use of the refreshed version of the REDIST rather than the one that shipped in the legacy DirectX SDK.
BTW, if you are trying to target Windows XP with the "v120_xp" Platform Toolset, you are actually using the Windows 7.1 SDK and not the Windows 8.x SDK since the Windows 8.x SDK does not support Windows XP. See this post for the many caveats of this scenario, or save your sanity and just let Windows XP go away :)