www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Including windows.h

reply Valentino Giudice <valentino.giudice96 gmail.com> writes:
Hi.

I know this isn't the first thread about this issue, but they are 
from years ago, so I'm writing to see if something has changed.

Attempting to compile, through importC, on Windows, code that 
includes windows.h leads to several linker C5106 warnings and 
LNK2019 errors from link.exe.

As a workaround, I compiled the C file through cl, from the 
Developer Command Prompt for VS, without linking (through the 
`/c` flag) and added the obj as a source file (instead of the C 
file). I'm using Dub to compile and I also had to add lflags for 
certain libraries (gdi32.lib and user32.lib) in my case.

It works now, but doing things this way is not ideal.

Compiling is no longer cross-platform (windows.h is only on 
Windows, of course, but the file contains specific code for other 
systems) and I can't import symbols through `import`, only 
`extern (C)`.

Is there any way to use importC to compile files that include 
windows.h and, if not, are there any plans to resolve this?

Thank you a lot in advance!
Jun 21
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
If there are any issues outside of the following tickets please report.

https://github.com/dlang/dmd/issues?q=is%3Aissue%20state%3Aopen%20windows.h
Jun 21
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Every operating system vendor suffers from the disease of feeling compelled to 
add all kinds of ding-dong extensions to their C compiler, all different from 
every other operating system, and weld them into their ding-dong system .h
files.

(The correct way to do this is to make the .h files use Standard C, and
relegate 
the ding-dongs to the implementation files that nobody ever needs to see.)

With D, this has resulted in a lot of ugly hacks and workarounds for the 
ding-dong constructions. You can see these in
druntime/src/__importc_builtins.di 
and druntime/src/importc.h.

They can help in showing how to deal with windows.h.

An alternative you can try is windows.d in druntime.

If you're blocked, the thing to do is file an issue for each item, and then the 
D community can help out.
Jun 22
next sibling parent reply Araq <rumpf_a web.de> writes:
On Tuesday, 23 June 2026 at 04:00:02 UTC, Walter Bright wrote:

 (The correct way to do this is to make the .h files use 
 Standard C, and relegate the ding-dongs to the implementation 
 files that nobody ever needs to see.)


Nope, that is a terrible way to do as you lose crucial semantic 
information about the true parameter ranges, aliasing information 
etc. Your very own "gee-ha we can type check 
printf-format-strings" piece of trivia depends on non-Standard C 
extensions or else is tied to functions literally named printf 
etc.

The correct way it to treat the standard header files as abstract 
entities that might not even exist on the disc.
Jun 23
next sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Tuesday, 23 June 2026 at 08:45:55 UTC, Araq wrote:

 On Tuesday, 23 June 2026 at 04:00:02 UTC, Walter Bright wrote:

 (The correct way to do this is to make the .h files use 
 Standard C, and relegate the ding-dongs to the implementation 
 files that nobody ever needs to see.)


 Nope, that is a terrible way to do as you lose crucial semantic 
 information


Losing some semantic information is not that bad, but I get the 
point.
Jun 23
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/23/2026 1:45 AM, Araq wrote:

 On Tuesday, 23 June 2026 at 04:00:02 UTC, Walter Bright wrote:

 (The correct way to do this is to make the .h files use Standard C, and 
 relegate the ding-dongs to the implementation files that nobody ever needs to 
 see.)


 
 Nope, that is a terrible way to do as you lose crucial semantic information 
 about the true parameter ranges, aliasing information etc.



 Your very own "gee-ha 
 we can type check printf-format-strings" piece of trivia depends on
non-Standard 
 C extensions or else is tied to functions literally named printf etc.


printf for the Mac expands as:

int printf(const char * restrict, ...) __attribute__((__format__ (__printf__,
1, 
2)));

But I think that is an exception. The C standard library functions don't seem
to 
need extensions, as these are declared for the Mac as:

void *  memchr(const void * __s, int __c, size_t __n);
int memcmp(const void * __s1, const void * __s2,  size_t __n);
void *  memcpy(void * __dst, const void * __src,  size_t __n);
void *  memmove(void * __dst,  const void * __src, size_t __len);
void *  memset(void * __b, int __c, size_t __len);
char *  strcat(char * __s1, const char *__s2)

though I see no purpose to the __ prefixes, or even the existence of the 
parameter names.

The compiler, though, does recognize them and often will replace the function 
call with custom assembler.



 The correct way it to treat the standard header files as abstract entities
that 
 might not even exist on the disc.


Having the library interface be not visible to the programmer will make life 
difficult for him.
Jun 24
prev sibling parent Dave P. <dave287091 gmail.com> writes:
On Tuesday, 23 June 2026 at 04:00:02 UTC, Walter Bright wrote:

 Every operating system vendor suffers from the disease of 
 feeling compelled to add all kinds of ding-dong extensions to 
 their C compiler, all different from every other operating 
 system, and weld them into their ding-dong system .h files.

 (The correct way to do this is to make the .h files use 
 Standard C, and relegate the ding-dongs to the implementation 
 files that nobody ever needs to see.)

 [...]


If I recall correctly, part of the issue with why you get link 
errors when compiling windows.h is that D doesn’t implement C 
inline correctly and is generating externally visible functions 
in the object files for inline functions and is generating code 
at all for inline functions that aren’t called.

https://github.com/dlang/dmd/issues/21266
Jun 26
prev sibling parent reply Harry Gillanders <contact harrygillanders.com> writes:
On Monday, 22 June 2026 at 01:33:37 UTC, Valentino Giudice wrote:

 [...]
 I know this isn't the first thread about this issue, but they
 are from years ago, so I'm writing to see if something has
 changed.

 Attempting to compile, through importC, on Windows, code that
 includes windows.h leads to several linker C5106 warnings and
 LNK2019 errors from link.exe.
 [...]


The reason why the linker errors occur is that ImportC doesn't 
recognise MSVC's compiler intrinsics, and so attempts to call 
them as externally defined functions.
(As they are intrinsic, they have no external definition.)

A couple of years ago I wrote up D implementations for all but 
three of MSVC's intrinsics, with optimised code for LDC, GDC, and 
DMD. Unit-tested and all. Fuzzed, even, for the floating-point 
stuff!

I submitted a PR (https://github.com/dlang/dmd/pull/16372), but 
was unable to find a way to make the compiler able to use the D 
implementations' module without the end-user having to find the 
location of the `__builtins_msvc.d` file distributed with their 
compiler so that they could then supply its path when invoking 
the compiler (which was Walter's proposed solution to the 
problem).

A second problem was that—due to the way that MSVC's intrinsics 
are declared in Windows' headers—the compiler is unable to inline 
D implementations of the intrinsics.
Again I submitted a PR with a potential solution for that, but it 
was ignored by even dlang-bot: 
https://github.com/dlang/dmd/pull/16464

To answer your question, "are there any plans to resolve this?", 
the answer is ostensibly: no.

Alas, here lies testament to my folly of trying to make ImportC 
better for targeting Windows: 
https://github.com/users/just-harry/projects/1/
Jun 25
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 25 June 2026 at 08:33:26 UTC, Harry Gillanders wrote:



 Again I submitted a PR with a potential solution for that, but 
 it was ignored by even dlang-bot: 
 https://github.com/dlang/dmd/pull/16464

 To answer your question, "are there any plans to resolve 
 this?", the answer is ostensibly: no.


I don't believe it was intentionally ignored. I've pinged both of 
our Pull Request managers and Nicholas Wilson has left some 
feedback.

For anyone who has a PR that isn't getting attention, please post 
in the forums about it. We've got a small number of reviewers 
with a high volume of notifications, and some of them are bound 
to slip through the cracks.
Jun 25