Getting back into translating the Win32 headers - anyone?

[Chris Miller]

On Sat, 02 Dec 2006 09:54:14 -0500, Stewart Gordon <smjg_1998 at yahoo.com>  
wrote:
> 2. Which should be the default - winsock or winsock2?  Don once wrote:
>
> "I really think that Winsock2 should be the default, since it was
> supported in Win95. It was definitely included in Win95 B and C. It's
> possible that Winsock2 might not have been included in the original
> Win95 release, but any such computers with networks connections would be
> immediately wiped out by viruses if they've never been upgraded to
> Winsock2. We can be confident that there are no Win95 PCs that want to
> use Winsock1. Winsock1 is a 16-bit technology, I doubt that any D
> programs will ever use it. -- Don"
>
> What does everybody else think?  If nobody disagrees or gets there
> first, I'll change Winsock2 to be the default.

I'd go with winsock2.

>
> 3. When should imports be public, and when should they be private?
>
> (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.
>
> Should we make imports of kind (c) public or private?  Moreover, should
> we declare (b) and (c) imports using "private import" or simply "import"?

I guess the main windows.d would public import everything else, and most  
everything else might be private import, unless such files were intended  
to pull other things. e.g. people include windows.h expecting the bulk of  
windows stuff to be included as well, but they generally don't include  
winbase.h and expect winerror.h to be tagged along, even if it is.

>
> 4. There seem to be a few ways of doing the variable-length structs in  
> use.
>
>      struct MIB_IPADDRTABLE {
>          DWORD            dwNumEntries;
>          MIB_IPADDRROW[1] _table;
>
>          MIB_IPADDRROW* table() { return _table.ptr; }
>      }
>
> or
>
>      struct MIB_IPADDRTABLE {
>          DWORD         dwNumEntries;
>          MIB_IPADDRROW _table;
>
>          MIB_IPADDRROW* table() { return &_table; }
>      }
>
> or (merely proposed, I don't think used yet)
>
>      struct MIB_IPADDRTABLE {
>          DWORD         dwNumEntries;
>          MIB_IPADDRROW _table;
>
>          MIB_IPADDRROW[] table() { return (&_table)[0..dwNumEntries]; }
>      }
>
> Which should we settle with?  I personally think the proposed idea is a
> good one.  Just as the C headers make use of C's lack of ABC, so the D
> translation would make use of D's ABC.  Look also at the idea for custom
> allocators for these things on the discussion page of the wiki.

I think I prefer the first one, as it most resembles what MS did. The last  
one is probably too D-like for a C interface, especially considering the C  
version of table would decay into a pointer, and yours would be a D slice.

>
> 5. I've noticed that bit field setters have variously, depending on who
> coded them up, been declared to return void or to return the value
> passed in.  Is there any reason to have them returning void?  We ought
> to make these consistent.

Unsure. Perhaps D's properties should automatically call the getter if the  
setter is used as an rvalue and it returns void. Also consider foo.prop++;  
it should probably call the getter, apply ++ and call the setter with the  
new value. This automatic calling of getter/setter as appropriate seems  
more simplistic and pure, and should probably be addressed before 1.0 so  
that properties aren't crippled in the spec.

>
> 6. In many modules, class IDs defined externally in a library are being
> declared without the const attribute.  Is there some reason for this?
> They're constants, so surely they should be declared as such.

Is const stuff even added to object files? This might be why..