Getting back into translating the Win32 headers - anyone?

[Don Clugston]

Stewart Gordon wrote:
> Not long ago (read: three months ago), there was a thread here to the
> effect that this effort to translate the Windows API headers had gone 
> quiet.
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/announce/4605.html
> http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
> 
> However, activity since then has continued to be minimal.  Can anyone
> hazard a guess at why?  I can't....
> 
> The good news is that I've recently got an Internet connection set up on
> the PC I do my D programming on.  Despite being broadband through a
> router, it's intermittent, but at least I've got it at all.  And I've
> even got Subversion working!  So no longer will I have to zip up my
> updates and upload them to my website.  I guess I ought to remove the
> link to my zip edition from the wiki page....
> 
> I'm working on implementing the status scheme proposed by Don Clugston:
> 
> - Initial conversion, but with sections commented out -- fixme
> - Initial conversion with basic functionality -- compiles
> - Fully functional (including versioning, pragma(lib)) -- alpha
> - Polished -- beta
> 
> 
> There are a few open issues that I feel still need to be addressed:
> 
> 1. Should having the types of all constants (where available) be a
> prerequisite for counting as "fully functional", and therefore having
> alpha status?  Or is this something for the beta stage?  I suppose it 
> depends on whether you consider the difference between alpha and beta to 
> be purely cosmetic issues.
> 
> 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.
> 
> 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 think (c) should be private, except in a few rare cases where they are 
  'top-level' modules that do nothing except publically import other 
modules.

> 
> 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.
> 
> 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.

For the ones done by me (which is probably a fair fraction of the 
total), I didn't think about it at all. Returning the value passed in 
probably makes more sense.

> 
> 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.
> 
Agreed.
> 
> We've less than 30 days to get it done and dusted if we're going to
> submit a full translation for DMD 1.0.  Even better would be if it can
> be got done by the time I go back to my immediate family for Christmas
> around the 20th.  So come on guys!
> 
> Stewart.