On Saturday, May 12, 2012 15:47:15 Gor Gyolchanyan wrote:
> What are the plans to finish the WinAPI in druntime? It's grossly lacking at the moment.

Someone needs to do it. Simple as that. It'll probably be done by taking code from the existing Win32 API project (it's whole purpose in the first place from what I understand was to collect the Win32 API stuff in preparation for putting it in the standard library), and it will probably require rearranging some of how that stuff is laid out in druntime, from what I understand, but regardless, the big thing is that someone needs to take the time to do it, and no one has.

- Jonathan M Davis

There is a very good binding of WinAPI in dsource.org in bindings project.
It's aim is to precisely replicate the WinAPI's headers.
What are the requirements of the druntime WinAPI? What needs to be done to
get the existing binding into druntime?

On Sat, May 12, 2012 at 10:25 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Saturday, May 12, 2012 15:47:15 Gor Gyolchanyan wrote:
> > What are the plans to finish the WinAPI in druntime? It's grossly lacking at the moment.
>
> Someone needs to do it. Simple as that. It'll probably be done by taking
> code
> from the existing Win32 API project (it's whole purpose in the first place
> from
> what I understand was to collect the Win32 API stuff in preparation for
> putting
> it in the standard library), and it will probably require rearranging some
> of
> how that stuff is laid out in druntime, from what I understand, but
> regardless,
> the big thing is that someone needs to take the time to do it, and no one
> has.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

On Saturday, May 12, 2012 22:28:12 Gor Gyolchanyan wrote:
> There is a very good binding of WinAPI in dsource.org in bindings project.
> It's aim is to precisely replicate the WinAPI's headers.
> What are the requirements of the druntime WinAPI? What needs to be done to
> get the existing binding into druntime?

What kind of requirements are you worried about? We want all of the Win32 API bindings in druntime in an organized manner (my first guess would be according to the dll or header that they come from in C, but I don't know how the bindings project does it or necessarily what the best way is). I don't believe that what's currently in druntime is necessarily organized properly (I don't think that where new declarations go has been all that organized), so some stuff will likely have to be moved around when the WinAPI bindings are merged in (with the appropriate deprecation path used for any declarations that must be moved). But really, it's just a question of someone taking the time and making the effort to merge the WinAPI bindings into druntime and creating a pull request for it.

- Jonathan M Davis

I'll just move the binding to druntime and rename the package from win32.*
to core.c.windows.*
There are tons of modules, each for a header file in original WinAPI.
Next, we're gonna have to update the libs. What does it take to update the
libs? Are there any legal or technical difficulties?

On Sat, May 12, 2012 at 10:43 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Saturday, May 12, 2012 22:28:12 Gor Gyolchanyan wrote:
> > There is a very good binding of WinAPI in dsource.org in bindings
> project.
> > It's aim is to precisely replicate the WinAPI's headers.
> > What are the requirements of the druntime WinAPI? What needs to be done
> to
> > get the existing binding into druntime?
>
> What kind of requirements are you worried about? We want all of the Win32
> API
> bindings in druntime in an organized manner (my first guess would be
> according
> to the dll or header that they come from in C, but I don't know how the
> bindings project does it or necessarily what the best way is). I don't
> believe
> that what's currently in druntime is necessarily organized properly (I
> don't
> think that where new declarations go has been all that organized), so some
> stuff will likely have to be moved around when the WinAPI bindings are
> merged
> in (with the appropriate deprecation path used for any declarations that
> must
> be moved). But really, it's just a question of someone taking the time and
> making the effort to merge the WinAPI bindings into druntime and creating a
> pull request for it.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

On 12/05/2012 19:47, Gor Gyolchanyan wrote:
> I'll just move the binding to druntime and rename the package from win32.* to core.c.windows.*
> There are tons of modules, each for a header file in original WinAPI.
<snip>

You mean you're going to try merging the bindings into your installation of druntime and see if it works, in order to see whether there are complications that need to be overcome?

On Sat, May 12, 2012 at 10:43 PM, Jonathan M Davis
<jmdavisProg@gmx.com <mailto:jmdavisProg@gmx.com>> wrote:
<snip>
> What kind of requirements are you worried about?  We want all of
> the Win32 API bindings in druntime in an organized manner (my first
> guess would be according to the dll or header that they come from
> in C, but I don't know how the bindings project does it or
> necessarily what the best way is).

This is indeed how the WinAPI bindings project is organised - each file is a translation of the C header of the corresponding name.  And yes, it was started with a view of putting it into Phobos when it's ready (druntime didn't exist back then).

> I don't believe that what's currently in druntime is necessarily
> organized properly (I don't think that where new declarations go
> has been all that organized), so some stuff will likely have to be
> moved around when the WinAPI bindings are merged in (with the
> appropriate deprecation path used for any declarations that must be
> moved).  But really, it's just a question of someone taking the
> time and making the effort to merge the WinAPI bindings into
> druntime and creating a pull request for it.

What's going to happen about continued maintenance of the bindings once they've been dropped in?  Are we just going to carry on maintaining the bindings on dsource and then make pull requests every now and again to update druntime to it?

There are a few things that still need to be thought about, like how handle types are defined.  Better to get this decided before we drop it into druntime.  I'll start another thread about this and other issues.

Stewart.

On Sunday, May 13, 2012 15:03:08 Stewart Gordon wrote:
> What's going to happen about continued maintenance of the bindings once they've been dropped in?  Are we just going to carry on maintaining the bindings on dsource and then make pull requests every now and again to update druntime to it?
> 
> There are a few things that still need to be thought about, like how handle types are defined.  Better to get this decided before we drop it into druntime.  I'll start another thread about this and other issues.

Yes. That sort of stuff needs to be sorted out as part of getting the bindings into druntime. As for maintenance, I would expect that the WinAPI project would be effectively superseded by druntime and become completely redundant, but the WinAPI project will probably be around for a while. How the bindings get maintained depends entirely on who is willing to create the appropriate pull requests when changes are necessary and what they do. It'll certainly work better if someone takes it upon themselves to actively maintain them. But if someone has been doing that with the WinAPI bindings, then presumably, they can do it with druntime.

- Jonathan M Davis

On 13/05/2012 15:17, Jonathan M Davis wrote:
<snip>
> Yes. That sort of stuff needs to be sorted out as part of getting the bindings
> into druntime. As for maintenance, I would expect that the WinAPI project
> would be effectively superseded by druntime and become completely redundant,

Being migrated from dsource to druntime doesn't constitute becoming "completely redundant" in my mind....

> but the WinAPI project will probably be around for a while. How the bindings
> get maintained depends entirely on who is willing to create the appropriate
> pull requests when changes are necessary and what they do.

I think what might work best is to carry on maintaining the project on dsource, and have pull requests created from this, at least for as long as it's still far from finished or there's still D1 as well to worry about.

> It'll certainly
> work better if someone takes it upon themselves to actively maintain them. But
> if someone has been doing that with the WinAPI bindings, then presumably, they
> can do it with druntime.

In theory, that someone is me.  But in practice, I've mostly been tied up with other things in recent times.

Stewart.

On Sunday, May 13, 2012 17:39:08 Stewart Gordon wrote:
> On 13/05/2012 15:17, Jonathan M Davis wrote:
> <snip>
> 
> > Yes. That sort of stuff needs to be sorted out as part of getting the bindings into druntime. As for maintenance, I would expect that the WinAPI project would be effectively superseded by druntime and become completely redundant,
> Being migrated from dsource to druntime doesn't constitute becoming "completely redundant" in my mind....

If someone wants to keep maintaning the WinAPI project no dsource, they're free to, but if it's in druntime, I don't know why you would. druntime is always going to be on any box with D, whereas the WinAPI project won't be, and if all of the bindings are in druntime, then the WinAPI project adds nothing. It seems completely redundant at that point. But there's nothing stopping it from continuing regardless.

- Jonathan M Davis

On 13/05/2012 21:24, Jonathan M Davis wrote:
<snip>
> If someone wants to keep maintaning the WinAPI project no dsource, they're
> free to, but if it's in druntime, I don't know why you would. druntime is
> always going to be on any box with D, whereas the WinAPI project won't be, and
> if all of the bindings are in druntime, then the WinAPI project adds nothing.
> It seems completely redundant at that point. But there's nothing stopping it
> from continuing regardless.

How do you come to the conclusion that, if the WinAPI project is migrated, the place it's been migrated from continues to constitute "the WinAPI project"?

As I see it, the WinAPI project would be primarily in druntime, as well as being still available on dsource with the latest community-contributed updates.  This would continue to have a number of advantages:

- Can continue to collaborate efficiently in updating the bindings to a new version of the MinGW headers or of Windows.
- Those who are already working on the WinAPI project don't have to learn a whole new way of doing things.
- Anybody can quickly get the latest updates through SVN as is the case currently.

But maybe we'd be better off crossing this bridge when we get to it, i.e. when the WinAPI project has more or less stabilised....

Stewart.