https://issues.dlang.org/show_bug.cgi?id=19760
--- Comment #7 from Jonathan Marler <[email protected]> --- > That's a Windows DLL, not to be confused with their C(++) runtime. Yes, not sure what your point is though. I was saying that DMD shouldn't add runtime dependencies that are not installed on all windows machines. msvcr100.dll is not installed on all machines. It is installed with Visual Studio or by the user manually downloading and installing a standalone version. > I don't know if there's any MSVC runtime preinstalled on Windows, and if so, > which version(s) (depending on the Windows versions). I do know that the > 2015+ runtime is required to cover druntime properly (C99 additions + some > relevant fixes). Been reading about this and it looks like different compilers for different languages also run into this problem. https://gitlab.haskell.org/ghc/ghc/issues/14537 https://github.com/rust-lang/rfcs/issues/2355 It looks like there are different approaches being taken. > It's the same old story, nobody cares that one needs gcc/clang + binutils on > Posix (for linking *and* the libs), but if a bunch of (easily > redistributable) DLLs are required for running generated programs on Windows > due to the restrictive MS license preventing to simply ship with their static > libs, people complain - no offence intended, just an observation. If I compiled a "hello world" program on one linux machine and it wouldn't run on another linux machine without installing extra software that doesn't come out of the box, then I would certainly have a problem with that. That's what we're seeing here in the windows 10 case. If msvcr100.dll was installed on all machines by default then this wouldn't be an issue, but it isn't. It looks like msvcrt.dll (a different version) is always installed, however, Microsoft doesn't make any guarantees as to it's API. So you're taking a risk either way. > Also note that Visual Studio defaults to /MD (dynamic runtime, i.e., these > DLLs). So generated binaries also depend on those DLLs (but newer ones, vc100 > is VS 2010). Like I said in the issue, the machine this occurred on was one that didn't have visual studio installed. It's using the LLVM linker. If you installed the right version of visual studio then you would't run into this issue because it would have installed msvcr100.dll. However, requiring everyone to install visual studio to run programs compiled with "dmd -m64" is not a solution. In the end, the situation is that anyone running windows 10 who hasn't installed visual studio, will run into this error if they compile 64-bit code with dmd. Having a new user download dmd, compile their program and find out they can't run it is a very bad first impression. To solve this, we need to remove the dependency on msvcr100.dll, and switch to using a static library by default. If a program wants to use msvcr100.dll, they can explicitly configure that and make sure to include that dll in their software installer. --
