digitalmars.D - Windows API and druntime/Phobos
- Jonathan M Davis (19/19) Jan 24 2012 The level of support for the Windows API in druntime and Phobos is prett...
- Vladimir Panteleev (14/30) Jan 25 2012 I support putting all public domain modules from the Win32
- Trass3r (1/3) Jan 25 2012 Yep, Walter just added what he used.
- Kagamin (4/9) Jan 27 2012 Public domain? PSDK is not public domain. Isn't "Microsoft &
- Vladimir Panteleev (6/16) Jan 27 2012 The files in the Windows API bindings project are translations
- Kagamin (4/9) Jan 28 2012 Things like CRITICAL_SECTION are documented as opaque structures.
- Kagamin (2/2) Jan 28 2012 I also remember MinGW folks were asked about this, but they don't
- Marco Leise (20/22) Jan 29 2012 I understand that Microsoft prefers Visual Studio to be used with one of...
- Sean Kelly (31/41) Jan 27 2012 pretty low. As I understand it, Windows users are pretty much forced to ...
- Vladimir Panteleev (8/14) Jan 27 2012 Would it be possible to fix this overhead in the compiler
- Andrej Mitrovic (3/3) Jan 28 2012 I really hope druntime doesn't get one gigantic windows.d file. I
- Marco Leise (7/10) Jan 29 2012 No, it should be done like everywhere else where the IDEs have no proble...
- Jonathan M Davis (6/9) Jan 28 2012 It will definitely be more organized than that. I would think that it wo...
- Vladimir Panteleev (3/14) Jan 28 2012 http://www.dsource.org/projects/bindings/browser/trunk/win32/windows.d
- Andrej Mitrovic (2/3) Jan 28 2012 Well sheeeit, somehow I never noticed that file being there.
- Don (3/22) Jan 25 2012 Please note that the Win32 API project on dsource was created with the
- Jonathan M Davis (17/19) Jan 25 2012 Good to know. I would point out though that for the most part, std.c has...
- Jacob Carlborg (6/25) Jan 25 2012 It depends. If we want to keep druntime small and only contain what's
- Jesse Phillips (9/19) Jan 25 2012 It seems to me that calling OS functions are expected to work out
- Yao Gómez (9/10) Jan 25 2012 On Wednesday, 25 January 2012 at 19:58:40 UTC, Jesse Phillips
- Jesse Phillips (4/14) Jan 25 2012 I don't see how that is the problem, this post is about what to
- Vladimir Panteleev (8/11) Jan 25 2012 Underlying implementation of language features trickles down to
- Jesse Phillips (4/6) Jan 25 2012 Yes it is, there aren't doc comments on anything:
- Jonathan M Davis (6/17) Jan 25 2012 Pretty much none of the C bindings in druntime generate documentation - ...
- Jacob Carlborg (4/21) Jan 25 2012 That would be good to have. A link to the C documentation would hurt eit...
- Sean Kelly (11/19) Jan 27 2012 either the DMC runtime or Windows APIs. Druntime defines the Windows =
- Sean Kelly (20/26) Jan 27 2012 pretty low. As I understand it, Windows users are pretty much forced to ...
- Jonathan M Davis (10/16) Jan 27 2012 The value in having empty ddoc comments is so that if you need to use an...
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. Regardless, this is one of those issues which frequently plagues D Windows developers, and we really should at least get a plan together as to how we want to handle it. - Jonathan M Davis P.S. A related pull request: https://github.com/D-Programming- Language/druntime/pull/139
Jan 24 2012
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."
Jan 25 2012
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.Yep, Walter just added what he used.
Jan 25 2012
On Wednesday, 25 January 2012 at 19:27:47 UTC, Vladimir Panteleev wrote: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.Public domain? PSDK is not public domain. Isn't "Microsoft & public domain" an oxymoron?
Jan 27 2012
On Friday, 27 January 2012 at 18:16:38 UTC, Kagamin wrote:On Wednesday, 25 January 2012 at 19:27:47 UTC, Vladimir Panteleev wrote:The files in the Windows API bindings project are translations from the MinGW headers, which were created based on the documentation (which explains the occasional errors). The MinGW headers are public domain. Considering that MinGW is not an obscure project, I think we're on safe legal ground here.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.Public domain? PSDK is not public domain. Isn't "Microsoft & public domain" an oxymoron?
Jan 27 2012
On Friday, 27 January 2012 at 20:37:04 UTC, Vladimir Panteleev wrote:The files in the Windows API bindings project are translations from the MinGW headers, which were created based on the documentation (which explains the occasional errors). The MinGW headers are public domain. Considering that MinGW is not an obscure project, I think we're on safe legal ground here.Things like CRITICAL_SECTION are documented as opaque structures. http://social.msdn.microsoft.com/Forums/en-US/winembplatdev/thread/3856c437-9a7e-4315-a954-fc50e25a12f2
Jan 28 2012
I also remember MinGW folks were asked about this, but they don't know, where the headers came from.
Jan 28 2012
Am 28.01.2012, 11:22 Uhr, schrieb Kagamin <spam here.lot>:I also remember MinGW folks were asked about this, but they don't know, where the headers came from.I understand that Microsoft prefers Visual Studio to be used with one of their compilers, but you can't honestly sue anyone nowadays for copying headers to interface with the OS. It is Windows, the most used OS on consumer PCs. Who's gain was it if a major part of open source software was locked out because they couldn't port the application due to missing OS headers. If you always looked only on the legal side of things, you would be allowed and disallowed absurd things: http://www.guardian.co.uk/politics/2007/nov/07/uk.queensspeech20072 The other ingredient is common sense. - So you don't buy Visual Studio, which may be a loss for MS, if those OSS developers would have switched to Windows, bought VS etc... in the other case, Windows loses popularity as a platform, because a lot of software wont be ported. With the background of the legal debate about making IE4 a part of the operating system I'd assume that some degree of freedom and choice of software is today considered almost as valuable as a formal copyright in a header file. It would be different if WINE somehow got the Windows source code and was only through this event becoming an alternative that made Windows obsolete. But I think we had the header/interface discussion here already :)
Jan 29 2012
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: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?The level of support for the Windows API in druntime and Phobos is =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.=20 Do we want to put all of the Win32 API bindings in druntime? If not, ==20 I support putting all public domain modules from the Win32 bindings =project into Druntime.=20 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.=20 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.=
Jan 27 2012
On Friday, 27 January 2012 at 18:36:28 UTC, Sean Kelly wrote: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.Would it be possible to fix this overhead in the compiler (avoiding generation of such overhead for modules without classes, static ctors/dtors, etc.)? Even though Windows API programs classically begin with #include <windows.h>, which includes most of the other headers, this isn't a requirement, and it's possible to import modules on a finer-grained basis.
Jan 27 2012
I really hope druntime doesn't get one gigantic windows.d file. I don't want to wait seconds for syntax highlighting to kick in because a file is huge.
Jan 28 2012
Am 28.01.2012, 09:41 Uhr, schrieb Andrej Mitrovic <andrej.mitrovich gmail.com>:I really hope druntime doesn't get one gigantic windows.d file. I don't want to wait seconds for syntax highlighting to kick in because a file is huge.No, it should be done like everywhere else where the IDEs have no problem dealing with the Windows headers. C++, Delphi, ... . I think COM and WinSock are usually separate, whereas user32 and kernel32 are commonly imported through one file. I may be wrong. If a particular IDE/editor is slow it must be fixed :)
Jan 29 2012
On Saturday, January 28, 2012 09:41:21 Andrej Mitrovic wrote:I really hope druntime doesn't get one gigantic windows.d file. I don't want to wait seconds for syntax highlighting to kick in because a file is huge.It will definitely be more organized than that. I would think that it would be organized along the lines of how the win32 API itself is organized, but I don't know. It probably also depends on what the current bindings project does. A giant windows.d would definitely be rejected though. - Jonathan M Davis
Jan 28 2012
On Saturday, 28 January 2012 at 09:22:33 UTC, Jonathan M Davis wrote:On Saturday, January 28, 2012 09:41:21 Andrej Mitrovic wrote:http://www.dsource.org/projects/bindings/browser/trunk/win32/windows.dI really hope druntime doesn't get one gigantic windows.d file. I don't want to wait seconds for syntax highlighting to kick in because a file is huge.It will definitely be more organized than that. I would think that it would be organized along the lines of how the win32 API itself is organized, but I don't know. It probably also depends on what the current bindings project does. A giant windows.d would definitely be rejected though.
Jan 28 2012
On 1/28/12, Vladimir Panteleev <vladimir thecybershadow.net> wrote:http://www.dsource.org/projects/bindings/browser/trunk/win32/windows.dWell sheeeit, somehow I never noticed that file being there.
Jan 28 2012
On 25.01.2012 05:48, 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. Regardless, this is one of those issues which frequently plagues D Windows developers, and we really should at least get a plan together as to how we want to handle it. - Jonathan M Davis P.S. A related pull request: https://github.com/D-Programming- Language/druntime/pull/139Please note that the Win32 API project on dsource was created with the explicit intention of including it in Phobos. See bug 317.
Jan 25 2012
On Wednesday, January 25, 2012 20:38:01 Don wrote:Please note that the Win32 API project on dsource was created with the explicit intention of including it in Phobos. See bug 317.Good to know. I would point out though that for the most part, std.c has been being phased out with all of its parts being moved to Phobos, so I'm not sure that putting the Win32 API bindings in std.c.windows makes sense. Regardless, my point is that we need to figure out what we want to do at this point. As it stands, we end up with pull requests such as https://github.com/D-Programming-Language/druntime/pull/139 which just add more bindings which a particular programmer happens to want. And while that might be okay in the short term, that doesn't work in the long term. We need to decide where we want the Win32 API bindings, how we want them organized more or less, and start putting them there. The Win32 API project is a great start, but it's been around for years without being moved into druntime or Phobos, and we should start looking at moving those bindings into either druntime or Phobos. At this point, given that they're OS bindings, and the OS bindings have been going in druntime, I would expect them to go into druntime. But a decision must be made, or the situation won't improve. - Jonathan M Davis
Jan 25 2012
On 2012-01-26 00:50, Jonathan M Davis wrote:On Wednesday, January 25, 2012 20:38:01 Don wrote:It depends. If we want to keep druntime small and only contain what's necessary for the runtime it would be better to add the bindings to Phobos. But that would mean to duplicate parts of the bindings. -- /Jacob CarlborgPlease note that the Win32 API project on dsource was created with the explicit intention of including it in Phobos. See bug 317.Good to know. I would point out though that for the most part, std.c has been being phased out with all of its parts being moved to Phobos, so I'm not sure that putting the Win32 API bindings in std.c.windows makes sense. Regardless, my point is that we need to figure out what we want to do at this point. As it stands, we end up with pull requests such as https://github.com/D-Programming-Language/druntime/pull/139 which just add more bindings which a particular programmer happens to want. And while that might be okay in the short term, that doesn't work in the long term. We need to decide where we want the Win32 API bindings, how we want them organized more or less, and start putting them there. The Win32 API project is a great start, but it's been around for years without being moved into druntime or Phobos, and we should start looking at moving those bindings into either druntime or Phobos. At this point, given that they're OS bindings, and the OS bindings have been going in druntime, I would expect them to go into druntime. But a decision must be made, or the situation won't improve. - Jonathan M Davis
Jan 25 2012
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?It seems to me that calling OS functions are expected to work out of the box. This would preclude requiring a third party library. I don't think it makes sense in Druntime. It isn't required for the compiler to work that I know of. Maybe their are some Windows functions used within druntime? Also what is there currently isn't generating documentation. Phobos already has std.windows, it just needs expanded.
Jan 25 2012
On Wednesday, 25 January 2012 at 19:58:40 UTC, Jesse Phillips wrote: [snip]Phobos already has std.windows, it just needs expanded.The issue is that this would be a huge undertaking, as the std.windows (or core.sys.windows, to be more precise) is awfully incomplete. Maybe we could add the Win32 bindings into the Deimos project, and make it more prominent somehow. -- Yao Gómez
Jan 25 2012
On Wednesday, 25 January 2012 at 21:36:36 UTC, Yao Gómez wrote:On Wednesday, 25 January 2012 at 19:58:40 UTC, Jesse Phillips wrote: [snip]I don't see how that is the problem, this post is about what to do with the Win32 bindings project which is quite a bit more complete and created for the intent of inclusion of Phobos.Phobos already has std.windows, it just needs expanded.The issue is that this would be a huge undertaking, as the std.windows (or core.sys.windows, to be more precise) is awfully incomplete. Maybe we could add the Win32 bindings into the Deimos project, and make it more prominent somehow. -- Yao Gómez
Jan 25 2012
On Wednesday, 25 January 2012 at 19:58:40 UTC, Jesse Phillips wrote:I don't think it makes sense in Druntime. It isn't required for the compiler to work that I know of.Underlying implementation of language features trickles down to using either the DMC runtime or Windows APIs. Druntime defines the Windows APIs locally where needed, which is a hack. Example: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L31Also what is there currently isn't generating documentation.This is not true: http://dlang.org/phobos/core_thread.html
Jan 25 2012
On Wednesday, 25 January 2012 at 21:44:21 UTC, Vladimir Panteleev wrote:Yes it is, there aren't doc comments on anything: https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/windows.dAlso what is there currently isn't generating documentation.This is not true: http://dlang.org/phobos/core_thread.html
Jan 25 2012
On Thursday, January 26, 2012 00:20:52 Jesse Phillips wrote:On Wednesday, 25 January 2012 at 21:44:21 UTC, Vladimir Panteleev wrote:Pretty much none of the C bindings in druntime generate documentation - I believe primarily because Sean doesn't want to redo C documentation. However, that doesn't preclude giving them empty documentation so that you can see what's there, and that hasn't been done. - Jonathan M DavisYes it is, there aren't doc comments on anything: https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/ windows/windows.dAlso what is there currently isn't generating documentation.This is not true: http://dlang.org/phobos/core_thread.html
Jan 25 2012
On 2012-01-26 00:44, Jonathan M Davis wrote:On Thursday, January 26, 2012 00:20:52 Jesse Phillips wrote:That would be good to have. A link to the C documentation would hurt either. -- /Jacob CarlborgOn Wednesday, 25 January 2012 at 21:44:21 UTC, Vladimir Panteleev wrote:Pretty much none of the C bindings in druntime generate documentation - I believe primarily because Sean doesn't want to redo C documentation. However, that doesn't preclude giving them empty documentation so that you can see what's there, and that hasn't been done. - Jonathan M DavisYes it is, there aren't doc comments on anything: https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/ windows/windows.dAlso what is there currently isn't generating documentation.This is not true: http://dlang.org/phobos/core_thread.html
Jan 25 2012
On Jan 25, 2012, at 1:44 PM, Vladimir Panteleev wrote:On Wednesday, 25 January 2012 at 19:58:40 UTC, Jesse Phillips wrote:compiler to work that I know of.I don't think it makes sense in Druntime. It isn't required for the ==20 Underlying implementation of language features trickles down to using =either the DMC runtime or Windows APIs. Druntime defines the Windows = APIs locally where needed, which is a hack.=20 Example: =20 =https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmai= n2.d#L31 This was done to reduce coupling between modules and to reduce the = runtime footprint in executables. It's not terribly = maintenance-friendly however, and so Druntime is slowly transition to = simply importing the appropriate module. A number of these remain = mostly because it ain't broke as-is.
Jan 27 2012
On Jan 25, 2012, at 11:58 AM, Jesse Phillips wrote:On Wednesday, 25 January 2012 at 19:16:34 UTC, Jonathan M Davis wrote: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?The level of support for the Windows API in druntime and Phobos is ==20 It seems to me that calling OS functions are expected to work out of =the box. This would preclude requiring a third party library.=20 I don't think it makes sense in Druntime. It isn't required for the =compiler to work that I know of. Maybe their are some Windows functions = used within druntime? Also what is there currently isn't generating = documentation. System headers are absolutely required for Druntime to build. This is = one of the reasons core.stdc and core.sys exist. Documentation isn't = generated because these are interfaces to external APIs, so the = documentation for those APIs should be referenced when coding to them. = We could add an empty doc comment to every declaration so something was = generated in the Druntime docs, but I don't know why anyone would ever = actually refer to them.=
Jan 27 2012
On Friday, January 27, 2012 10:39:41 Sean Kelly wrote:System headers are absolutely required for Druntime to build. This is one of the reasons core.stdc and core.sys exist. Documentation isn't generated because these are interfaces to external APIs, so the documentation for those APIs should be referenced when coding to them. We could add an empty doc comment to every declaration so something was generated in the Druntime docs, but I don't know why anyone would ever actually refer to them.The value in having empty ddoc comments is so that if you need to use any of the functions in them for some reason (which _does_ happen upon occasion), then you know what module has what without having to go find the source code and look through it. So, ideally, all of the declarations in druntime for the C APIs should at least have empty ddoc so that they're documented. I completely agree that it's best not to try and duplicate the full documentation for them - that's best left to the C docs - but documenting what's there is still valuable, and we should probably do that at some point. - Jonathan M Davis
Jan 27 2012