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

--- Comment #19 from Jonathan Marler <johnnymarler@gmail.com> ---

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

You're straw manning.  We're not talking about dropping support for msvcrt.dll, we're talking about making the default a static library. The developer can still opt-in to link against msvcrXX.dll, which they would when their software is going to be deployed with an installer or if they need to interoperate with C++ binaries. And by the way, DMD is currently only compatible with C++ programs that link against msvcr100.dll, a small subset of the versions of msvcrXX.dll.  The fact that DMD binaries on windows are only compatible with a small subset of C++ binaries is a fact that should not be hidden from the developer.  By making it "opt-in" rather than defaulting to one specific-version, you're making it easier for developers because now they know what their binaries are compatible with.

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

The main point I've gotten from you is that you think it's ok for simple programs compiled with DMD to not work on other's computers by default.  Right now this is a fundamental disagreement between us that makes all your other points moot.

--

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

--- Comment #20 from Jonathan Marler <johnnymarler@gmail.com> ---
Another idea to mitigate this problem.

Having a runtime dependency on a dll that is not intalled on Windows machines by default could be OK if we could fail with a message prompting user to install the Microsoft C++ Redistributable package.

This could be done by loading the msvcr100.dll dynamically inside druntime rather than having the windows loader do it.  This would also give us the ability to choose between multiple versions if we wanted to support that.  Then in the case where it can't find the DLL, we could put up an error message or error window a message like:

  "This binary requires the Microsoft Visual C++ 2010 Redistributable package.
Please install it to continue."

--

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

--- Comment #21 from kinke@gmx.net ---
(In reply to Jonathan Marler from comment #19)
> The main point I've gotten from you is that you think it's ok for simple programs compiled with DMD to not work on other's computers by default.

Yep, totally my point, besides that being apparently no big deal (let alone
critical issue rendering a compiler 'totally broken') for the comparatively
huge Visual C++, Rust and MinGW user base. And with an absolutely trivial
solution - just install Visual Studio and use the static libs (I think that's
the default setting for DMD too, for LDC it definitely is), then your users
won't need the redistributable.
And that seems to be the crux - some Windows guys seem totally opposed to the
idea of having to install the 'official system toolchain' for professional
development, while having to install Xcode on Mac (also required for linking in
general, not just to have the ability of linking the C runtime statically) is
somehow far less considered a PITA.

> This could be done by loading the msvcr100.dll dynamically inside druntime

That'd be too late; druntime's _d_run_main (IIRC) is called from C main
(emitted by the compiler), which is called by the C runtime, as that's where
the actual entry point is.
I wish Microsoft had added something similar as convenience ages ago - if the
binary requires one of their runtime DLLs, offer the option to download &
install it automatically for them, but they apparently don't find it that
critical or rather shift the burden to the software packagers.

--

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

brocolis <brocolis@eml.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brocolis@eml.cc

--- Comment #22 from brocolis <brocolis@eml.cc> ---
I think this is a doc issue. A possible 'fix' in https://dlang.org/dmd-windows.html:

"In order to run programs built with -m64 the end users must first install <link to>MS DLLs</link> in their computers"

The developers should then warn their users whenever they want.

--

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

--- Comment #23 from Rainer Schuetze <r.sagitario@gmx.de> ---
>Then in the case where it can't find the DLL, we could put up an error
> message or error window a message like:

>  "This binary requires the Microsoft Visual C++ 2010 Redistributable
> package.  Please install it to continue."

This is possible with delayed loaded DLLs. An error could be issued at startup
as in
https://docs.microsoft.com/en-us/cpp/build/reference/loading-all-imports-for-a-delay-loaded-dll?view=vs-2017

The downside is that the necessary lib implementing this functionality (delayimp.lib) comes with VC only, so you can also just use the static libraries to begin with.

> I think this is a doc issue.

I agree, lets improve the documentation and move on.

--

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

Jonathan Marler <johnnymarler@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Windows 10 -m64 completely  |Windows 10 -m64
                   |broken, can't compile/run   |undocumented dependency on
                   |hello world                 |MSVC ++ Redistributable
                   |                            |when linking with LLD

--- Comment #24 from Jonathan Marler <johnnymarler@gmail.com> ---
>> The main point I've gotten from you is that you think it's ok for simple programs compiled with DMD to not work on other's computers by default.

> Yep, totally my point, besides that being apparently no big deal (let alone critical issue rendering a compiler 'totally broken') for the comparatively huge Visual C++, Rust and MinGW user base. And with an absolutely trivial solution - just install Visual Studio and use the static libs (I think that's the default setting for DMD too, for LDC it definitely is), then your users won't need the redistributable.
> And that seems to be the crux - some Windows guys seem totally opposed to the idea of having to install the 'official system toolchain' for professional development, while having to install Xcode on Mac (also required for linking in general, not just to have the ability of linking the C runtime statically) is somehow far less considered a PITA.

Ah I see I've misunderstood. I wasn't aware that you could statically link using the MSVC tools.  This is a much better state, at least there's a path to be able to build executables that will run on any reasonably recent windows system.  In that case updating the dmd windows documentation about using the LLD linker is good enough for me.  Still not ideal, but acceptable.

>> This could be done by loading the msvcr100.dll dynamically inside druntime

>That'd be too late; druntime's _d_run_main (IIRC) is called from C main (emitted by the compiler), which is called by the C runtime, as that's where the actual entry point is.

Gotcha.  So if we wanted to do that we would also need to also emit the entry point or link against a static library with an entry point implementation.

--

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

--- Comment #25 from anonymous4 <dfj1esp02@sneakemail.com> ---
(In reply to brocolis from comment #22)
> "In order to run programs built with -m64 the end users must first install <link to>MS DLLs</link> in their computers"
Normally the dll is just placed in the same folder with the executable, applications on windows are self contained this way.

--

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

--- Comment #26 from Rainer Schuetze <r.sagitario@gmx.de> ---
Given that the MS-DLLs are redistributable, we could also just add them to the dmd installation. You can then copy them with your built executable to another computer without having to go through full installation of the VC distributables.

Using the VC2010 DLLs has the advantage that later versions don't make it that easy because they require proper manifests.

--

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

--- Comment #27 from kinke@gmx.net ---
(In reply to Jonathan Marler from comment #24)
> In that case updating the dmd windows documentation about using the LLD linker is good enough for me.

Wrt. docs, they should mention that it is specific to -m32mscoff/-m64 *and* the shipped-with MinGW libs, i.e., only if no Visual Studio is installed. LLD as linker is usable just fine with the MS libs (and in fact way faster than the MS linker - see the -link-internally speedup in https://github.com/ldc-developers/ldc/issues/2964#issuecomment-454533092).

(In reply to Rainer Schuetze from comment #26)
> Using the VC2010 DLLs has the advantage that later versions don't make it that easy because they require proper manifests.

But I guess the UCRT is more likely already installed nowadays. I don't know
whether DMD requires vcruntime etc. on top like LDC.
The question of default MSVC runtime version for DMD is also relevant for
https://github.com/dlang/installer/pull/346.

--

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

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

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

--