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

--- Comment #9 from anonymous4 <dfj1esp02@sneakemail.com> ---
(In reply to kinke from comment #8)
> Or are you suggesting to port the DigitalMars C runtime to 64-bits?

Or musl :)

--

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

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

I'm not sure what the right solution is yet.  It looks like different compilers are using different approaches.  I think I've read that LIBCMT is a static version of MSVCRT.dll, but I can't confirm, and even if it is, there may be licensing issues like you point out.  Maybe we could use msvcrt.dll (the unversioned one) for stuff that we're sure will never change and supplement it with another static library to fill in the holes.  Maybe we chose another implementation that we can ship a static library of (DMC/MUSL).  I'm not sure what the right solution is here.


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

This only works if you are creating an executable that you are shipping with an installer.

--

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

--- Comment #11 from kinke@gmx.net ---
> I think I've read that LIBCMT is a static version of MSVCRT.dll, but I can't confirm

I can; also see the -mscrtlib cmdline switch.

> Maybe we chose another implementation that we can ship a static library of (DMC/MUSL).

Musl on Windows? I just mentioned alternative runtimes for completeness; even if somebody wanted to go through all that trouble, incl. adapting druntime, there'd be still one big drawback: if you want to mix D and C(++) code and use the same heap etc., you have to make sure both parts use the same runtime. So any non-MSVC runtime on Windows would be an exotic and as such bad choice, just like the DigitalMars C runtime and Optlink are (being phased out with -m32mscoff/-m64 by default).

> This only works if you are creating an executable that you are shipping with an installer.

I was talking about the DMD installer itself - checking if the libs or a Visual C++ (dev) installation is found, just so that the dev himself can run generated binaries without surprises.

When redistributing you own Windows programs, you have two options - either bundle your software with the MS DLLs, like most C++ software does, or install Visual Studio or the Build Tools and link against the static runtime to prevent those runtime dependencies. The latter is clearly not an option for hobbyist devs; you surely remember all the threads of Windows users complaining about the Visual C++ dependency for linking.

--

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

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de

--- Comment #12 from Rainer Schuetze <r.sagitario@gmx.de> ---
I'm with kinke on this. We must not distribute the static MS libs, and the dynamic libs need to be installed (usually through the distributable installers).

Didn't the installer warn you that no VC runtime was found and even proposed to install the VC2010 redistributables for you?

--

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

--- Comment #13 from Jonathan Marler <johnnymarler@gmail.com> ---
> Didn't the installer warn you that no VC runtime was found and even proposed to install the VC2010 redistributables for you?

I'm talking about the the case where you build hello world on one windows machine, then run it on another.  Are you saying that it's ok that you can't run simple binaries on other machines without putting them inside an installer and including the MSVC C++ Redistribuable runtime in your installer? And if that's the case, I haven't seen any documentation saying that all executables compiled by DMD need to be packaged with an installer and need to come with the Microsoft redistributable runtime.

--

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

--- Comment #14 from kinke@gmx.net ---
> Are you saying that it's ok that you can't run simple binaries on other machines without putting them inside an installer and including the MSVC C++ Redistribuable runtime in your installer?

It sadly can't be avoided (and the only one to blame being Microsoft) for as
long as druntime and Phobos depend on a C runtime, unless the dev installs
Visual Studio or the Build Tools. Alternatively, just mentioning the MSVC
runtime as prerequisite on the web or in some README might be enough in some
cases.
C# apps come with a .NET framework dependency, Java with JRE, and
C(++)/D/Rust/... usually with the MSVC runtime
(https://stackoverflow.com/questions/52153676/what-is-the-requirements-for-running-a-rust-compiled-program-on-another-windows).
My Windows system with a moderate number of installed programs currently has 15
installed MSVC runtime versions (2005-2017, incl. different subversions).

For LDC, I wrote this in an attempt to clarify that dependency: https://github.com/ldc-developers/ldc/blob/8f81d0797b7cb4bc44aeb6565366a8d31945b8c4/packaging/README.txt#L10-L18

--

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

--- Comment #15 from anonymous4 <dfj1esp02@sneakemail.com> ---
(In reply to kinke from comment #11)
> Musl on Windows? I just mentioned alternative runtimes for completeness; even if somebody wanted to go through all that trouble, incl. adapting druntime, there'd be still one big drawback: if you want to mix D and C(++) code and use the same heap etc., you have to make sure both parts use the same runtime.

Technically there's Universal CRT.
If the problem is only with math functions, I suppose those can be separately
taken from musl, should be standalone.
If you use C/C++ code, you either compiled it and then have visual studio, or
not and you again have the problem of the same runtime.

--

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

--- Comment #16 from kinke@gmx.net ---
(In reply to anonymous4 from comment #15)
> (In reply to kinke from comment #11)
> > Musl on Windows? I just mentioned alternative runtimes for completeness; even if somebody wanted to go through all that trouble, incl. adapting druntime, there'd be still one big drawback: if you want to mix D and C(++) code and use the same heap etc., you have to make sure both parts use the same runtime.
> 
> Technically there's Universal CRT.
> If the problem is only with math functions, I suppose those can be
> separately taken from musl, should be standalone.

Please just trust my and Rainer's judgement on this, we have been deeply
involved with all this.
Universal CRT is one part of the newer MS runtimes since 2015 (and so used when
linking against recent MS msvcrt.lib or libcmt.lib). It doesn't solve anything
for us (as it isn't preinstalled on older Windows; not sure if it's
preinstalled on Win10), except making the runtime installation somewhat harder
(requires a reboot IIRC).
The problem isn't only with math functions (e.g., no hex float parsing, buggy
snprintf in older MS runtimes...). And in contrast to all/most? other x86(_64)
runtimes, Microsoft chose 64-bit double precision for `long double`, so printf
etc. from other runtimes won't work out of the box. And for LDC, we use the
Visual C++ EH personality function (which for example is not part of the
Universal CRT).

> If you use C/C++ code, you either compiled it and then have visual studio, or not and you again have the problem of the same runtime.

I'm not sure I get what you mean. But the MS runtime is not just used by the MS
compiler, but also by MinGW-gcc and the Intel compiler, and those are, I guess,
at least a thousand times more popular than all the other C(++) compilers on
Windows combined.
If you meant that you need a runtime *version* compatible with the C(++) code,
then yes, you either need an older Visual Studio compatible with that version,
or you might get away with selecting one of the many runtime versions LDC ships
with (all dynamic ones from VS 2002-2015) via `-mscrtlib`.

--

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

--- Comment #17 from anonymous4 <dfj1esp02@sneakemail.com> ---
(In reply to kinke from comment #16)
> Universal CRT is one part of the newer MS runtimes since 2015 (and so used when linking against recent MS msvcrt.lib or libcmt.lib). It doesn't solve anything for us (as it isn't preinstalled on older Windows; not sure if it's preinstalled on Win10)
It's delivered as system update to everything post XP.

> The problem isn't only with math functions (e.g., no hex float parsing, buggy snprintf in older MS runtimes...).
These two must be standalone too. UCRT has standard snprintf, then there's a problem if some code actually relies on the buggy one.

> And in contrast to all/most? other
> x86(_64) runtimes, Microsoft chose 64-bit double precision for `long
> double`, so printf etc. from other runtimes won't work out of the box.
AFAIK, musl doesn't predefine fp precision and relies on declared precision definitions.

Options:
1. keep using 100 or ms static lib
2. full static musl with ported malloc, stdio, personality, startup etc.
3. use ucrt and ported personality

--

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

--- Comment #18 from kinke@gmx.net ---
(In reply to anonymous4 from comment #17)
> 2. full static musl with ported malloc, stdio, personality, startup etc.

Won't work when mixing with C(++) code and you want a shared C runtime. Which
shouldn't be an extremely exotic use case (D plugin as DLL).

> 3. use ucrt and ported personality

Won't work if you want to catch D exceptions from C++, something that's in principle doable with LDC for more than 3 years already (https://github.com/ldc-developers/dmd-testsuite/pull/15).

Anyway, I'm out of this discussion, I think I made my points.

--