View mode: basic / threaded / horizontal-split · Log in · Help
December 26, 2012
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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
Re: What's up with the windows headers?
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.
1 2 3 4
Top | Discussion index | About this forum | D home