3

I am trying to simply deploy an OpenGL, C++ application from one computer to another. The app was written using Visual Studio 2017 Community. The first computer has VS installed, the second does not.

The computers have Intel Core i7-8550U CPU and Intel Atom x5-Z8350 CPU, respectively. Both are running Windows 10 Home.

The VS project started as an empty project to which I added everything.

I have copied the release, x64 application .exe file and the one .dll file necessary to the project development to a single directory on the second computer.

Microsoft instructions for local deployment say “Local deployment, in which you copy particular Visual C++ DLLs from your Visual Studio installation—typically in \Program Files (x86)\Microsoft Visual Studio version\VC\Redist\platform\library\—and install them on target computers in the same folder as the application executable. You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share.”

Nothing I can see or find to set in VS tells me what .dll files are being used by the application I developed and run on the first computer. There is a VS output window that shows a number of .dll files, but those are in c:\windows\system32.

From the reference in the Microsoft instructions regarding the MSVC DLLs in \Program Files (x86)\Microsoft Visual Studio version\VC\Redist\platform\library\, I looked in ..\VC\Redist\MSVC\14.16.27012\x64 on the first computer and found these folders:

enter image description here

I have copied the DLLs from the .CRT directory and the .MFC directory to the second computer to no avail.

When I try to run the application on the second computer it displays the message “Failed to create GLFW window”, which is in the code I wrote as shown here:

enter image description here

It would seem that there must be a straightforward way to do this. I have seen reference to an old Microsoft application (I think), depends.exe, which provides the a list of the DLLs required, but it is no longer deployed with Windows systems.

user34299
  • 377
  • 2
  • 11

2 Answers2

1

You can use DUMPBIN /DEPENDENTS EXENAME to get a list of bound DLLs. Mind you this only lists DLLs with import table entries, if you're instantiating COM objects this won't help at all.

My guess is you're probably missing the opengl driver/dll on the target system.

ed: actually I'm going to narrow that down to missing the driver, since if you were missing the DLL you'd have gotten an an error on load. The fact you're able to call the function means you bound to it, but that you're only getting failures when it tries to call the driver. Try calling something benign that queries for driver or device info, like a version or string. If that fails you know the driver is missing.

eric
  • 88
  • 6
  • eric, Thanks. I was not aware of DUMPBIN.EXE. It does show the DLLs needed by my .exe file. I did **not** have to keep any but the one required by my code for the .exe file to now function on the second computer. That said, I did find that the second computer has an older version of the Microsoft Visual C++ Redistributable for both x86 and x64 installed, and found at least one of the DLLs specified by DUMPBIN in `C:\Windows\System32`. Microsoft sure seems to make this harder than need be. – user34299 Oct 05 '19 at 22:37
1

missing DLL or RTL

causes crash or even no error but just instant closing your app (that is what missing or miss-matching MSVCPP RTL is doing or was at some point).

As the RTL libs are changing all the time (IIRC once in a year) there are a lot of versions already so good luck using MSVCPP apps on fresh OS computers. In order to use some app you usually need to find out which version of RTL it needs which they usually do not report so you will end up with installing all of them you get hands on ...

There is a way around this problem just enable your compiler/linker to link all the stuff it needs directly into exe file instead of using RTL DLLs. However I do not code in MSVCPP and from what I heard MS removed this option from their environment (other compilers I use still have it)

Your error message indicates your App run as should and is not missing anything.

The problem is on GL side. Windows 10 is usually forcing wrong drivers (and not just for gfx cards). The goto case is enforcing (most likely intentionaly) buggy MS drivers (where GL is bugged and DX more or less works) instead of vendor provided. To remedy this (check the driver manufactor and if not what it should be) download&install correct driver from your gfx Vendor site Do not use Windows Driver service for gfx cards !!!

Community
  • 1
  • 1
Spektre
  • 49,595
  • 11
  • 110
  • 380
  • 1
    Spektre, Thanks. Your last comment, viz., “The problem is on GL side”, put me onto the answer. The second computer’s video driver is up to date, though the latest video driver from Intel, not Microsoft, is dated July, 2016. My app is running OpenGL 4.5, which was released in August, 2014. Nonetheless, it appears that the second computer’s video driver does not accommodate that version. As a test, I reduced the OpenGL version in the code to 3.3 and the application now works on the second computer. ... – user34299 Oct 05 '19 at 14:54
  • ... I am going to experiment both with the OpenGL version number and the DLLs (eliminating one at a time) to see where it breaks. – user34299 Oct 05 '19 at 14:54
  • @user34299 you can even call old 1.0 context and read the GL version using [glGetString](https://stackoverflow.com/a/35826975/2521214) ... then open compatible GL version or throw relevant error message. Did not see any GLFW hints in your code so I did not realized you are enforcing GL context version ... – Spektre Oct 05 '19 at 16:17
  • I did use the `glGetString()` function to see the OpenGL version being used and found that the second computer will accommodate up to v4.4. All that effort and I was using v4.5! – user34299 Oct 05 '19 at 22:32
  • @user34299 hmm its sad but my experience is that Intel does not update drivers for older gfx cards / APUs ... maybe you can find 3th party driver like omega or try emulation like nVidia's [nvemulate.exe](https://developer.nvidia.com/nvemulate) orgive up hope and port to older GL ... – Spektre Oct 06 '19 at 08:09