Emulator Issues #8917

Missing MVC++ 2015 DLLs, 2013 still packaged with Development version

Added by psilupan about 7 years ago. Updated over 6 years ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


Since the move to VS2015, the DLLs for 2013 are still being packaged with the Windows development builds.

This will cause a missing DLL error for the "140" .DLLs.


#1 Updated by delroth about 7 years ago

  • Assignee set to Anonymous
  • Status changed from New to Accepted

#2 Updated by Anonymous about 7 years ago

  • Assignee changed from Anonymous to parlane

People who are using the builds must install VCRedist.
I already removed the v120 dlls from the project, so if people are seeing them in the buildbot builds it's just because there is old cruft left in the build directory.

#3 Updated by delroth about 7 years ago

Any reason why we shouldn't bundle the DLLs? They're called redistributable for a reason.

#4 Updated by Anonymous about 7 years ago

It's mainly unattractive because of the sheer maintenance.
The directories which would need to be copied with dolphin:

Directory of c:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x64

08/15/2015  12:32 AM    <DIR>          .
08/15/2015  12:32 AM    <DIR>          ..
06/17/2015  03:09 AM            19,136 api-ms-win-core-console-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-datetime-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-debug-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-errorhandling-l1-1-0.dll
06/17/2015  03:09 AM            22,208 api-ms-win-core-file-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-file-l1-2-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-file-l2-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-handle-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-core-heap-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-interlocked-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-core-libraryloader-l1-1-0.dll
06/17/2015  03:09 AM            21,184 api-ms-win-core-localization-l1-2-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-core-memory-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-namedpipe-l1-1-0.dll
06/17/2015  03:09 AM            19,648 api-ms-win-core-processenvironment-l1-1-0.dll
06/17/2015  03:09 AM            20,672 api-ms-win-core-processthreads-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-core-processthreads-l1-1-1.dll
06/17/2015  03:09 AM            18,112 api-ms-win-core-profile-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-core-rtlsupport-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-string-l1-1-0.dll
06/17/2015  03:09 AM            20,672 api-ms-win-core-synch-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-core-synch-l1-2-0.dll
06/17/2015  03:09 AM            19,648 api-ms-win-core-sysinfo-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-timezone-l1-1-0.dll
06/17/2015  03:09 AM            18,624 api-ms-win-core-util-l1-1-0.dll
06/17/2015  03:09 AM            19,648 api-ms-win-crt-conio-l1-1-0.dll
06/17/2015  03:09 AM            21,184 api-ms-win-crt-convert-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-crt-environment-l1-1-0.dll
06/17/2015  03:09 AM            20,160 api-ms-win-crt-filesystem-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-crt-heap-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-crt-locale-l1-1-0.dll
06/17/2015  03:09 AM            23,744 api-ms-win-crt-math-l1-1-0.dll
06/17/2015  03:09 AM            23,232 api-ms-win-crt-multibyte-l1-1-0.dll
06/17/2015  03:09 AM            44,736 api-ms-win-crt-private-l1-1-0.dll
06/17/2015  03:09 AM            19,648 api-ms-win-crt-process-l1-1-0.dll
06/17/2015  03:09 AM            21,184 api-ms-win-crt-runtime-l1-1-0.dll
06/17/2015  03:09 AM            22,208 api-ms-win-crt-stdio-l1-1-0.dll
06/17/2015  03:09 AM            22,208 api-ms-win-crt-string-l1-1-0.dll
06/17/2015  03:09 AM            20,160 api-ms-win-crt-time-l1-1-0.dll
06/17/2015  03:09 AM            19,136 api-ms-win-crt-utility-l1-1-0.dll
06/17/2015  03:09 AM           971,456 ucrtbase.dll
              41 File(s)      1,787,072 bytes
Directory of c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x64\Microsoft.VC140.CRT

08/15/2015  12:28 AM    <DIR>          .
08/15/2015  12:28 AM    <DIR>          ..
06/25/2015  11:15 PM           332,968 concrt140.dll
06/25/2015  11:15 PM           635,040 msvcp140.dll
06/25/2015  11:15 PM           390,320 vccorlib140.dll
06/25/2015  11:15 PM            88,752 vcruntime140.dll
               4 File(s)      1,447,080 bytes

Besides that, I think the linked posts (by VS team people) make good points as to why these libs should be maintained at a system level instead of a per-app level.

#5 Updated by mbc07 about 7 years ago

Maybe include that in the FAQ too? I see we already make note of this in development builds section of the download page, but I think many people will blindly scroll to the current build and hit download without noticing the note...

#6 Updated by Anonymous almost 7 years ago

  • Status changed from Accepted to Fixed

#7 Updated by tueidj almost 7 years ago

You should at least bundle vcredist_x64.exe, which has always been the method preferred by MS for apps that don't use static runtime linking...

#8 Updated by MayImilae almost 7 years ago

  • Status changed from Fixed to Won't fix

vcredist_x64.exe for VS2015 is 15MB, three times the size of Dolphin's package! That isn't really a good idea to include...

godisgovernment, why did you mark this as fixed? The situation wasn't actually changed, so "Won'tfix" or "Working as intended" is more appropriate.

#9 Updated by MayImilae almost 7 years ago

  • Status changed from Won't fix to Fixed

Matt_P explained it.

Matt_P: [2013] dlls were removed
Matt_P: only part that could be fixed is fixed

#10 Updated by Anonymous almost 7 years ago

tueidj yes, we should do that - but only for real "release" builds (it would just be a step in the installer, etc).

#11 Updated by tueidj almost 7 years ago

So you'd rather distribute a package with missing dependencies, leaving the noobs to download possibly untrustworthy executables or mess up their systems by attempting to replace DLLs one-by-one.

Use a bootstrap package if it's that much of an issue. Otherwise you accepted the move the VS2015, so accept the size increase that comes with it. Doing neither is just laziness that shows you don't really give a shit about your users.

#12 Updated by Anonymous almost 7 years ago

We point people to the correct source, and that is all we need to do for now.

#13 Updated by delroth almost 7 years ago

We definitely don't give a shit about people who download development builds and can't read simple instructions. Stable versions built with MSVC2015 will include what's necessary to get the runtime installed.

#14 Updated by mbc07 over 6 years ago

Today I needed to run Dolphin on a Windows 7 install where I didn't have elevated access to install the redistributables, so I copied them from the Windows install on my laptop to the Dolphin folder (yes, I know this can cause issues, etc -- I deleted the copied DLLs after that). The point is Dolphin seems to require only msvcp140.dll and vcruntime140.dll to work (it didn't complain about the api-ms-win-* DLLs like I thought it would), can anyone confim this? If that's the case, maybe we should bundle them in development builds and stick with the VS 2015 installer on stable builds?

#15 Updated by Helios over 6 years ago

I think that would be "fine" for casual usage, but I doubt it's very stable and I imagine updates to either the code or compiler could very well break that.

Also available in: Atom PDF