www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - betterC DLL in Windows

reply Tamas <km212121 gmail.com> writes:
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](https://wiki.dlang.org/Win32_DLLs_in_D) and 
[this](https://tekmoji.com/?post=Calling%20D%20(dlang)%20shared%20libs%20from%20Pyt
on%20on%20Windows), 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
```D
//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.
Feb 04 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
You don't have access to druntime/Phobos stuff at runtime.

SimpleDllMain is for initializing and uninitializing druntime.

See: 
https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/dllmain.d

You want to only use ldc atm. The defaults right now should most likely 
"just work" in dub for a single compile + link step (i.e. only a single 
static library in dll).

If you do it manually, you'll want to add the flag 
``--fvisibility=public`` to export everything.
Feb 04 2023
parent reply Tamas <km212121 gmail.com> writes:
On Saturday, 4 February 2023 at 16:51:36 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 You don't have access to druntime/Phobos stuff at runtime.

 SimpleDllMain is for initializing and uninitializing druntime.

 See: 
 https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/dllmain.d

 You want to only use ldc atm. The defaults right now should 
 most likely "just work" in dub for a single compile + link step 
 (i.e. only a single static library in dll).

 If you do it manually, you'll want to add the flag 
 ``--fvisibility=public`` to export everything.


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:

```D
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?
Feb 04 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/02/2023 7:29 AM, Tamas wrote:

 What's the reason to prefer LDC over DMD?


DMD is currently a write off for DLL support (some things do work, but 
its very easy to hit situations that don't).

I've been looking into this for the past year, implemented some things 
in dub to get it to work, also currently working on the redesign of 
export :)
Feb 04 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 4 February 2023 at 18:29:41 UTC, Tamas wrote:


 What's the reason to prefer LDC over DMD?


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.
Feb 04 2023
parent Tamas <km212121 gmail.com> writes:
On Saturday, 4 February 2023 at 19:44:15 UTC, bachmeier wrote:

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


 What's the reason to prefer LDC over DMD?


 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.


Good to know, thank you. The posts I've seen so far online 
suggesting to start with DMD must've been outdated, then.
Feb 05 2023
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 4 February 2023 at 16:45:31 UTC, Tamas wrote:

 and they compile without `-betterC`, but fail with link errors 
 when using the switch.


then don't use the switch lol

-betterC is barely supported and completely useless so better to 
just not use it.


 export extern (C) void main()
 mixin SimpleDllMain;


No need to ever mix two mains together, the DllMain is the 
required one.


 error LNK2019: unresolved external symbol 
 _D4core3sys7windows3dll18dll_process_attachFPvbZb referenced in 
 function DllMain


This is just betterC breaking the code.
Feb 04 2023
parent reply Tamas <km212121 gmail.com> writes:
Hi, thanks for the feedback. I'm happy to see 2 replies so 
quickly.

On Saturday, 4 February 2023 at 17:26:17 UTC, Adam D Ruppe wrote:

 On Saturday, 4 February 2023 at 16:45:31 UTC, Tamas wrote:

 export extern (C) void main()
 mixin SimpleDllMain;


 No need to ever mix two mains together, the DllMain is the 
 required one.


Indeed, that is an oversight on my part. However, that's just a 
typo I happened to include in my last attempt. I use foo() and 
others, and .def exporting them etc. Tried various things based 
on the examples I linked.



 and they compile without `-betterC`, but fail with link errors 
 when using the switch.


 then don't use the switch lol

 -betterC is barely supported and completely useless so better 
 to just not use it.


Well, as I'm new to D this isn't something I have insight into. 
However, this being and advertised feature of the language, I'm 
surprised to see that you dismiss it so casually. Also, for my 
project, I mostly need interop with C libraries and D would only 
serve as a glue, so I don't really need several features like GC 
etc. `betterC`, at least what I thought it was supposed to be, 
seemed to be a good fit for what I need.


 error LNK2019: unresolved external symbol 
 _D4core3sys7windows3dll18dll_process_attachFPvbZb referenced 
 in function DllMain


 This is just betterC breaking the code.


Perhaps, but this doesn't help me much.
Feb 04 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 4 February 2023 at 18:11:05 UTC, Tamas wrote:

 Well, as I'm new to D this isn't something I have insight into.


Then you'd probably be better off taking my word for it (or even 
trusting your own limited experience where things worked until 
you added the switch) and just not using -betterC switch.

It is hopelessly broken, but thankfully, it also brings zero 
benefit, so simply not using it is a viable path forward.


 I mostly need interop with C libraries and D would only serve 
 as a glue, so I don't really need several features like GC etc.


Just don't call those functions and they won't hurt you, aside 
from adding ~200 KB of size to the dll. On the other hand, the 
-betterC switch is hurting you - as evidenced by your own attempt 
working until you added it.


 Perhaps, but this doesn't help me much.


It is a very easy solution to your problem. It is up to you if 
you want to take it and continue on in productivity or keep 
suffering for no benefit (and you'll find more trouble the 
further you go using the broken, barely supported switch).
Feb 04 2023
parent reply Tamas <km212121 gmail.com> writes:
On Saturday, 4 February 2023 at 18:27:34 UTC, Adam D Ruppe wrote:

 On Saturday, 4 February 2023 at 18:11:05 UTC, Tamas wrote:

 Well, as I'm new to D this isn't something I have insight into.


 Then you'd probably be better off taking my word for it (or 
 even trusting your own limited experience where things worked 
 until you added the switch) and just not using -betterC switch.

 It is hopelessly broken, but thankfully, it also brings zero 
 benefit, so simply not using it is a viable path forward.


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.


 I mostly need interop with C libraries and D would only serve 
 as a glue, so I don't really need several features like GC etc.


 Just don't call those functions and they won't hurt you, aside 
 from adding ~200 KB of size to the dll. On the other hand, the 
 -betterC switch is hurting you - as evidenced by your own 
 attempt working until you added it.


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.
Feb 04 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 4 February 2023 at 18:40:51 UTC, Tamas wrote:


 It is hopelessly broken, but thankfully, it also brings zero 
 benefit, so simply not using it is a viable path forward.


 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.


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 mostly need interop with C libraries and D would only serve 
 as a glue, so I don't really need several features like GC 
 etc.


 Just don't call those functions and they won't hurt you, aside 
 from adding ~200 KB of size to the dll. On the other hand, the 
 -betterC switch is hurting you - as evidenced by your own 
 attempt working until you added it.


 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.


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.
Feb 04 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 4 February 2023 at 19:49:41 UTC, bachmeier wrote:

 I'm not sure what Adam's getting at when he says "hopelessly 
 broken" but it's basically a subset of D.


You're almost guaranteed to hit some wall with it and have no 
solution. Some of these are bugs but some of them are by design; 
betterC is a set of arbitrary restrictions without much 
consistent reasoning behind them.

For example, with dlls, you still have to deal with all the 
potential problems of C library version mismatches, but if you 
use any module that touches a D feature it is likely to compile 
but then fail to link when someone uses it! All pain, no gain.
Feb 04 2023
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 4 February 2023 at 18:40:51 UTC, Tamas 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.


This is achieved without the betterC switch, and severely limited 
with it.


 Also, your words give me the impression that I cannot trust the 
 documentation; which isn't a great start into the learning 
 process.


There's a lot of things described in the documentation that don't 
actually work. D can be an *extremely* productive language if you 
know which parts to focus on, but most the newer hyped features 
just don't deliver.

The table of contents on the left side of the site is in roughly 
chronological order. The things near the top are pretty reliable, 
with a few exceptions (which are generally called out in the 
documentation if you read it carefully, like how the "static 
initialization of associative arrays" is "not yet implemented", 
or misuse of shared is "is not an error yet by default").

The things near the bottom are not reliable. The C++ interface 
works in some cases but you aren't likely to get far using it in 
any real world project; the C++ stdlib bindings are extremely 
minimal and Windows-only. The Objective-C interface works 
beautifully on dmd.... which cannot target the new Apple devices. 
ldc can generate code for those arm chips, but the Objective-C 
interface is not implemented on ldc.

The portability guide and named character entities are pretty 
much ok.

The memory safety ` safe` stuff only actually works if you 1) opt 
into it in the functions and 2) opt into it on command line 
params. This is mentioned in the docs as a small note near the 
bottom. The design of  safe also allows several things that can 
escape it on certain systems.

The ABI page is ok, but there are several bugs in the debug info 
output. I find it good enough but it can be annoying.

The vector extensions work on dmd if you can piece together the 
magic but the other compilers do it differently.

The betterC page has several falsehoods on it, including the 
misinformation that you need to use it to link into C 
applications. This is just 100% nonsense. It also claims nearly 
the full language remains available, but this is also simply 
false. Some of the things listed there can be made to work with a 
bunch of code, but many things just plain don't work, even if you 
add the small amounts of code necessary to enable them.

For example, interfaces don't work, even if you implement your 
own dynamic cast function. It just doesn't let them link. It 
claims constructors and destructors work, which is true, unless 
they're `static`, in which case you get random errors. Delegates 
and lambdas work if you manage captured variables in your own 
functors, but otherwise are simply disabled, even if you had your 
own backing system.

Even module imports can fail because betterC disables outputting 
the module data info, even if it would otherwise be required by 
language rules, despite it not using the druntime.

Then importC only works for toy examples. Using two separate 
headers or modules will result in spurious compile errors (and 
bugs detailing how to address this have been closed WONTFIX), and 
there's several kinds of C apis it just doesn't support.

And finally, the  live functions also only work in toy examples 
and the design is fundamentally limited to only direct function 
calls, no struct aggregation is supported at all. It is a 
complete dead end.

On the other hand, if you avoid most the compiler switches and 
stick to the more solid features - "Interfacing to C" and above 
on the list, for the most part - you'll find D is a very capable 
conservative language.
Feb 04 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/02/2023 1:20 PM, Adam D Ruppe wrote:

 Even module imports can fail because betterC disables outputting the 
 module data info, even if it would otherwise be required by language 
 rules, despite it not using the druntime.


This only affects you if you use full D to interact with -betterC code.

Even then it is very easy to work around.

https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/moduleinfostubs.d

-betterC DLL's do work with full D executables.

If all you need it for is gluing some stuff together don't listen to 
Adam about it not working, because it absolutely does and quite usable 
if you're not expecting there to be a GC.
Feb 04 2023
parent reply Tamas <km212121 gmail.com> writes:
On Sunday, 5 February 2023 at 00:27:19 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 05/02/2023 1:20 PM, Adam D Ruppe wrote:

 Even module imports can fail because betterC disables 
 outputting the module data info, even if it would otherwise be 
 required by language rules, despite it not using the druntime.


 This only affects you if you use full D to interact with 
 -betterC code.

 Even then it is very easy to work around.

 https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/moduleinfostubs.d

 -betterC DLL's do work with full D executables.

 If all you need it for is gluing some stuff together don't 
 listen to Adam about it not working, because it absolutely does 
 and quite usable if you're not expecting there to be a GC.


I'm repeating myself, but I'm very happy to see so many helpful 
responses to my newbie question. It gives me a good feeling about 
the community here.

As I wrote, I'd like to use D only in a limited way, for now. My 
project actually interfaces Python and glib/gstreamer, the glue 
being provided by my C code. What I'd like to do is to improve on 
my C code, inspired by [this 
interview](https://dlang.org/blog/2017/08/23/d-as-a-better-c/). I 
don't want to introduce another GC or runtime into the picture, 
and I probably don't need to call any D libraries.

Python -> my C code -> glib/gstreamer C libs

to

Python -> C improved by betterC -> glib/gstreamer C libs

On the surface, betterC seems to be perfect for this case. How 
would YOU do it (Adam, Richard)?

BtW, gstreamer also has D bindings, and maybe in the future I'll 
use those. I suspect that Adam's suggestions have a stronger 
relevance to that case, right?
Feb 05 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 05/02/2023 10:01 PM, Tamas wrote:

 On the surface, betterC seems to be perfect for this case. How would YOU 
 do it (Adam, Richard)?
 
 BtW, gstreamer also has D bindings, and maybe in the future I'll use 
 those. I suspect that Adam's suggestions have a stronger relevance to 
 that case, right?


So LDC with druntime and yes GC turned on is good enough right now that 
you can probably make it work without too much effort. You don't 
necessarily have to limit yourself to -betterC.

In fact if you don't, you have access to PyD[0] which can handle the 
interop stuff for you. I haven't personally used it, but it might work 
for your use case :)

The main thing is no matter what flags you pass, you'll need to be 
careful about memory ownership between the language divide and the 
ownership therein. You have already got a hang of that though from the C 
version! Just gotta be extra careful with GC memory that its pinned on 
the D side and won't get free'd elsewhere.

But yeah if you can avoid having to create bindings for stuff (such as 
glib which we have bindings for), or wrappers ext. do so. That way you 
can do more of the fun things!

[0] https://github.com/ariovistus/pyd
Feb 05 2023
parent Tamas <km212121 gmail.com> writes:
On Sunday, 5 February 2023 at 19:00:16 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 So LDC with druntime and yes GC turned on is good enough right 
 now that you can probably make it work without too much effort. 
 You don't necessarily have to limit yourself to -betterC.

 In fact if you don't, you have access to PyD[0] which can 
 handle the interop stuff for you. I haven't personally used it, 
 but it might work for your use case :)

 [...]
 But yeah if you can avoid having to create bindings for stuff 
 (such as glib which we have bindings for), or wrappers ext. do 
 so. That way you can do more of the fun things!


Sounds quite convincing, I think I might do it this way, instead 
of with betterC. Not needing additional python bindings does 
sound like a big plus. Thanks.
Feb 06 2023
prev sibling parent reply Tamas <km212121 gmail.com> writes:
On Sunday, 5 February 2023 at 00:20:24 UTC, Adam D Ruppe wrote:

 There's a lot of things described in the documentation that 
 don't actually work. D can be an *extremely* productive 
 language if you know which parts to focus on, but most the 
 newer hyped features just don't deliver.

 The table of contents on the left side of the site is in 
 roughly chronological order. The things near the top are pretty 
 reliable, [...].

 The things near the bottom are not reliable. [...] and so on


I appreciate all of this... however, as a newcomer, I wish the 
docs were simply more honest, instead of representing wishful 
thinking. I guess in any programming language, experience reveals 
things not present in the docs, but it seems to apply much more 
acutely here.
Feb 05 2023
parent reply bachmeier <no spam.net> writes:
On Sunday, 5 February 2023 at 08:48:34 UTC, Tamas wrote:


 I appreciate all of this... however, as a newcomer, I wish the 
 docs were simply more honest, instead of representing wishful 
 thinking. I guess in any programming language, experience 
 reveals things not present in the docs, but it seems to apply 
 much more acutely here.


Technically, those pages are [the spec rather than 
documentation](https://dlang.org/spec/spec.html).


 This is the specification for the D Programming Language.


I've been bitten by that a few times over the years, though to be 
honest, I'm not sure of the relationship of the spec to 
documentation. The Phobos documentation and compiler 
documentation appear to be actual documentation, in the sense 
that you can trust it to be accurate, and if not it's a bug. 
Maybe someone that has been around from the earliest days 
understands the goal of the spec.
Feb 06 2023
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Feb 06, 2023 at 03:54:40PM +0000, bachmeier via Digitalmars-d-learn
wrote:

 On Sunday, 5 February 2023 at 08:48:34 UTC, Tamas wrote:


[...]

 This is the specification for the D Programming Language.


 
 I've been bitten by that a few times over the years, though to be
 honest, I'm not sure of the relationship of the spec to documentation.
 The Phobos documentation and compiler documentation appear to be
 actual documentation, in the sense that you can trust it to be
 accurate, and if not it's a bug.  Maybe someone that has been around
 from the earliest days understands the goal of the spec.


IIRC the spec was started as part of an ongoing effort to fully specify
the language so that, at least in theory, someone could read the spec
and implement a D compiler completely independent of the current ones.


T

-- 
INTEL = Only half of "intelligence".
Feb 06 2023
prev sibling parent Tamas <km212121 gmail.com> writes:
On Monday, 6 February 2023 at 15:54:40 UTC, bachmeier wrote:

 This is the specification for the D Programming Language.


 I've been bitten by that a few times over the years, though to 
 be honest, I'm not sure of the relationship of the spec to 
 documentation. The Phobos documentation and compiler 
 documentation appear to be actual documentation, in the sense 
 that you can trust it to be accurate, and if not it's a bug.


I see... I guess I was confused by the title of the link, 
"Language Reference" on the Docs page, and didn't look carefully 
at the URL or the text after that.
Feb 06 2023
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
In betterC mode you don't have access to the standard library or 
the runtime

You can only access the libc functions

Basically the modules from: ``import core.stdc``

So for your example, just do like you'd do in C

As simple as that


As for DMD/LDC, easy:

DMD: reference compiler, fast compile time

LDC: LLVM based compiler, LLVM is slow, but provides great 
optimizations


It's common to use DMD for debug, fast iteration time, and LDC 
for release builds, so you en enjoy great performance
Feb 04 2023