// -----------------------------------
module test;

import core.stdc.stdio;

extern (C) int main()
{
    printf("hello world\n");
    return 0;
}
// -----------------------------------


compiled with dmd v2.077.0, using the -betterC option, I get:

.. on windows ..
23k executable if 32bit (i.e. -m32 )
112k executable if 64bit (i.e. -m64 )

.. on freebsd ..
5.6k executable if 32bit (i.e. -m32 )
7.5k executable if 64bit (i.e. -m64 )

This is not meant to be an anti-windows thing...so let me stop those responses right here.

I am genuinely interested in understanding why the 'order of magnitude' increase for the 64bit executable on Windows?

On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:
> 23k executable if 32bit (i.e. -m32 )

It is the statically linked C library. Note that if you remove the call to printf, the size is slashed in half.

Windows traditionally didn't do a system-wide C lib, but rather the various compiler vendors would do their own. To keep this from being a big pain for the end user, static linking can be employed as it apparently is with Digital Mars.

> 112k executable if 64bit (i.e. -m64 )

I'm not 100% sure this is the same, but I suspect it probably is.

> .. on freebsd ..
> 5.6k executable if 32bit (i.e. -m32 )

If you ldd that, you'll see it dynamically links the C library. The downside of this is there's less binary compatibility across major versions; you are liable to need to recompile from source to deal with different libc versions on the system, whereas the Windows builds are more likely to just work.

On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe wrote:
>
> It is the statically linked C library. Note that if you remove the call to printf, the size is slashed in half.
>
> Windows traditionally didn't do a system-wide C lib, but rather the various compiler vendors would do their own. To keep this from being a big pain for the end user, static linking can be employed as it apparently is with Digital Mars.
>

Thanks Adam. I understand better now.

On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:
> // -----------------------------------
> module test;
>
> import core.stdc.stdio;
>
> extern (C) int main()
> {
>     printf("hello world\n");
>     return 0;
> }
> // -----------------------------------
>
>
> compiled with dmd v2.077.0, using the -betterC option, I get:
>
> .. on windows ..
> 23k executable if 32bit (i.e. -m32 )
> 112k executable if 64bit (i.e. -m64 )
>
> .. on freebsd ..
> 5.6k executable if 32bit (i.e. -m32 )
> 7.5k executable if 64bit (i.e. -m64 )
>
> This is not meant to be an anti-windows thing...so let me stop those responses right here.
>
> I am genuinely interested in understanding why the 'order of magnitude' increase for the 64bit executable on Windows?

If you're worried about executable size, you're probably better off using ldc on non-Windows platforms, because David made ldc work with the linker's --gc-sections.  I don't think that work was ever done for dmd, which is why ldc invokes --gc-sections by default for non-MSVC targets but dmd doesn't.

On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe wrote:
> On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:
>> 23k executable if 32bit (i.e. -m32 )
>
> It is the statically linked C library. Note that if you remove the call to printf, the size is slashed in half.
>
> Windows traditionally didn't do a system-wide C lib, but rather the various compiler vendors would do their own. To keep this from being a big pain for the end user, static linking can be employed as it apparently is with Digital Mars.
>
>> 112k executable if 64bit (i.e. -m64 )
>
> I'm not 100% sure this is the same, but I suspect it probably is.
>
>> .. on freebsd ..
>> 5.6k executable if 32bit (i.e. -m32 )
>
> If you ldd that, you'll see it dynamically links the C library. The downside of this is there's less binary compatibility across major versions; you are liable to need to recompile from source to deal with different libc versions on the system, whereas the Windows builds are more likely to just work.

There is system-wide C library. It is named msvc.dll.
TCC uses it producing very small executables.

On Friday, 17 November 2017 at 18:53:57 UTC, Temtaime wrote:
> On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe wrote:
>> [...]
>
> There is system-wide C library. It is named msvc.dll.
> TCC uses it producing very small executables.

https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273