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