On 24 November 2012 01:08, Jonathan M Davis <[email protected]> wrote:
> On Friday, November 23, 2012 15:15:41 Gor Gyolchanyan wrote: > > As we all know, the WinAPI binding in druntime as well as the static > > libraries of WinAPI, which come with DMD are in horrendous state. > > I am not all that well acquainted with all of the issues involved with the > Win32 API, so I'm probably not the best qualified to chime in on how they > should be handled. However, I would point out that given that the Win32 > API is > effectively the system layer API for Windows, it should be fully supported > in > druntime (just like glibc should be fully supported for Linux by druntime), > and as Walter points out, such a layer should be thin rather than trying > to fix > anything (that's the job of Phobos or other wrapper libraries). And since > we're about to have 64-bit Windows support, druntime should be updated with > whatever C prototypes are in the 64-bit Windows API (and I really don't > know > how those relate to the Win32 API other than the fact that as I understand > it, > 64-bit Windows still uses some version of the Win32 API). > > So, I would hope that the various Windows Gurus around here could come to > an > agreement on how the Windows API bindings should be put into druntime and > then > someone (or several someones) would take the time to implement that. I > don't > think that we should continue with the approach that anyone doing anything > serious with the Win32 API has to use a 3rd party project to do it. > OS-level > functions should be part of druntime for every OS that we support, and it's > worthy of a bug report every time that we find an OS-level function that > is not > in druntime. > I'm regularly annoyed by the quality of the druntime windows bindigs. I use this one: http://www.dsource.org/projects/bindings/wiki/WindowsApi It's better. I don't think there's really any room for opinion on the topic, the windows bindings should simply be complete, and correct. It's a flat C api, I can't imagine anything in there that doesn't translate to D well. As said before, the only details that might require some discussion are the handling of the windows version macro, and the unicode macro. I would personally just expect to use them exactly as they are in C, and expect the user to supply the appropriate versions to D when compiling.
