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

--- Comment #1 from Jonathan Marler <johnnymarler@gmail.com> ---
I manually fixed the issue on my laptop by reading this thread:

https://www.faqforge.com/windows/fix-the-program-cant-start-because-msvcr100-dll-is-missing-from-your-computer-error-on-windows/

It had me download and install this:

https://www.microsoft.com/en-us/download/details.aspx?id=14632


So...the problem is that the DMD installation includes:

 dmd2\windows\lib64\mingw\msvcrt100.lib


However, the msvcrt100.dll isn't necessarilly installed on the host system. So...dmd and/or lld-link should not be linking against ".lib" files when their ".dll" counterparts are not installed on the system.

DMD should not be providing msvcrt100.lib to lld-link unless the dll is installed.  The correct full solution may involve changes to both dmd and lld-link (LLVM's linker).

--

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

Jonathan Marler <johnnymarler@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |critical

--

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

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #2 from Basile-z <b2.temp@gmx.com> ---
I don't think this is an issue, at least certainly not critical. The error message is clear and once you have setup the right dynamic library the "problem" goes away.

> However, the msvcrt100.dll isn't necessarilly installed on the host system.  So...dmd and/or lld-link should not be linking against ".lib" files when their ".dll" counterparts are not installed on the system.

But the reasoning is not good. the system where is linked the program is not necessarily the one that will run the program.


And most importantly : you can definitely compile the program.

--

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

--- Comment #3 from Jonathan Marler <johnnymarler@gmail.com> ---
I have to respectfully disagree with you on the severity of this issue.

This issue means that out of the box, any 64-bit executable compiled by dmd is broken. To run D any D program, the user now has to install this extra package and the only way for the end user to fix it is to Google this missing dll issue and figure out they need to download an extra package from microsoft.

This issue affects all 64-bit programs compiled by dmd and only manifests at "load time". In my mind this is the epitome of critical issues.

Because this library is not installed by default on windows machines, dmd should not be forcing every executable to have this load-time dependency. It should be compiling against a static version of the library by default, and allow the option to link against the dynamic one. Then the developer can choose when to depend on this extra package, and by doing so can protect their end user by checking that this dependency exists when their software is installed.

--

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

kinke@gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #4 from kinke@gmx.net ---
> It should be compiling against a static version of the library by default

Well, I wish it was that simple, but nope, Microsoft does not permit a 3rd party to ship with their static libs. So both DMD's and LDC's libraries are import libraries for their DLLs and based themselves on the MinGW definitions. [DMD's -m32 on Windows uses the DigitalMars C runtime, so that's different.]

--

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

--- Comment #5 from Jonathan Marler <johnnymarler@gmail.com> ---
Actually it appears Microsoft expects software installers to install their own msvcrt*.dlls (see wiki https://en.m.wikipedia.org/wiki/Microsoft_Windows_library_files)

However that doesn't address the issue. Unless the dll is installed by default on all windows systems (i.e. kernel32.dll), dmd should not be forcing a runtime dependency on it.

--

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

--- Comment #6 from kinke@gmx.net ---
> Unless the dll is installed by default on all windows systems (i.e. kernel32.dll), dmd should not be forcing a runtime dependency on it.

That's a Windows DLL, not to be confused with their C(++) runtime. 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).

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.

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

--

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

--- Comment #7 from Jonathan Marler <johnnymarler@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.

--

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

Seb <greeenify@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greeenify@gmail.com

--

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

--- Comment #8 from kinke@gmx.net ---
> It looks like msvcrt.dll (a different version) is always installed

If it is indeed preinstalled, that's the version from 2002-2003 IIRC. E.g., missing a whole lot of C99 math functions (but maybe not much more than the 2010 runtime).

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

You don't need full-blown Visual Studio (let alone the ancient 2010 one), you
need the runtime redistributable of the matching version; for DMD v10 (VS
2010), for LDC v14 (VS 2015).
But what I meant was that anyone compiling a C++ program with Visual Studio's
default settings will also yield a binary depending on the runtime DLLs, just
like DMD. That's of course no problem for the dev himself, but if he is to
redistribute that program.

> To solve this, we need to remove the dependency on msvcr100.dll, and switch to using a static library by default.

Feel free not to trust me, but I had a look at their license, as shipping with static libs would have made the lives of some people around here much easier. Or are you suggesting to port the DigitalMars C runtime to 64-bits? Note that the MinGW runtime is no alternative, it is itself based on the Microsoft DLLs (yep, the MSVC ones, not just the Windows ones).

A practical solution (well, the only really I can think of) would be checking the availability of those DLLs in the installer.

--