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@4
testderelict.obj(testderelict)
Error 42: Symbol Undefined _wglMakeCurrent@8
testderelict.obj(testderelict)
Error 42: Symbol Undefined _wglCreateContext@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@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
