Emulator

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

https://github.com/dolphin-emu/dolphin/pull/2762#issuecomment-137444102

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.

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...

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...

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

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.

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

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.

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?

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.