The new core.sys.windows

Vladimir Panteleev via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 15 09:05:10 PDT 2015


On Thursday, 15 October 2015 at 08:34:10 UTC, Walter Bright wrote:
> I know how tempting it is to "fix" windows headers (or other 
> operating system headers). We made a decision long ago that 
> this is not on the agenda of the D project. We simply make the 
> closest approximation of them possible, and go with that.
>
> Taking on the task of "fixing" headers like that makes us then 
> responsible for documenting them, being responsible for them, 
> etc., that is way, way beyond our resources. By sticking with 
> them the way they are, we simply refer people to the OS vendor 
> documentation on how they are to be correctly used, for better 
> or worse.
>
> Also, it means that C code that deals with those APIs is 
> directly transcribable to D without going through another 
> translation process.
>
> I agree that they would be better if fixed, but the D project 
> is not going to do that. If anyone wants to make a set of fixed 
> windows imports, that's great, but it wouldn't be a part of the 
> official D release.

All good points.

I'd like to add some:

1. Some new versions of C/C++ Windows headers do define a "strict 
mode", which enables additional compile-time checks by using 
static typing, e.g. for all the various handle-like types.

2. The changes I had in mind would not change the way you would 
write code (and I agree C source compatibility is important and 
must be preserved). The "strict mode" mentioned above works in 
the same way. Compatibility with the old core.sys.windows.windows 
remains the highest priority.

3. This effort is likely going to prevent any third-party D 
Windows headers project become popular. Why bother if the headers 
in the language's runtime library are "good enough"?

Anyway, since there are supporters of both sides, it seems like 
the best course of action here and now is to leave the 
declarations as they are. If there is desire for it, we can 
improve C-source compatibility or introduce opt-in (enabled by a 
version) strict mode checks down the line.



More information about the Digitalmars-d mailing list