Hi,

I'm new to D and trying my hands on a few simple things. Being able to build a Windows DLL with betterC enabled is of particular interest to me, as I'd need it for a project that I'd like to do in D.

I'm trying to follow some examples, such as this and this, and they compile without -betterC, but fail with link errors when using the switch.

example DLL, or see 2nd link for one without the mixin

//WindowsApp1.d
module WindowsApp1;
import core.sys.windows.windows;
import core.sys.windows.dll;

export extern (C) void main()
{
    import core.stdc.stdio : printf;

    printf("Hello betterC\n");
}
mixin SimpleDllMain;

then

dmd -m64 -shared -betterC WindowsApp1.d

yields error:

error LNK2019: unresolved external symbol _D4core3sys7windows3dll18dll_process_attachFPvbZb referenced in function DllMain
error LNK2019: unresolved external symbol _D4core3sys7windows3dll18dll_process_detachFPvbZv referenced in function DllMain
error LNK2019: unresolved external symbol _D4core3sys7windows3dll17dll_thread_attachFbbZb referenced in function DllMain
error LNK2019: unresolved external symbol _D4core3sys7windows3dll17dll_thread_detachFbbZb referenced in function DllMain

I'm not a complete beginner to programming, so I'm guessing the linker is missing a library, but as I'm not familiar with D yet, and these are fairly basic examples that I expected to run without a hitch, I'm a bit confused as to what I should be doing. Shouldn't the system modules provide the link targets themselves? Should I add a parameter to include a windows system library?

BtW, I've tried compiling from the command line and from Visual Studio using the visuald extension - I'm assuming the extension makes sure the environment variables are set correctly. When using dmd from the command line, I also tried invoking dmd2vars64.bat and vcvars64.bat before running dmd.exe to ensure the variables are set. In any case, the build process is successful without betterC, so I'm assuming the path/variables are set correctly.

On Saturday, 4 February 2023 at 16:51:36 UTC, Richard (Rikki) Andrew Cattermole wrote:

I'm not sure I understand every bit of it yet, but this looks helpful, thank you.

I was able to compile this (based on dllmain.d linked by you) with both DMD and LDC:

module WindowsApp1;

version (Windows)
{
    version (D_BetterC)
    {
        import core.sys.windows.windef : HINSTANCE, BOOL, DWORD, LPVOID;

        extern (Windows) BOOL DllMain(HINSTANCE hInstance, DWORD ulReason, LPVOID reserved)
        {
            return true;
        }
    }
    else
    {
        import core.sys.windows.dll;

        mixin SimpleDllMain;
    }
}

export extern (C) void foo()
{
    import core.stdc.stdio : printf;

    printf("Hello betterC\n");
}

What's the reason to prefer LDC over DMD?

On Saturday, 4 February 2023 at 18:27:34 UTC, Adam D Ruppe wrote:

I do take your word for it, but now I have to re-evaluate my expectations towards D and perhaps use it for another project. I've got most of my project working in C already, but I was hoping to add some safety and better readability/managability by using some of the convenient features D offers over C. And, of course, learn D in the process. Also, your words give me the impression that I cannot trust the documentation; which isn't a great start into the learning process.

It can be evidence of something broken in D as you say (simplified) or of my lack of experience with D - a simple missing include, badly configured PATH, or lack of understanding on my part what SimpleDllMain does.

On Saturday, 4 February 2023 at 18:29:41 UTC, Tamas wrote:

Anyone that cares about performance will use LDC rather than DMD. It's hard to imagine a case where someone would want betterC to avoid the GC, but they wouldn't want to use LDC. When I started using D many years ago, LDC was behind DMD, so you needed to use DMD to have a current compiler. That's no longer true. The only reason I use DMD today is the faster compilation speed when I'm doing a lot of write-compile-debug iterations.

On Saturday, 4 February 2023 at 18:40:51 UTC, Tamas wrote:

I'm not sure what Adam's getting at when he says "hopelessly broken" but it's basically a subset of D. The main reason I've seen people wanting betterC is to avoid the GC. Well, you don't need betterC for that, you use @nogc and then you don't have to worry about the GC.

I think the point is that it works without the betterC switch, so it's not your lack of experience that's the problem, it's the functionality that you lose when you use that switch.