Including windows.h

[Walter Bright]

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.