Open CyberShadow opened 9 years ago
The bindings are now part of the 2.070 D release: http://dlang.org/changelog/2.070.0.html
@CyberShadow You got me pretty excited there for a minute :smile: But I don't see any of the DirectX, XAudio, or XInput bindings in 2.070.2, unfortunately. It sounded like you meant that all these bindings were adopted.
I decided to leave out bindings that did not clearly have license information that permitted inclusion (in this case, all bindings which did not have a public domain header). That included the Winsock2 and all DirectX modules.
I'm not sure that porting a header file to another language and distributing it would violate any sort of license. I'd like to see more of the bindings integrated to druntime. Is there anything I could do to help with this? I could look into the licensing if that would help? I work at HP and we use windows CE and XP on our printers so there's quite a few people here who are familiar with these types of details I could talk to.
I have since written a tool that converts MS .idl
files to D which I used to generate D3D11 bindings. Doing manual conversion seemed kind of insane to me since there are so many what with all the recent revisions of / additions to D3D11. Unfortunately, that tool does not 100% automate this process. Because MS IDL allows for raw c++ code insertion using the cpp_quote
command (yay...) my conversion tool does not touch them and just copies them over verbatim, adding a static_assert
that they still need manual conversion.
The results of that tool can be found here: krepel-d/code/directx. For reference, this folder also contains the original .idl
files.
The resulting .d
files don't have a license yet or anything (because I didn't care so far) but I'd gladly share those!
If you're interested, I've moved the conversion tool here.
Honestly there isn't much left.
I'm fairly certain that the DirectX bindings don't belong in Druntime proper, since nothing in Phobos or Druntime needs them. They would be a good candidate for Deimos.
That just leaves the WinSock bindings, at which point it'd be easier to simply improve the existing ones.
@marler8997 If a header is translated from one language to another, the translated header is a derivative work of the original header, and therefore the licence of the original header is relevant. It depends on what that licence says about derivative works.
@smjgordon yes I suppose that makes sense. Do we know how the headers are licensed? I would imagine it would have to be a very open license (for the headers).
@marler8997 The MinGW headers were public domain when we started the project. However, this seems to have changed to a MIT-style licence at some point. I'm not sure what that means. I guess that once you've released something into the public domain you can't really take it out again, and so the older versions would still be PD, but the newer updates to the files are MIT licensed.
FWIW:
So I guess that leaves us with 2 options for winsock in druntime:
Does this sound correct?
It's a bit silly that we can't use what we already have, but this sort of thing does happen when it comes to licensing. We would probably be OK using the code based of the winsock2 headers, but these 2 options are pretty full proof IMO.
Use a derivative work of the MinGW winsock2 headers (MIT is a very open license, if I remember correctly the only requirement is to include the MIT license in any derivative work and maintain the copyright notice).
Yes, and this is an additional burden that Phobos/Druntime currently does not have. Depending on how you interpret it, it would mean that a copy of the MIT license would need to be redistributed with ANY Windows program compiled with a D compiler, which is obviously unreasonable for a programming language.
Modify what's in druntime right now based on the windows documentation (instead of the headers themselves) so it's not a "derivative work" of the headers.
This is the way to go. Another correct way to do it, when applicable, is to write small C programs which print the results of including Windows headers, such as struct sizes or offsets, and use these numbers to implement the D versions.
Use a derivative work of the MinGW winsock2 headers (MIT is a very open license, if I remember correctly the only requirement is to include the MIT license in any derivative work and maintain the copyright notice).
Yes, and this is an additional burden that Phobos/Druntime currently does not have. Depending on how you interpret it, it would mean that a copy of the MIT license would need to be redistributed with ANY Windows program compiled with a D compiler, which is obviously unreasonable for a programming language.
Yes, requiring every application that uses the druntime to include the MIT license would be VERY bad. Well it looks like we have a clear path forward. I could work on this and submit a PR but I'd want to make sure no one else is currently working on it and that this code is something that people want included in druntime. But if someone else wants to do this I'm fine with that as well. How should we move forward?
but I'd want to make sure no one else is currently working on it
As far as I know, the only person who might be already working on it is @qchikara. He recently submitted a huge patch that fixes a lot of declarations from the adapted headers:
https://github.com/dlang/druntime/pull/1576
Perhaps you could coordinate with him. Otherwise I think it's unlikely that someone is already working on this particular issue.
As far as I know, the only person who might be already working on it is @qchikara. He recently submitted a huge patch that fixes a lot of declarations from the adapted headers:
Hi. I've already finished my work and am not going to modify this. So feel free to do your works, please.
Hi, just to let you know - there are two efforts underway to integrate these bindings into Druntime, so they can be distributed with D:
https://github.com/D-Programming-Language/druntime/pull/1076 https://github.com/D-Programming-Language/druntime/pull/1402
Hopefully once one of these is merged, third-party repositories will become unnecessary and development can continue in D's GitHub repo.