The issue with libraries that use Windows API prototypes

[Sean Cavanaugh]

On 7/9/2011 2:42 PM, Andrej Mitrovic wrote:
> Btw, the issue with those conflicting functions could be resolved by
> careful uses of selective imports:
>
> import win32.wingdi;
> // This overwrites win32\wingdi : wglMakeCurrent, wglDeleteContext,
> wglCreateContext;
> import derelict.opengl.wgl : wglMakeCurrent, wglDeleteContext, wglCreateContext;
> // This overwrites win32.basetsd or wherever HGLRC is
> import derelict.util.wintypes : HGLRC;
>
> But again, that doesn't scale as it gets tedious to have to do this in
> every module..

The Win32 Bindings project on dsource.org project is far more complete 
(even if it is missing some of Vista and a ton of Win7 functions and 
enumerations).  These apparently are a port of the mingw headers, but I 
can't help but wonder if it would be possible to split the different 
with the mingw developers and have the bindings live in a language 
neutral database with a code generator for C/C++ headers and D 
'headers'.  I would also expect this to be of interest to Mono to 
generate a complete and correct set of PInvoke bindings as well, and any 
other language that wants be able to talk native to Win32.

The other major weak leak I've run across are usages of COM and 
IUnknown.  They are defined in a few places as well which is problematic 
if you are trying to write COM interfaces that are provided by C/C++ 
dlls ( in my case, D3D11 bindings ).

import std.c.windows.com;
import win32.unknwn;

and a D template version of CComPtr from atl has to do two checks to see 
if it is a valid IUnknown object:

struct ComPtr(T)
{
public:
     static assert(is(T : std.c.windows.com.IUnknown) || is(T : 
win32.unknwn.IUnknown));
     T p;
     alias p this;
...
}


This is a pretty huge problem since its a giant violation of DRY (Don't 
Repeat Yourself).  There should only be one way of doing some things.