Getting back into translating the Win32 headers - anyone?

[Don Clugston]

Stewart Gordon wrote:
> Don Clugston wrote:
>> Stewart Gordon wrote:
>>> Don Clugston wrote:
>>> <snip>
>>>>> (a) If the whole point of a module is to import other modules, then 
>>>>> obviously the imports have to be public.
>>>>> (b) If qwert.h doesn't include yuiop.h, but yuiop.d is required for 
>>>>> qwert.d to compile, then the import should be private.
>>>>> (c) This leaves the general case where a C header includes another.
> <snip>
>> I think I created windows.core, which does that, but it's probably 
>> unique. I think we should try to eliminate all cases of (c), turning 
>> them into (a) or (b).
> 
> The cases (a), (b) and (c) are from the POV of the C headers.  That was 
> about what each case should become in the D code.  It would make no 
> sense to change anything to (b), because in D you can't use a symbol 
> from another module without importing it.

There are many cases where the SDK docs say "this is in xxx.h, but do 
not #include xxx.h directly. Instead, use yyy.h which includes xxx.h".
Sometimes it turns out that yyy is including zzz.h which is including xxx.h.
In this situation, I think that zzz should privately import xxx, and yyy 
should publicly import both xxx and zzz.
That is, the only instances of public imports should be with modules 
intended to be directly imported by the user.

>> What are the case (c)'s at the moment?
> 
> See for yourself.  Grep the MinGW headers for "#include", and then cross 
> off those headers that have no content but #include directives.
> 
> <snip>
>> I doubt I'll contribute much more to the Windows API project anytime 
>> before D 1.0, I'm too tied up in another D project.
> 
> I know what you mean - I get tied up in different D projects from time 
> to time too.  Thank you for telling us - though it would've been nice to 
> have known sooner.
> 
>> A couple of suggestions, though:
>> * vfw is an obselete, buggy technology, and the MinGW header is a 
>> disaster area. I think we should just drop it.
> 
> I don't know enough about vfw to give any first-hand opinion, but on the 
> basis of what you say, if nobody disagrees then maybe we should get rid 
> of it indeed.
> 
>> * Some of the other MinGW header, like zmouse, are so incomplete 
>> there're probably not worth including.
> 
> Indeed, zmouse does nothing but defines constants that are already 
> defined elsewhere.
> 
>> * We don't need windowsx, either, it's just for C programmers without OO.
> 
> I'm not sure what I think to this.  It defines macros for manipulating 
> the older Windows controls, just as commctrl does for the newer ones. 
> But they aren't documented in my win32.hlp.

It's ancient. It was around in the Windows 3.0 days, maybe even older. 
They just kept including it for backwards compatibility.
It's probably best to think of windowsx.h as 'framework code', like MFC, 
rather than part of the WinAPI itself.
Arguably we want a D equivalent of it, but that would be very different 
to a port.