[Issue 19760] Windows 10 -m64 completely broken, can't compile/run hello world

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19760

--- Comment #7 from Jonathan Marler <johnnymarler at gmail.com> ---
> 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.

--