December 26, 2012
12/27/2012 12:36 AM, Phil Lavoie пишет:
> You know what, I have browsed it a little bit and I think the choice to
> make aliases to A and W versions was the right one. I was thinking of
> adding a
> version( Unicode ) {
>    aliases here...
> }

Somewhat OT.
But IMHO almost any use of *A version is either a bug (unintended) or a legacy code. The OS kernel(Win2K+) works in UTF-16 (or rather an unchecked "superset" of it) via so called UNICODE_STRING** and it's even not NUL-terminated.

The fact that the horrible legacy MBCS API is still there is merely typical M$ kind of thing (leave the old rusty API working so that old software keeps crawling).

The fact that no new API calls come in *A variant alone should be a good food for a thought.

** See http://msdn.microsoft.com/en-us/library/windows/hardware/ff564879(v=vs.85).aspx
(the exact same thing comes up in various areas of MSDN)

Moving more firmly into OT realms:

What would have been nice is version of the same binding with UTF-8 auto converted to UTF16 and passed to *W calls. The most of text is in UTF-8 anyway (and lot of stuff in D assumes simply 'string' i.e. UTF-8).
Thus we have 2 good things: newer API and cleaner text conversion (I won't be surprised in the least if it ends up to be faster then *A in some WINAPI calls).

-- 
Dmitry Olshansky
December 27, 2012
On 26/12/2012 20:36, Phil Lavoie wrote:
<snip>
> Of my own but I can see this is exactly what has been done so I am
> thrilled. One last question: do you know if people are planning to
> maintain this for windows 8 and following?

The plan has always been to try and keep it up ot date with the latest version of the MinGW Windows headers, which would hopefully continue to be expanded to include new API features in each successive Windows version and therefore include whatever is new in Windows 8 (actually Windows 6.2 - what was Bill Gates or whoever it is now thinking?)

> I'll download this and let you know if I am having any unsurmountable
> difficulty.

By all means.  Indeed, maybe you'd like to help with the project?

Stewart.
December 27, 2012
On 26/12/2012 20:22, Andrej Mitrovic wrote:
> On 12/26/12, Phil Lavoie <maidenphil@hotmail.com> wrote:
>> Makes sense, do you know of any plans to merge those with the dmd
>> distributables?
>
> It was discussed many times. I don't know if the Phobos team is
> willing to merge the dsource.org WinAPI in its current layout.
> WinAPI has aliases to Ascii/Unicode versions of functions which
> they don't like (or maybe it's just Walter who doesn't like it),

Any recollection of why?  Besides, if Walter just doesn't like these aliases, he doesn't have to use them.

> and it has a directory and file structure. Putting this whole API
> into a single file would be insane (it would be a 70.000 lines
> file). And the other problem is that currently DMD is distributed
> with all header and binary files for all OSes, so adding WinAPI
> would increase the size of the .zip file.

It seems common to bundle full Windows API headers with C(++) compilers - indeed, even DMC seems to (though they seem to be very out of date). So why not D compilers just as well?

> We should have separate packages for each OS,

I agree.

> but Walter is in charge of making them so I don't know when things
> will improve.
>
> Personally I'm tired of discussing this as the discussions always
> reach a stale-mate.

Indeed, it's time a positive effort were made.  At least for the time being, document the incompleteness properly and in doing so point people to the WindowsAPI project.  I'll try and come up with a proposal for how this should be done.

Stewart.
December 27, 2012
On 26/12/2012 18:35, Andrej Mitrovic wrote:
> On 12/26/12, Phil Lavoie <maidenphil@hotmail.com> wrote:
>> I believe everything was moved to the core.sys.windows.windows header.
>
> No, that module existed for a long time but it was lacking a lot of
> functionality, so a couple of devs created the WindowsAPI project
> instead.

I am the one who started this WindowsAPI project.  Good to hear people talking about it again.

There were a handful of people helping out with it at a time, but this has dwindled apparently through people's loss of interest and lack of time.  Indeed, lack of time is why I haven't contributed much to it lately (and why I haven't been active on the newsgroups lately) - I've been in and out of employment a few times since it started and, while it's nice having a job (both for the money and for the social aspects), it does mean that I don't have much time these days to devote to D projects.  But I do hope to find some time to do more on it in the not-too-distant future.

We have five people besides myself on this thread at the moment.  How many of you (or anyone else, for that matter) are actually willing to help out with the project?

Please see also
http://tinyurl.com/brrxtzj

I have now decided to implement the solutions proposed for points 1 and 2 therein.  I've just modified the translation instructions per point 2, but still need to go through changing already-translated headers accordingly.  I'll do this and take care of point 1 when I'm reunited with my usual computer in about a week's time.  Point 3 is TBD.

Stewart.
December 27, 2012
On Thursday, December 27, 2012 01:52:02 Stewart Gordon wrote:
> It seems common to bundle full Windows API headers with C(++) compilers
> - indeed, even DMC seems to (though they seem to be very out of date).
> So why not D compilers just as well?

The Windows headers should definitely be part of druntime just like the POSIX headers are. In theory, all of the system headers for any particular OS that druntime supports should be part of druntime. The main problem is that that takes time and effort, and that effort has not been made. It gets discussed from time to time, but it doesn't actually happen. Instead, everyone who needs the Windows headers just uses the Windows API project because it gives them what they need now. And until someone steps up to the plate and adds all of the appropriate headers to druntime (probably by porting them from the Windows API project), druntime won't have them.

As for the complaint about putting everything in a single file, there's no way that that's how it's ever going to be. core.sys.windows.windows is a mess that never should have existed, and I don't think that much of anyone is suggesting that all of the Windows declarations go in there. The POSIX stuff tries to put stuff in modules that correspond to the C header files, and the Windows stuff should do the same. And if I understand correctly, that's what the Windows API project does, which should make the transition easier. But there's still the issue of figuring out how to do that transition (like figuring out how to deal with versions and the like), and someone still has to do it.

- Jonathan M Davis
December 27, 2012
On 27/12/2012 04:04, Jonathan M Davis wrote:
<snip>
>  And if I understand correctly, that's what the Windows API
> project does, which should make the transition easier. But there's still the
> issue of figuring out how to do that transition (like figuring out how to deal
> with versions and the like), and someone still has to do it.

You mean how to give people who currently _are_ using core.sys.windows.windows the time to convert their code to use the full bindings?  If win32.* is just migrated to core.sys.windows.* then the problem is solved, since win32.windows is a module that imports everything.  The only thing they'll need to do is do away with the extra Windows API declarations they've put into their projects, in order to avoid symbol conflicts.

Stewart.
December 27, 2012
On Thursday, December 27, 2012 11:14:15 Stewart Gordon wrote:
> On 27/12/2012 04:04, Jonathan M Davis wrote:
> <snip>
> 
> >  And if I understand correctly, that's what the Windows API
> > 
> > project does, which should make the transition easier. But there's still the issue of figuring out how to do that transition (like figuring out how to deal with versions and the like), and someone still has to do it.
> 
> You mean how to give people who currently _are_ using core.sys.windows.windows the time to convert their code to use the full bindings?  If win32.* is just migrated to core.sys.windows.* then the problem is solved, since win32.windows is a module that imports everything.  The only thing they'll need to do is do away with the extra Windows API declarations they've put into their projects, in order to avoid symbol conflicts.

Transition is one issue, but as I understand it, there are issues with regards to versioning, since druntime tends assume that there's only one OS version instead of asking you which version you're building for, whereas the actual Windows API uses a fair number of ifdefs which use macros, and the Windows API project has tried to emulate that. I think that there were also issues with different approaches for handling types between what the Windows API project is doing now and what druntime is doing now. I'd have to go look through previous discussions on that to really know what was going on though. I don't deal with Windows much and am prone to forgetting some of those types of details.

Regardless of what the issues are though or how much effort is involved in merging the Windows API project into druntime, someone has to take the time to sort it all out and do it, and no one has done that yet. We need a D developer who's familiar with Windows and the Windows API project to step up and take it on. The last, major discussion on it was instigated by someone interested in doing it, but they weren't all that familiar with the Windows side of things, and it seems that some issues weren't properly sorted out, so it never went anywhere.

- Jonathan M Davis
December 27, 2012
On 27/12/2012 11:40, Jonathan M Davis wrote:
<snip>
> Transition is one issue, but as I understand it, there are issues
> with regards to versioning, since druntime tends assume that
> there's only one OS version instead of asking you which version
> you're building for,

Are you talking about issues like this?
http://d.puremagic.com/issues/show_bug.cgi?id=6024

This is an issue that needs to be resolved by using code that works in all 32-bit Windows versions or, if this can't be done, detecting the OS version at runtime.  Not by getting the programmer to specify the target version of Windows, since such specification doesn't belong in a program that is written to be platform-agnostic.

As such, no version identifiers in druntime for Windows versions (besides Win32/Win64) is exactly how it should be at the moment.  Once we add Windows API bindings, only _then_ should we worry about adding these version identifiers.  And, unless there's something else I've missed, we can take care of it by simply migrating WindowsAPI across as it is.

If the fix to bug 6024 (and any similar issues) involves calling an XP-specific function that is currently declared in c.s.w.w without versioning, the module in druntime could have its own private redeclaration of this function.

<snip>
> I think that there were also issues with
> different approaches for handling types between what the Windows API project is
> doing now and what druntime is doing now.

When you say "handling types", what kinds of stuff you mean?

> We need a D developer who's familiar with Windows and the Windows
> API project to step up and take it on.

I believe we already have that somebody - me.  What we're lacking is:
- somebody who is in this position and actually has plenty of time to look into it
- a clear decision on what is the minimum Windows version D2 is to support (given that the abandonment of D1 is imminent)
- a clear decision on when to do the migration - get it over with as soon as we can and then pull updates as and when, wait until the bindings are finished, or somewhere between the two extremes?

> The last, major discussion on it was instigated by someone
> interested in doing it, but they weren't all that familiar with the
> Windows side of things, and it seems that some issues weren't
> properly sorted out, so it never went anywhere.

Which discussion are you referring to as "the last, major discussion on it"?

Stewart.
December 27, 2012
On Thursday, December 27, 2012 13:20:14 Stewart Gordon wrote:
> On 27/12/2012 11:40, Jonathan M Davis wrote:
> <snip>
> 
> > Transition is one issue, but as I understand it, there are issues with regards to versioning, since druntime tends assume that there's only one OS version instead of asking you which version you're building for,
> 
> Are you talking about issues like this? http://d.puremagic.com/issues/show_bug.cgi?id=6024

No. There was ifdef stuff of some kind, but I don't recall the details. You'd probably know more about that sort of stuff than I would. I'm just recalling stuff from previous discussions and not necessarily all that accurately.

We're not supporting anything older than XP, but we're still supporting XP, so whatever is done with the bindings needs to be in line with that.

> This is an issue that needs to be resolved by using code that works in all 32-bit Windows versions or, if this can't be done, detecting the OS version at runtime.  Not by getting the programmer to specify the target version of Windows, since such specification doesn't belong in a program that is written to be platform-agnostic.
> 
> As such, no version identifiers in druntime for Windows versions (besides Win32/Win64) is exactly how it should be at the moment.  Once we add Windows API bindings, only _then_ should we worry about adding these version identifiers.  And, unless there's something else I've missed, we can take care of it by simply migrating WindowsAPI across as it is.
> 
> If the fix to bug 6024 (and any similar issues) involves calling an XP-specific function that is currently declared in c.s.w.w without versioning, the module in druntime could have its own private redeclaration of this function.
> 
> <snip>
> 
> > I think that there were also issues with
> > different approaches for handling types between what the Windows API
> > project is doing now and what druntime is doing now.
> 
> When you say "handling types", what kinds of stuff you mean?

IIRC, stuff relating to HANDLE, void*, and possibly some other stuff was being debated as to the best way to handle it. I don't recall the details.

> > We need a D developer who's familiar with Windows and the Windows API project to step up and take it on.
> 
> I believe we already have that somebody - me.  What we're lacking is:
> - somebody who is in this position and actually has plenty of time to
> look into it
> - a clear decision on what is the minimum Windows version D2 is to
> support (given that the abandonment of D1 is imminent)

XP. I think that it's fairly clear at this point that at minimum, we're going to support whatever versions of Windows Microsoft still supports. What's not clear is how long after Microsoft ceases to support a version we'll cease supporting that version. But since XP is around until at least sometime 2014, we don't have to make that decision right now.

> - a clear decision on when to do the migration - get it over with as soon as we can and then pull updates as and when, wait until the bindings are finished, or somewhere between the two extremes?

Ideally, the bindings would end up in druntime as soon as possible, but obviously, that's highly dependent on the schedule of anyone who's working on that. I have no idea what that will ultimately meaning for the Windows API bindings project. I would think that it would become irrelevant and that anything that would have needed to be done there would just be done in druntime, but others may feel differently, and I'm not a Windows developer, so I don't know any of the nitty-gritty details here.

> > The last, major discussion on it was instigated by someone interested in doing it, but they weren't all that familiar with the Windows side of things, and it seems that some issues weren't properly sorted out, so it never went anywhere.
> 
> Which discussion are you referring to as "the last, major discussion on it"?

I believe that it was the "WinAPI for druntime and OpenGL for deimos" thread that Gor Gyolchanyan started, though it looks like it got chopped up funny in the archives:

http://forum.dlang.org/post/mailman.2156.1353669352.5162.digitalmars- d@puremagic.com

http://forum.dlang.org/post/mailman.2157.1353670441.5162.digitalmars- d@puremagic.com

- Jonathan M Davis
December 27, 2012
On 27/12/2012 13:52, Jonathan M Davis wrote:
<snip>
> No. There was ifdef stuff of some kind, but I don't recall the
> details. You'd probably know more about that sort of stuff than I
> would. I'm just recalling stuff from previous discussions and not
> necessarily all that accurately.

So you mean ifdefs from the C headers that have been just commented out because we weren't sure how to deal with them?  I'll have to take a look.  Or ifdefs in some other set of headers?

> We're not supporting anything older than XP, but we're still
> supporting XP, so whatever is done with the bindings needs to be in
> line with that.

Are you referring to DMD or to the D language as a whole?  And where is the official statement?

<snip>
>> When you say "handling types", what kinds of stuff you mean?
>
> IIRC, stuff relating to HANDLE, void*, and possibly some other
> stuff was being debated as to the best way to handle it. I don't
> recall the details.

Oh yes.  See my reply to Andrej's first post on this thread and the thread linked to therein.  But hopefully making this change won't break any code, but might expose some code as being already broken.

> I have no idea what that will ultimately meaning for the Windows
> API bindings project. I would think that it would become irrelevant
> and that anything that would have needed to be done there would
> just be done in druntime, but others may feel differently, and I'm
> not a Windows developer, so I don't know any of the nitty-gritty
> details here.

We've had this conversation already....
http://tinyurl.com/csg5oug
(For some reason this half of the thread seems to be missing from the archives on digitalmars.com)

<snip>
> I believe that it was the "WinAPI for druntime and OpenGL for
> deimos" thread that Gor Gyolchanyan started, though it looks like
> it got chopped up funny in the archives:
>
> http://forum.dlang.org/post/mailman.2156.1353669352.5162.digitalmars-
> d@puremagic.com
>
> http://forum.dlang.org/post/mailman.2157.1353670441.5162.digitalmars-
> d@puremagic.com

It seems the reason it didn't get anywhere was that I was too busy with work and stuff and hadn't checked the 'group properly in too long.

Too bad that thread doesn't seem to have generated any interest in helping with the project....

Stewart.