The issue with libraries that use Windows API prototypes

Jacob Carlborg doob at me.com
Sun Jul 10 02:27:27 PDT 2011


On 2011-07-09 18:55, Andrej Mitrovic wrote:
> I've run into yet another incompatibility issue with D2 libraries that
> use the Windows API.
> This time it's Derelict:
>
> testderelict.obj(testderelict)
>   Error 42: Symbol Undefined _wglDeleteContext at 4
> testderelict.obj(testderelict)
>   Error 42: Symbol Undefined _wglMakeCurrent at 8
> testderelict.obj(testderelict)
>   Error 42: Symbol Undefined _wglCreateContext at 4
> --- errorlevel 3
>
> The issue? Derelict uses its own Windows API header prototype in
> \Derelict2\DerelictUtil\derelict\util, which defines:
>
> 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;
>
> 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".
>
> 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), 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.
>
> To add insult to injury, MessageBoxW isn't even defined in
> \druntime\src\core\sys\windows\windows.d (that's imported by
> std.c.windows.windows). It defines maybe 5% of anything in WindowsAPI,
> so using std.c.windows.windows is out of the question because of an
> enormous wall of errors due to missing symbols.
>
> But even so, std.c.windows.windows *also* defines HANDLE:
> typedef void *HANDLE;
>
> So far, we have 3 incompatible libraries. Add a couple of more
> libraries like DFL, DGui DCairo and now we're up to 6.

We can probably add DWT to this list as well. This seems like quite a 
mess that needs to be sorted out. It's hard to tell what the best 
solution would be. There need to be some kind of bindings in druntime, 
since it depends on the Windows APIs. On the other hand it seems to be 
unnecessary to have DirectX bindings and similar in druntime. Perhaps 
the best solution is to have an absolute minimum set of bindings in 
druntime and then merge all other bindings in the Windows API bindings 
project. This would be less of an issue when we get a package manager for D.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list