typedef is deprecated--WindowsAPI should be updated. Problem solved? Sent from my iPhone
On Jul 9, 2011, at 12:55 PM, Andrej Mitrovic <andrej.mitrov...@gmail.com> 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. > > *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. > > 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. > > 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. > > The DCairo author kindly suggested to use version(WindowsAPI) > else(HisOwnPrototypes) as a workaround, but this doesn't scale. There > could be numerous prototypes based on how many libraries you use. > > How #2 can be organized, I don't know. But we have to start from > somewhere because the more time we wait, the worse this situation > gets.