The dynamic HLSL shader linking feature is (perhaps intentionally) only available in DirectX 11.2 on Windows 8.1+ and I found this out a little late in the game. I'm not able to upgrade my dev box at this time but in the near future I may have access to a separate machine that does have Win8.1.
Is there a way I can compile (but not run) my project with DirectX 11.2 on my Windows 7 machine so I can get access to this feature?
If that is the only 11.2 feature you use you can actually both build and run it on Windows 7, since you are allowed to redistribute d3dcompiler_47.dll (which implements the linking entrypoints) with your application. Just install the 8.1 SDK on your Win7 machine, and you should end up with all the necessary files to build and run: d3dcompiler.lib, d3dcompiler.h, and d3dcompiler_47.dll. Note you can find the redistributable version of the dll under Windows Kits\8.1\Redist\D3D.
If you don't want to install the full SDK on your dev machine, you can install it somewhere else and just manually copy over the header and lib. In general it's a bad idea to mix and match SDK components but the HLSL compiler shouldn't have any cross-dependencies that would cause problems.
Related
I want to run some C++ on my Laptop GPU with Windows 11. I saw in the Internet that I need the Intel OpenCL SDK. I tried to download it, but I got a warning that it's only recommended for Windows 10. I still continued with the installation, but i can't find all the C++ header files. Is that because I use Windows 11 or is there another reason for this?
I thought that the Download would contain all the OpenCL header files and so on.
You don't need the Intel OpenCL SDK for OpenCL development. All you need is the graphics driver, which probably is already present, and the OpenCL header files. For how to set it up in a Visual Studio Community project, see here; this works for Intel/AMD GPUs too, and on both Windows 10 and 11.
After porting some of my programs from VS2015 to VS2017 in noticed that the binaries no longer run on Windows 7 or Windows XP - even though they have been compiled with v141_xp toolset. The program fails to start with missing DLL api-ms-win-core-rtlsupport-l1-2-0.dll (note the 2).
I'm well aware that those api-ms-win-* DLL's belong to the UCRT and that, starting with VS2015, I have to redistribute the UCRT DLL's from the Windows 10 SDK (to be found at Redist\ucrt\DLLs in the Windows 10 SDK directory), along with my application - just redistributing the vcruntime140.dll and msvcp140.dll is not sufficient. But there is only api-ms-win-core-rtlsupport-l1-1-0.dll in my Windows SDK directory, but not api-ms-win-core-rtlsupport-l1-2-0.dll. I just downloaded and re-installed the latest Windows SDK (10.0.15063), just to be sure. Still the DLL in question is absent!
I also tried installing the VS2017 Redistributable package on the Windows 7 (or XP) machine via VC_redist.x86.exe - latest version downloaded from Visual Studio web-site (14.11.25325). Obviously that copies the api-ms-win-* DLL's into the "System32" directory. But, again, only api-ms-win-core-rtlsupport-l1-1-0.dll, but not api-ms-win-core-rtlsupport-l1-2-0.dll. App still won't start.
[EDIT]
This of course only applies if I link against the DLL runtime (/MD). If I link against the "static" runtime (/MT) I get a binary that has no DLL dependencies on UCRT and runs fine on Windows 7 and XP.
[EDIT #2]
Please refer to my other post (including EDIT) for the resolution of the mess:
https://stackoverflow.com/a/45773325/1766377
Okay, this is quite interesting: Just now my VS2017 found a new update. Apparently that updated my VS2017 from v15.2 to v15.3.1. The runtime libraries were updated as well, it seems!
There are now two directories, VC\Redist\MSVC\14.11.25325 and VC\Redist\MSVC\14.11.25415, inside my VS2017 install directory. The vcruntime140.dll exists in both directories. But the newer version (25415, right) has quite different dependencies, compared to the older one (25325, left):
Only the "new" version has dependencies that are missing on Windows 7. So, I should be fine going with the "old" version. But it means I'm locked to the "old" version. Is this normal / intended ???
(BTW: Both DLL versions from VS2017 v15.3.1 are newer than the one I originally took from v15.2)
[EDIT]
So, it was just brought to my attention that there is a subtle difference between the VC\Redist\MSVC\14.11.25325 and VC\Redist\MSVC\14.11.25415 directories: The 25415 directory has all DLL files inside another sub-folder called onecore, the other one doesn't. Apparently, this means that the "newer" DLL versions (the one with onecore sub-folder) are not supposed to be redistributed with normal Desktop applications; they are strictly for the "OneCore" Mobile/IoT platform.
Conclusion:
M$ did a great job to design the Redist directory structure as confusing as possible. Putting the version numbers of the "normal" and the "onecore" redistributables on the same level of the directory hierarchy (rather than having separate onecore and desktop directories on that level) indicates that those directories represent different versions of the same thing - which isn't the case at all :-/
Do *not* redistribute any */onecore/* DLL's with normal Desktop applications!
In the property pages for the project, try changing the Windows SDK version from 10.0.15063.0 to 10.0.10240.0. I think that will fix it, provided that the older SDK is installed on your build machine. Something else to try is to change the platform toolset to v140_xp. VS 2017 then builds with the VS 2015 tool chain, provided that VS 2015 is installed.
My personal preference is to avoid any 'DLL hell' by linking with the static runtime, although this won't work if an exe and a dll need to share a heap and incurs some space penalty if you are building several binaries (I just have two).
I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
I've got some experience in programming for Windows environment but I need to develop a "Kiosk" (I've heard that this is the right name) on a BeagleBone Black. I'm totally new to Linux and also new to the tools I'm going to use. Until the last couple of months, I developed with VB6 and C++Builder only.
Right now I have Eclipse, MinGW and wxWidgets working on my Windowns 7 64-bits PC, and the BeagleBone Black booting a Debian 7.8 with LXDE.
I need to setup a tool-chain to compile for the BeagleBone Black. I tried really hard and have read at least hundred pages, but still I've not figured it out.
From This Site I've learnt that it's possible to compile for Linux from Windows, which could be the perfect solution. If not possible, I already have a Virtual Machine running Ubuntu (but I can change it if needed) ready for Eclipse and other stuff installation.
I'm still lost about what tool-chain to use/build with. This site seems to have already built a tool-chain, but there's no indication to where to go from there. I understand that I should now compile the wxWidgets with this tools, but I'm unsure and also I don't want to mess-up my current working setup in Windows 'cause I missed a switch or a path.
I see how this question was asked more than one time, but I didn't find one that is up-to-date so I'm asking it again.
How to make a tool-chain to compile a GUI application, from Windows using Eclipse, MinGW and wxWidget for a BeagleBone Black running Debian and LXDE?
You need a compiler that runs on Windows and produces binaries for the target platform (Debian arm).
You need a SDK (headers, libs) for the target platform.
The MinGW-64w wiki describes how to build MinGW cross-compiler and build environment.
You can also look at SO: C++ cross-compiler from Windows to Linux.
Another technique is Canadian Cross, like Google makes its Android NDK for Windows host. At first you should setup Linux build machine. Then build GCC and binutils that will run on Windows machine and will produce binaries for Debian arm. Then copy built toolchain to Windows Cygwin or MSYS environment.
Ideally, I want to compile our QT-based apps, which also link other third-party libraries, on 64-bit Linux using GCC, but for a 64-bit Windows target. Again ideally, I want the result to run on 64-bit Windows without any additional runtime support, just as if we had compiled the same source code in Visual Studio. Is this possible with MinGW-w64?
I have successfully used MinGW-w64 to compile simple apps with GCC on Windows. I'm not sure how much of the MinGW-w64 installation is runtime support for executables as opposed to support for the GCC compilation environment. I did attempt to run a WinGW-w64 hello world executable on an installation of Windows without MinGW-w64, but had missing dll errors. This tells me that some runtime support was necessary, but I would like to know more precisely what is required.
If you don't want to install Windows, I think the best way is using a Virtual Machine. That's because even if the source code compiles for Windows, how could it be verified to run? You will need a real target environment to finally test your application.
From a complexity point of view, I think setting up a Windows machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards.
You can install Qt on the installed Windows, copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
Nothing stops you from developing on Linux. You can do the entire development on Linux and just test the code on the prepared Windows by compiling and running. Sending the code to the Windows environment is simple by using git. The development process can be like :
Make a repository of your application, clone the repository both on Linux and Windows
Do the Major development on Linux and push
Pull on Windows from time to time, compile, test and make minor fixes and then push