The issue with libraries that use Windows API prototypes

[Stewart Gordon]

On 09/07/2011 17:55, Andrej Mitrovic wrote:
<snip>
> alias void* HANDLE;
> alias HANDLE HGLRC;
>
> And the "_wgl" functions take HGLRC as the parameter.
>
> The problem is WindowsAPI also defines these, because well, it's a
> binding library so it has to. And it's prototypes are:
>
> typedef void* HANDLE;
> alias HANDLE HGLRC;

I don't know Derelict at all.  But if as I make out it's a cross-platform library, I'm 
surprised if many functions in its API receive or return Windows API types directly, which 
should be the only case in which this matters.  But for passing a HANDLE to a Derelict 
function, it still shouldn't be a problem as a typedef can be implicitly converted to its 
underlying type.

derelict.util.wintypes.HANDLE and win32.basetsd.HANDLE are distinct symbols.  If your code 
uses WindowsAPI, Derelict can still use its own bindings internally.  Yes, it's wasteful, 
but the code should still compile.

> When linking my project with WinsowsAPI and Derelict, the Derelict
> static library defines a function as "_wglDeleteContext", while the
> project that uses WindowsAPI sees the wglDeleteContext prototype from
> the import, but sees the HGLRC typedef in WindowsAPI, and DMD looks
> for the symbol "_wglDeleteContext at 4".

And does it find that symbol?

If not, have you checked that you're linking in all the right .lib files?

> So now I can't really use Derelict and the WindowsAPI. Perhaps I can
> use it with std.c.windows.windows? Nope, guess again!
>
> std.c.windows.windows doesn't define NULL (small nuisance),

Why is it a nuisance at all?  D code should use null, which is built in, not NULL.

> and it
> doesn't use aliases to ANSI/WideChar versions of API functions like
> the WindowsAPI bindings, you have to explicitly use e.g. MessageBoxA
> or MessageBoxW.

std.c.windows is very deficient (last time I knew, Walter just added stuff as and when he 
needed it), so why single this omission out?

> *Every single* Windows-related library seems to define its own winapi
> prototypes, and because of issues like:
> 1. typedefs (which we're going to hopefully kill sometime soon)
> 2. small differences in how these prototypes were written
>
> these libraries become incompatible with each other. It's only going
> to get worse as each library author keeps growing their library and
> adds more prototypes.

It's inefficient, but since the symbols have distinct fully qualified names, I can't see 
it causing clashes generally.  Trouble occurs if:

(a) A library API module (as opposed to a module for the library's internal use) publicly 
defines one of these symbols or publicly imports a module that does, thereby forcing you 
to use fully qualified names.

(b) You need to pass data of Windows API types directly between your app and the library. 
  Then you end up needing to use casts.  You might also need to import a library module 
that defines the types, thereby making (a) an issue here too.

> I can see two ways out of this situation:
> 1) D Library authors start using the WindowsAPI bindings from
> http://dsource.org/projects/bindings/wiki/WindowsApi, and expect the
> user of the their library to put WindowsAPI in the import path where
> the authors' libraries can find it to resolve symbols, and where the
> user's project can import it as well. This would mean the author's
> library's build process gets a bit more complicated as you would have
> to pass the path to the WindowsAPI bindings when building the author's
> library.

Then tell D programmers to install library code under a common base path, so that at most 
one extra import path in sc.ini is needed however many third party libraries you use.

> 2) We devise some plan to incorporate WindowsAPI into Phobos itself.
> This way library users don't have to waste time fetching dependencies,
> and library authors don't have to waste time prototyping functions
> since the majority of this work will be already incorporated into
> Phobos.
<snip>

http://d.puremagic.com/issues/show_bug.cgi?id=317

Moreover, it's about time we had a plan for getting these bindings completed. 
Unfortunately now that I have a job....

Stewart.