0

I have an application written in QT. Previously I was using Visual Studio 2012 and Qt 5.3.1 after which I recently upgraded to Visual Studio 2015 and QT 5.6. I would previously provide msvcp110 and msvcr110 as part of the installation (I know that wasn't the best practice but I got away with it).

After upgrading I had to now install VC++ 2015 because of the changes with VS 2015. I don't mind the changes and currently providing redist packages to be installed.

The problem I am facing is that, I do have to provide VC++ 2012 as well and recently running the software in Windows 8.1 Pro, I was asked to provide VC++ 2013 as well (never used VS2013 for compiling). The diagnosis was from dependency walker and google. Not only that, I had to install x86 and x64 of all the 3 versions of VC++ for the software to start (wouldn't even start to be honest).

  1. Why do I need VC++ 2012 and 2013 when I now use only Visual Studio 2015?
  2. How do I get rid of the other redist packages? Is it some code I have written which is dependent? If yes any chance I can find out?
  3. Why do I need to provide both the 32 and 64 bit versions when I compile strictly in the 64 bit compiler?
  4. Any way to diagnose without dependency walker? Can there be some logging when the application refuses to start at all?

Apologies for the long post, but any light here can restore my sanity.

Thanks in advance.

Vivian Lobo
  • 583
  • 10
  • 29
  • Dependency Walker hasn't been updated in **years**. It doesn't understand the Universal CRT at all, and will give false positives as well as false negatives. Don't use it. To get reliable diagnostics, enable the [show loader snaps](https://msdn.microsoft.com/en-us/library/windows/hardware/ff556886.aspx) flag using [GFlags](https://msdn.microsoft.com/en-us/library/windows/hardware/ff549557.aspx). – IInspectable May 18 '16 at 14:43
  • Fair enough, but strangely after I installed VC++ 2013 it sorted the problem. – Vivian Lobo May 18 '16 at 14:44
  • 1
    ***Why do I need VC++ 2012 and 2013 when I now use only Visual Studio 2015?*** Did you rebuild all of your dependent libraries / dlls with Visual Studio 2015 (including Qt)? – drescherjm May 18 '16 at 14:44
  • ***I installed VC++ 2013 it sorted the problem*** I say this will cause UB. It is not generally safe to mix and match different versions of Visual Studio in the same application because of different implementations of the standard library and having more than 1 CRT. – drescherjm May 18 '16 at 14:46
  • I have answered a similar question here: http://stackoverflow.com/a/19860574/487892 – drescherjm May 18 '16 at 14:48
  • 1
    @drescherjm: That depends on the DLL interfaces. It's entirely possible to have DLLs built with multiple runtime versions all load in the same process and work correctly, as long as usage of the runtime is internal to each DLL and the exports are pure "C" style. (Of course, the wrinkle is Qt, since it isn't pure C style) – Ben Voigt May 18 '16 at 14:49
  • Fully agreed. The dlls would have to isolate themselves for this to be safe. – drescherjm May 18 '16 at 14:50
  • Yes, I use only KDSoap and QT and I built KDSoap using VS2015 itself. Downloaded the msvc2015 version of QT from the official site. – Vivian Lobo May 18 '16 at 14:50
  • ***I built KDSoap using VS2015 itself*** I would go back and verify that you used the correct CMake generator when generating the Visual Studio project. If this was the same folder as a previous build I would do a totally clean build by wiping out the build folder and reconfiguring. – drescherjm May 18 '16 at 15:11
  • Thank you for the replies, I am guessing the best thing to do is go back and rebuild using a clean env with VS2015 and then it will be clean of the older redist rubbish. – Vivian Lobo May 18 '16 at 15:13

1 Answers1

2

  1. You are using DLLs linked to the older runtime. You can use Dependency Walker on your development machine to track this down, shouldn't need to install any tools on a customer machine for that.

  2. Migrate all the files shipped with your application to a version built against VC++ 2015.

  3. You didn't provide any details that could reveal the reason.

  4. For DLLs other than the language runtime library, you can use delay-loading and then be able to trap failure to load the library. You can't effectively delay-load msvcr*.dll though. One option would be to create a very thin EXE that uses no support DLL at all (either use pure Win32 API, or statically link the runtime) which does nothing except install an error handler and then load your main program which is now in the form of a DLL. Loading your main program DLL should be done either using delay-load linking or LoadLibrary()+GetProcAddress() -- either one will allow catching errors. This main program DLL would be free to import the runtime DLLs as usual.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720