On Jan 25, 2012, at 11:27 AM, Vladimir Panteleev wrote: > On Wednesday, 25 January 2012 at 19:16:34 UTC, Jonathan M Davis wrote: >> The level of support for the Windows API in druntime and Phobos is pretty >> low. As I understand it, Windows users are pretty much forced to use >> http://www.dsource.org/projects/bindings/browser/trunk/win32 if they need >> comprehensive Win32 API bindings. druntime seems to be trying to define all >> of the OS-specific stuff like that, but on top of it missing much of it, in >> the case of the Win32 API, that's a _lot_ of functions, and I don't know if >> we want to put that much in druntime. So, the question is, how do we want to >> support the Win32 API in druntime and Phobos? >> >> Do we want to put all of the Win32 API bindings in druntime? If not, then do >> we want to put them in Phobos? Or do we just want to send Windows developers >> to a 3rd party library like the Win32 bindings project on dsource? Given >> that they're OS bindings, I would _think_ that we'd want them in druntime, >> but I don't know. > > I support putting all public domain modules from the Win32 bindings project > into Druntime. > > The entirety of the Windows API modules (headers in C) and accompanying > import libraries are an integral part of The Windows SDK. There is no obvious > finer-grained separation of modules, so including only a part of them would > need to be done on mostly subjective decisions. > > The only non-public-domain modules are the DirectX headers (which don't > belong in Druntime either way), and WinSock modules, which are "Portions > Copyright (c) 1980, 1983, 1988, 1993 The Regents of the University of > California. All rights reserved." and "Portions Copyright (c) 1993 by > Digital Equipment Corporation."
For what it's worth, I tried integrating these headers ages ago (into Tango I believe) and stopped mostly because they were broken at the time. I imagine they're sorted by now, and so long as there's little maintenance effort on my part and there are no license concerns I'm all for it. The only other thing to be aware of is that each module linked into an executable incurs some overhead (500 bytes minimum, if I remember correctly), so moving to these new Win32 headers will increase the footprint of D apps on Windows. I imagine it's a worthwhile tradeoff, but I did want to bring this up so no one is surprised later.
