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
Related
I downloaded driver which targets Windows 7 (has option "TargetVersion" == "Windows 7" in ".vcxproj"). Also I installed Visual Studio 2022 Community, the latest SDK and DDK (for Windows 11) to compile it.
When I press "Build solution", I get error:
Windows7 is not a supported OS Version
I'm going to open file:
C:\Program Files (x86)\Windows Kits\10\build\10.0.22621.0\WindowsDriver.Common.targets
and comment the following line:
<Error Text=" '$(TargetVersion)' is not a supported OS Version"
Condition="'$(WindowsTargetPlatformVersion)' > '$(TargetPlatformVersion_CO)' and '$(TargetVersion)' !='$(LatestTargetVersion)' " />
Then trying to compile again.. and voila - everything works. Meaning driver works well for all operation systems up to Windows 10.
I do understand I'm doing wrong. So, my questions are:
Why don't Visual Studio developers let us build drivers for Windows 7 if everything works?
What is the correct way to build drivers for all operating systems, starting with Windows 7?
Added later:
I think maybe, for example, latest WDK has more API functions which are missing in Windows 7. It turns out that if we code carefully, checking all calls for compatibility, then there should be no problems with compilation.
Per this page:
To target Windows 8.1, Windows 8, and Windows 7, you will need to
install an older WDK and an older version of Visual Studio either on
the same machine or on a separate machine. For links to older kits,
see Other WDK downloads.
Question #1 - you better ask Microsoft.
Question #2 - you can install multiple SDK and WDK versions side by side. To target Windows 7, install Windows 8.1 SDK and WDK.
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 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?.
I wanna start learning DirectX in Visual C++ 2010, but it says that d3dx11 and d3dx9 can't be found when I include d3dx9.h, I can play games in DirectX 11 and dxdiag says my computer is running directX 11, but when I searched for DirectX 11 in C drive and my D-Drive, it couldn't find anything. So I decided to install DirectX 11 and then I got a folder after installing, but it didn't have any include or bin folders, so I couldn't go to properties and VC++ and add the include directories. Decided to try DirectX 9 instead to start with, but when I installed DirectX 9 June 2010 version, I went to C\Microsoft DirectX SDK (June 2010) there is no directories, only DirectX utilities and documentation for c++ and sample browser and Command prompt. So I don't really know what to do anymore, I have tried to install d3dx9.lib and put in in the default lib folder for VS 2010. but no success, But I have DirectX 9 2004 summer libraries and Include folders set up for visual c++, but that is such an old version so it doesn't include d3dx9.lib. I'm running Windows 8.1 64 bit OS.
The DirectX SDK and all version of the D3DX libraries are both deprecated.
The 'modern' solution is to use the Windows 8.x SDK which comes with Visual Studio 2012 and Visual Studio 2013. You can install the Windows 8.1 SDK 'standalone' and use it with Visual Studio 2010 by using .props files. See MSDN and this blog post for all the details.
You can mix using the Windows 8.x SDK with the legacy DirectX SDK in order to continue to use D3DX for Win32 desktop applications--you cannot use the DirectX SDK for Windows Store apps, Windows phone, or Xbox One. See the instructions on MSDN for how to handle the include/lib path directories. If you are going to continue to use the legacy DirectX SDK, you need to be aware of a number of things:
The DirectX SDK (June 2010) installer has some compatibility issues with systems that have VS 2010 SP1 REDIST installed. See this post.
The DirectX SDK (June 2010) does not have the latest developer debug runtime for Windows 8.1. You have to install the Windows 8.1 SDK, VS 2013, or the VS 2013 remote debugging tools to get the DEBUG layers and REFERENCE device. See this post.
There is no support for the Direct3D 9 DEBUG device on Windows 8.1.
The "PIX for Windows" tool in the DirectX SDK does not work for Direct3D 10.x or Direct3D 11.x on Windows 8.1, Windows 8.0, or Windows 7 SP1 with the DirectX 11.1 Runtime installed. Use the Visual Studio 2013 Graphics Diagnostics, or Intel/AMD/NVIDIA's GPU tools.
If you are deploying a game that needs the legacy DLLs like D3DX, be sure to use the April 2011 refreshed version of DXSETUP and not the copy that is in the DirectX SDK (June 2010). See this post and be sure to read Not So DirectSetup.
Given all that, your life will be a lot easier if you just use Direct3D 11 and avoid the legacy DirectX SDK and D3DX entirely. You can find many Direct3D 11 replacements for D3DX that only requires the Windows 8.x SDK along with a bunch of updated samples. See Living Without D3DX, DirectX Tool Kit, and DirectX SDK Samples Catalog. You can get all that to work with VS 2010, but it's a lot easier to get Visual Studio 2013 Express for Windows Desktop (for Win32 desktop applications) and/or Visual Studio 2013 Express for Windows (for Windows Store apps and Windows phone apps).
PS: Even back when the DirectX SDK was still the supported way to get Direct3D headers for VS 2010, it was not available until you manually added the include/path directories to your project. That's why you can't include "d3dx9.h" in your project freshly created.
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 :)