www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's up with the windows headers?

reply "Phil Lavoie" <maidenphil hotmail.com> writes:
Holà,

I am currently reading Programming Windows and coding his 
examples + my own initiatives. I know I am not the first one to 
do this and Andrej Mitrovic directed me to his code samples. I 
could not help but notice that those directives:
import win32.SOME_MODULE;
were used and are not supported anymore. I believe everything was 
moved to the core.sys.windows.windows header. Now somewhere along 
the way, either some MAJOR CHUNKS of the API got lost or they 
were never declared in the first time. I am curious to know how 
that happened and if this is planned to get fix for the next dmd 
release?

In any cases, I need those functions to test the Win32 api as I 
please so I started adding them to my own local import module. 
Then I started thinking: Surely, I am not the first one to do 
this? So I am asking the community if there is some knowledge of 
a more complete windows module somewhere?

If not, then I would be glad to add my contributions to the 
header so that it gets eventually completed. Now, in my HUMBLE 
opinion, for people developing Windows programs or cross 
compatible code (using the win32 api...) using D, isn't this kind 
of a big annoyance (maybe it should get prioritize)? Plus, for 
the newcomers making the jump from a language like C++ to D 
intending to program windows this might look like a major step 
back (since they got the full headers & stuff).

Additionally, I was wondering if it would be in the plans to also 
automagically link on Windows import libraries other than those 
currently supported (like gdi32 for example)?

Lemme know what you think.
Dec 26 2012
next sibling parent reply "Martin" <martinbbjerregaard gmail.com> writes:
http://www.dsource.org/projects/bindings/wiki/WindowsApi
Dec 26 2012
parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Wednesday, 26 December 2012 at 17:52:02 UTC, Martin wrote:

 http://www.dsource.org/projects/bindings/wiki/WindowsApi


KK cool, I will browse them. However, this is a 1 to 1 
correlation between windows headers and D versions, which is 
cool. I was hoping more for a direct replacement of 
core.sys.windows.windows. Though I can still use what you showed 
me, thanks.
Dec 26 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Dec 26 2012
next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
On Wednesday, 26 December 2012 at 18:35:56 UTC, 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.


Makes sense, do you know of any plans to merge those with the dmd 
distributables?
Dec 26 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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), 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. We should have separate packages for each OS, 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.
Dec 26 2012
next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
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...
}
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?

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

Cheers!

Phil
Dec 26 2012
next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
All right I got a problem now.
Including winver.d triggers the inclusion of version.lib through 
this:
pragma(lib, "version.lib");
However, this import library does not exist. So I created it 
using,implib /noi /system version.lib ...\System32\version.dll 
then moved it to the dmd\windows\lib folder.
Now when running using rdmd I get this error message:
--- errorlevel 1
Which means... WHAT?!?!?!?!

Thanks for any help
Dec 26 2012
next sibling parent "dnewbie" <run3 myopera.com> writes:
On Wednesday, 26 December 2012 at 21:56:31 UTC, Phil Lavoie wrote:

 All right I got a problem now.
 Including winver.d triggers the inclusion of version.lib 
 through this:
 pragma(lib, "version.lib");
 However, this import library does not exist. So I created it 
 using,implib /noi /system version.lib ...\System32\version.dll 
 then moved it to the dmd\windows\lib folder.
 Now when running using rdmd I get this error message:
 --- errorlevel 1
 Which means... WHAT?!?!?!?!

 Thanks for any help



If you have the Windows SDK:

cd C:\D\dmd2\windows\lib\
coffimplib "C:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.0A\Lib\version.lib"  version.lib
Dec 26 2012
prev sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Wednesday, 26 December 2012 at 21:56:31 UTC, Phil Lavoie wrote:

 All right I got a problem now.
 Including winver.d triggers the inclusion of version.lib 
 through this:
 pragma(lib, "version.lib");
 However, this import library does not exist. So I created it 
 using,implib /noi /system version.lib ...\System32\version.dll 
 then moved it to the dmd\windows\lib folder.
 Now when running using rdmd I get this error message:
 --- errorlevel 1
 Which means... WHAT?!?!?!?!

 Thanks for any help


KK I think it's related to that bug: 
http://d.puremagic.com/issues/show_bug.cgi?id=8377. So apparently 
it has something to do with the align directive being used. 
Fortunately it has been fixed. I'll have to rebuild dmd or wait 
for new release.
Dec 26 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Dec 26 2012
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 26 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 26 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 26 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 27 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 27 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 27 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 27 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 27 2012
next sibling parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
Hi,

I am currently using the win32 api bindings project and things 
went rather smoothly in migrating my (not so big) code (so far). 
I love that pragmas are everywhere to make the compiler link to 
proper libraries.

Also, the windows lib included in the distribution of dmd lacks 
the "version" import library, so I had to hand make it, but that 
should not be the case for a out-of-the-box-ready-compiler, so we 
should keep that in mind.

I am willing to help out but at the same time I am really not 
that savvy about Windows system. I will get as savvy as 
Programming Windows will get me though.

So far, I had to modify some code because windows functions 
should be marked as nothrow. Otherwise, they are to be placed in 
try catch blocks in a win-proc (which has to be nothrow I 
believe). So I adjusted those I used (but they usually are in 
"extern(Windows)" blocks so I just added "nothrow" to those, 
correcting a whole bunch of functions at the same time).

There will be some minor changes I think. Like removing the min 
and max templates or just implement them in an other way. See why:
current impl:
template max(T) {
	T max(T a, T b) {
		return a > b ? a : b;
	}
}

template min(T) {
	T min(T a, T b) {
                 return a < b ? a : b;
	}
}
Supposed to replace a macro, but no type inference make it a 
hassle to use (must say min!int( 1, 2 ) for example instead of 
just min(1,2). We could change it to type inferring functions, 
but that already has been done in std.algorithm, plus theirs is 
more powerful (variadic functions). This is just one example but 
I am guessing I will find others (and not all) through my 
experimentations on the Windows system.

I too believe that the whole win32 api headers should be included 
in the distribution, as well as well as any other system 
supported. Though, there could be some kind of package downloads 
to prevent the installation of unused headers. In any case, I 
think it would be nice if AT LEAST the installation platform's 
headers were all with the product. Others could be fetched on 
demand on this website for example.

Phil
Dec 27 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 27/12/2012 18:41, Phil Lavoie wrote:

 Hi,

 I am currently using the win32 api bindings project and things went
 rather smoothly in migrating my (not so big) code (so far). I love that
 pragmas are everywhere to make the compiler link to proper libraries.

 Also, the windows lib included in the distribution of dmd lacks the
 "version" import library, so I had to hand make it, but that should not
 be the case for a out-of-the-box-ready-compiler, so we should keep that
 in mind.


Yes, the .lib files that ship with DMD are out of date.  It's a known issue.
http://d.puremagic.com/issues/show_bug.cgi?id=6625


 I am willing to help out but at the same time I am really not that savvy
 about Windows system. I will get as savvy as Programming Windows will
 get me though.


OK.  Have you had a good look at the translation instructions? 
Downloaded the latest MinGW headers?  Got Subversion installed?  Let me 
know if you get stuck somewhere along the line.


 So far, I had to modify some code because windows functions should be
 marked as nothrow. Otherwise, they are to be placed in try catch blocks
 in a win-proc (which has to be nothrow I believe). So I adjusted those I
 used (but they usually are in "extern(Windows)" blocks so I just added
 "nothrow" to those, correcting a whole bunch of functions at the same
 time).


I guess most of us haven't been using the nothrow attribute much and so 
hadn't noticed it.  Good catch.

<snip>

 template min(T) {
      T min(T a, T b) {
                  return a < b ? a : b;
      }
 }
 Supposed to replace a macro, but no type inference make it a hassle to
 use (must say min!int( 1, 2 ) for example instead of just min(1,2).


<snip>

IFTI should work perfectly on these.  If it doesn't, you have a buggy 
compiler.  What compiler version are you using, and what error message 
do you get when you try using just min(1,2)?

Stewart.
Dec 27 2012
parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
Hi,

Sorry for the duplicate the forum did not seem to have processed 
my post so I made another one. I'm sorry I didn't mean TYPE 
INFERENCE did not work I meant that this:
int x
uint y;
min( x, y ) will not compile, you would have to rewrite it to 
min( x, cast( int )y ) for example, or min!int( x, y ). I am just 
saying that there is an implementation in std.algorithm that work 
right out of the box without such explicitness. In addition, it 
works with a variable amount of params ( z = min( a, b, c, d, e, 
..., y ) ), so I am just saying either we solicit the use of that 
one or implement it for two parameters :).

I'll let you know about how it goes with everything.

Phil
Dec 28 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/12/2012 13:38, Phil Lavoie wrote:

 Hi,

 Sorry for the duplicate the forum did not seem to have processed my post
 so I made another one. I'm sorry I didn't mean TYPE INFERENCE did not
 work I meant that this:
 int x
 uint y;
 min( x, y ) will not compile, you would have to rewrite it to min( x,
 cast( int )y ) for example, or min!int( x, y ).


You can't reliably compare signed and unsigned versions of the same type 
even under C, and D has the same problem
http://d.puremagic.com/issues/show_bug.cgi?id=259
http://d.puremagic.com/issues/show_bug.cgi?id=2205

So, while it would be trivial (and even a more faithful translation of 
the C macro) to change it to templatise the two parameters separately, 
it's probably for the better that it hasn't been done this way.


 I am just saying that
 there is an implementation in std.algorithm that work right out of the
 box without such explicitness. In addition, it works with a variable
 amount of params ( z = min( a, b, c, d, e, ..., y ) ), so I am just
 saying either we solicit the use of that one or implement it for two
 parameters :).


If std.algorithm.min always gives the correct result, then you're free 
to use that.  OTOH, those who don't need the extra power of the stuff in 
std.algorithm are free to use the one in the Windows bindings.

Stewart.
Dec 28 2012
parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
Yeah, sure, it's not a big problem, it's not even a problem. It's 
really just a matter of emulating the macro better, though using 
std.algorithm's might actually give the correct answer when the 
macro does not. I was just mentioning this as an example of 
possible things that could be discussed when merging with the 
druntime. I believe that there are going to be such small details 
that are going to be the subject of discussions, though it is 
really not a big deal in this case.

Cheers!

BTW: Thanks for having made this project, it is useful stuff.

Additional Question: Is there a reason why you use MingW's 
headers instead of VC? I am just wild guessing here, but aren't 
VC's most likely to be up to date?
Dec 28 2012
next sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Friday, 28 December 2012 at 18:54:40 UTC, Phil Lavoie wrote:

 Yeah, sure, it's not a big problem, it's not even a problem. 
 It's really just a matter of emulating the macro better, though 
 using std.algorithm's might actually give the correct answer 
 when the macro does not. I was just mentioning this as an 
 example of possible things that could be discussed when merging 
 with the druntime. I believe that there are going to be such 
 small details that are going to be the subject of discussions, 
 though it is really not a big deal in this case.

 Cheers!

 BTW: Thanks for having made this project, it is useful stuff.

 Additional Question: Is there a reason why you use MingW's 
 headers instead of VC? I am just wild guessing here, but aren't 
 VC's most likely to be up to date?


By VC I meant Visual Studio... not sure if I should have called 
it VS?
Dec 28 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/12/2012 18:54, Phil Lavoie wrote:
<snip>

 Additional Question: Is there a reason why you use MingW's headers
 instead of VC? I am just wild guessing here, but aren't VC's most likely
 to be up to date?


Copyright.  The MinGW headers are public domain.

Stewart.
Dec 28 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/12/2012 19:20, Stewart Gordon wrote:

 On 28/12/2012 18:54, Phil Lavoie wrote:
 <snip>

 Additional Question: Is there a reason why you use MingW's headers
 instead of VC? I am just wild guessing here, but aren't VC's most likely
 to be up to date?


 Copyright.  The MinGW headers are public domain.


On top of this, to use the headers from VS would require that somebody 
who is involved with the project has access to a version of VS that has 
the headers for the latest version of Windows, or at least access to 
said headers.  What's more, it would be more of a challenge to update 
our bindings when a new version comes out.

OTOH, anybody can download the MinGW headers for free, both the latest 
version and older versions in order to compare them and determine what 
changes need to be made to our bindings.

Stewart.
Dec 29 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/30/2012 3:20 AM, Stewart Gordon пишет:

 On 28/12/2012 19:20, Stewart Gordon wrote:

 On 28/12/2012 18:54, Phil Lavoie wrote:
 <snip>

 Additional Question: Is there a reason why you use MingW's headers
 instead of VC? I am just wild guessing here, but aren't VC's most likely
 to be up to date?


 Copyright.  The MinGW headers are public domain.


 On top of this, to use the headers from VS would require that somebody
 who is involved with the project has access to a version of VS that has
 the headers for the latest version of Windows, or at least access to
 said headers.  What's more, it would be more of a challenge to update
 our bindings when a new version comes out.


Platform SDK is free for anyone having Windows license. It includes 
relevant headers, libraries and build tools.

Copyright issues might be more critical though.


 OTOH, anybody can download the MinGW headers for free, both the latest
 version and older versions in order to compare them and determine what
 changes need to be made to our bindings.

 Stewart.



-- 
Dmitry Olshansky
Dec 30 2012
prev sibling next sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
Hi,

I am currently using the win32 api bindings project and the 
transition went smoothly. However, the "version" import library 
is not included in dmd's windows' libs, so we should have to keep 
that in mind, in order to provide a full out-of-the-box working 
installation.

I am willing to help but I am by no means a Windows savvy. Though 
I believe the book I am currently reading and my current project 
will take me a few steps ahead.

I have already modified some of the code provided. For example, 
no functions are declared "nothrow" in the provided headers. But 
I think they should. First of all, because they are, but also 
because if you want to call them in a win-proc (which HAS to be 
nothrow I believe) without using a try/catch block they have to 
be marked as such. So I just modify them as I use them. Though 
modifying one generally implies correcting a whole bunch (since 
only a "nothrow" clause has to be added to the "extern( Windows 
)" block...)

Also, I believe there are going to be some minor things that 
should be corrected. For exemple, the min and max templates 
provided as a substitute for their macro counterparts should be 
removed I believe. First of all because they are declared like 
this: template min( T ) { T min( T a, T b ) { ... } }, and this 
syntax does not allow for type inference on comparisons like ( 
int, uint ) without a cast or explicitly specifying the type, as 
such min!int( x, y ) (which of course, is not a problem when 
using a macro).

std.algorithm's already have more power min/max functions 
(variadic) so my take on this would be to use those instead, or 
implement a 2 parameter version of it for the windows header.

Cheers!

Phil
Dec 27 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, December 27, 2012 17:44:09 Stewart Gordon wrote:

 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?


I really don't remember. I recall that there were issues with ifdefs relating 
to version of Windows that you were targetting, but I don't know. I'm going off 
of fragmented memories here, because I do so little with Windows. If you're 
hip deep in the Windows API stuff as you seem to be, then you'd be far more 
familiar with the issues than I am. Just go off of what you know. My point is 
that there were problems that were discussed, and whatever problems exist with 
regards to merging the Windows API bindings into druntime need to be sorted 
out, whatever they may be. Folks who are actually familiar with that should be 
the ones to sort it out. I'm probably just confusing you by trying to discuss 
them at all.


 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?


I am referring to dmd, druntime, and Phobos. It was agreed upon by the Phobos 
devs in the newsgroup and/or in discussions in github pull requests, so it's 
essentially official, but we've never actually put it in the changelog or 
officially announced it in any way. I believe that it happened when we 
explicitly removed all of the Win9x support a while back.


 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....


That happens far too often around here. Plenty of folks have stuff that they 
want done, but too few people have the time, expertise, and/or willingness 
necessary to do it. I think that a lot of stuff gets done simply because 
someone gets sick of it not being done and buckles down and does it. And too 
many people are more likely to give up on it than do that.

- Jonathan M Davis
Dec 27 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 28/12/2012 04:57, Jonathan M Davis wrote:

 On Thursday, December 27, 2012 17:44:09 Stewart Gordon wrote:

 On 27/12/2012 13:52, Jonathan M Davis wrote:




<snip>

 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?


 I am referring to dmd, druntime, and Phobos. It was agreed upon by the Phobos
 devs in the newsgroup and/or in discussions in github pull requests, so it's
 essentially official, but we've never actually put it in the changelog or
 officially announced it in any way. I believe that it happened when we
 explicitly removed all of the Win9x support a while back.


<snip>

Thinking about it, we need to consider what third-party compiler vendors 
are going to do.  A standardised set of versions for all D compilers to 
use would be desirable.  Moreover, these third parties might want to use 
our bindings as well and thereby avoid duplication of effort.

But what is the oldest version of Windows we can reasonably expect 
anybody who writes a D2 compiler to want to support?  Getting rid of the 
Win9x support would simplify things considerably, but maybe we should 
still make Win2000 the default target version.  While it would seem 
silly to default to targeting a version that we officially don't 
support, it would make our bindings more portable and encourage Windows 
programmers to write portable code.  If that makes sense.

But this does suggest that, if nonetheless Walter decrees that the 
bindings distributed with DMD shall have XP as the minimum target 
version, meeting all of the objectives I've covered would mean creating 
a fork of the bindings project....

Stewart.
Dec 29 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 30, 2012 00:32:18 Stewart Gordon wrote:

 On 28/12/2012 04:57, Jonathan M Davis wrote:

 On Thursday, December 27, 2012 17:44:09 Stewart Gordon wrote:

 On 27/12/2012 13:52, Jonathan M Davis wrote:




 <snip>
 

 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?


 
 I am referring to dmd, druntime, and Phobos. It was agreed upon by the
 Phobos devs in the newsgroup and/or in discussions in github pull
 requests, so it's essentially official, but we've never actually put it
 in the changelog or officially announced it in any way. I believe that it
 happened when we explicitly removed all of the Win9x support a while
 back.


 
 <snip>
 
 Thinking about it, we need to consider what third-party compiler vendors
 are going to do.  A standardised set of versions for all D compilers to
 use would be desirable.  Moreover, these third parties might want to use
 our bindings as well and thereby avoid duplication of effort.


Third parties would typically take druntime and make whatever minimal tweaks 
they need to make it work with their stuff. That's what gdc and ldc do.


 But what is the oldest version of Windows we can reasonably expect
 anybody who writes a D2 compiler to want to support?  Getting rid of the
 Win9x support would simplify things considerably, but maybe we should
 still make Win2000 the default target version.  While it would seem
 silly to default to targeting a version that we officially don't
 support, it would make our bindings more portable and encourage Windows
 programmers to write portable code.  If that makes sense.
 
 But this does suggest that, if nonetheless Walter decrees that the
 bindings distributed with DMD shall have XP as the minimum target
 version, meeting all of the objectives I've covered would mean creating
 a fork of the bindings project....


We specifically decided not to support Win2K. It requires extra effort that we 
don't want to go to, and almost no one uses it anymore. XP isn't even going to 
be supported by Microsoft for all that much longer. I think that it's just 
asking for trouble to try and support anything older than XP. It's extra effort 
for little-to-no gain. I don't know why you'd bother. And IIRC, Phobos already 
uses at least one function which does not exist in Win2K. So, while you can 
certainly make it all work on older versions of Windows if you really want to, 
you're fighting an uphill battle. I would expect any bindings added to druntime 
to be done with the idea that they're for XP or newer rather than trying to 
support pre-XP at all.

- Jonathan M Davis
Dec 29 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/12/2012 00:49, Jonathan M Davis wrote:
<snip>

 Third parties would typically take druntime and make whatever
 minimal tweaks they need to make it work with their stuff. That's
 what gdc and ldc do.


All the more reason to keep the Win2000 support in, in case one of these 
third parties wants it.

<snip>

 We specifically decided not to support Win2K. It requires extra
 effort that we don't want to go to, and almost no one uses it
 anymore.


What extra effort is that?  The versioning to support Win2000 (and even 
NT4) is already in both the C headers and the D modules that have so far 
been done.  It's just another value of the constant _WIN32_WINNT.  My 
common sense tells me that it is _removing_ it that requires extra effort.

<snip>

 I would expect any bindings added to druntime to be done with the
 idea that they're for XP or newer rather than trying to support
 pre-XP at all.


Once each file has been translated, why would any further bindings for 
WinXP, let alone any older version, be later added?

Stewart.
Dec 30 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 30, 2012 18:33:01 Stewart Gordon wrote:

 On 30/12/2012 00:49, Jonathan M Davis wrote:
 <snip>
 

 Third parties would typically take druntime and make whatever
 minimal tweaks they need to make it work with their stuff. That's
 what gdc and ldc do.


 
 All the more reason to keep the Win2000 support in, in case one of these
 third parties wants it.


They're on their own if they want that. We're not supporting it, and since 
Microsoft hasn't supported it for years, I expect that very few people are 
going to care about it.


 We specifically decided not to support Win2K. It requires extra
 effort that we don't want to go to, and almost no one uses it
 anymore.


 
 What extra effort is that?  The versioning to support Win2000 (and even
 NT4) is already in both the C headers and the D modules that have so far
 been done.  It's just another value of the constant _WIN32_WINNT.  My
 common sense tells me that it is _removing_ it that requires extra effort.


There's stuff in druntime that doesn't work on Win2K right now. For instance, 
per this bug report, the stack trace stuff doesn't work on Win2K:

http://d.puremagic.com/issues/show_bug.cgi?id=6024

The solution was to drop Win2K support (the bug is still open, because it's 
asking that we make an official announcement about it, which we haven't done
yet 
and really should have).


 I would expect any bindings added to druntime to be done with the
 idea that they're for XP or newer rather than trying to support
 pre-XP at all.


 
 Once each file has been translated, why would any further bindings for
 WinXP, let alone any older version, be later added?


I don't follow.

I'd expect that druntime contain the function declarations for the entire 
Windows system API which is supported with XP with no care whatsoever to what 
was or wasn't supported before XP (because we're not supporting anything prior 
to XP). If those functions happened to be on Win2k, then fine, but it doesn't 
matter one way or the other, because we don't suppport it. Newer functions 
that are not in XP would then presumably be added in a way which they're only 
there if you've defined the right version to enable them (e.g. a version 
identifier indicating Vista would enable all of the functions added in Vista).

In general, older versions of Windows may work, but we're not making any effort 
to make them work (_especially_ if that means doing stuff like checking the 
Windows version number or creating different code branches for them as used to 
be the case in std.file to deal with the lack of W functions in Win9x), and 
we're not adding any code to target them or help them. They work as long as 
they work with the stuff targeting the currently supported versions of Windows.

I suppose that you can add Win2K bindings to druntime if you really want to go 
to that extra effort, but only if it's not going to complicate things. And 
we're not supporting anything related to Win2K, so any bindings which are 2k-
specific are just icing on the cake. druntime and Phobos themselves will not be 
making any attempt to support Win2K, and no bug reports related to Win2K are 
likely to be considered valid.

Whenever we drop XP support (which is obviously a ways off), that may or may 
not involve removing stuff related to XP. For the most part, it'll probably 
just be left there, but if it's causing problems for something (e.g. like was 
happening with std.file and Win9x), then it probably will be removed. If it 
doesn't harm anything to leave it there, then it's generally better to just 
leave it there, but just like with 2K now, at that point, XP won't be a 
concern anymore. If it happens to work, then great, but we won't put any effort 
into making it work, and we may do things that make it not work if it improves 
the situation for stuff that we actually support at that point in time.

- Jonathan M Davis
Dec 30 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/12/2012 22:27, Jonathan M Davis wrote:

 On Sunday, December 30, 2012 18:33:01 Stewart Gordon wrote:

 On 30/12/2012 00:49, Jonathan M Davis wrote:




<snip>

 We specifically decided not to support Win2K. It requires extra
 effort that we don't want to go to, and almost no one uses it
 anymore.


 What extra effort is that?  The versioning to support Win2000 (and even
 NT4) is already in both the C headers and the D modules that have so far
 been done.  It's just another value of the constant _WIN32_WINNT.  My
 common sense tells me that it is _removing_ it that requires extra effort.


 There's stuff in druntime that doesn't work on Win2K right now.


Your comment was posted as a reply to my statement that was about the 
Windows API bindings, not anything that is already in druntime.  As 
such, what you ended up saying was that we would need to go to some 
extra effort to have Win2K-compatible Windows API bindings.  So that 
isn't what you meant to say.  I see now.


 For instance,
 per this bug report, the stack trace stuff doesn't work on Win2K:

 http://d.puremagic.com/issues/show_bug.cgi?id=6024


It was me that mentioned this to you actually.  Besides, it claims 
something far more serious, that compiled programs don't work at all on 
Win2K.  Is it wrong or OOD in this respect?

But as you seem to be saying later on, whether we're going to fix it to 
work again on Win2K and whether Walter's going to make us remove the 9x 
vs. NT4 vs. 2K vs. XP versioning from the Windows API bindings before 
allowing them to be dropped in are two different matters.

Though I am inclined to remove the versioning for 9x, considering that

- doing so would simplify the versioning quite a bit
- character sets under Win9x are a PITA, especially in a language where 
you're meant to use only Unicode
- some of it seems wrong anyway, in such matters as which W functions 
are supported

<snip>

 I'd expect that druntime contain the function declarations for the entire
 Windows system API which is supported with XP with no care whatsoever to what
 was or wasn't supported before XP (because we're not supporting anything prior
 to XP). If those functions happened to be on Win2k, then fine, but it doesn't
 matter one way or the other, because we don't suppport it. Newer functions
 that are not in XP would then presumably be added in a way which they're only
 there if you've defined the right version to enable them (e.g. a version
 identifier indicating Vista would enable all of the functions added in Vista).


So you think the view Walter will take is that, if somebody wants to 
build a WinXP app (which may have been written by a DMD user) with a D 
compiler that happens to support Win2K, it's that somebody's 
responsibility to make sure -version=WindowsXP (or the equivalent switch 
for that compiler) has been set.

<snip>

 I suppose that you can add Win2K bindings to druntime if you really want to go
 to that extra effort, but only if it's not going to complicate things. And
 we're not supporting anything related to Win2K, so any bindings which are 2k-
 specific are just icing on the cake.


Are there APIs that have been removed in XP?  I wasn't thinking about 
those ... and don't even know how the MS or MinGW C headers would deal 
with such a scenario.

Stewart.
Dec 30 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 31, 2012 01:41:38 Stewart Gordon wrote:

 Your comment was posted as a reply to my statement that was about the
 Windows API bindings, not anything that is already in druntime.  As
 such, what you ended up saying was that we would need to go to some
 extra effort to have Win2K-compatible Windows API bindings.  So that
 isn't what you meant to say.  I see now.


I really don't know what the state of the Windows API project's bindings are. 
I'm just talking about what we want to be doing with druntime, though 
obviously taking the bindings from the Windows API project is a great time 
saver, and as I understand it, that was pretty much the point of the project 
in the first place. I may not have been clear on that point.


 For instance,
 per this bug report, the stack trace stuff doesn't work on Win2K:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=6024


 
 It was me that mentioned this to you actually.  Besides, it claims
 something far more serious, that compiled programs don't work at all on
 Win2K.  Is it wrong or OOD in this respect?


I have no idea what the current state of Win2K and dmd, druntime, or Phobos 
is. I know that std.datetime uses a function that doesn't exist in Win2K, and 
I know that that bug report was indicating problems with Win2K and stack 
traces, but I have no idea what the exact state of Win2K is with regards to 
running D programs.


 But as you seem to be saying later on, whether we're going to fix it to
 work again on Win2K and whether Walter's going to make us remove the 9x
 vs. NT4 vs. 2K vs. XP versioning from the Windows API bindings before
 allowing them to be dropped in are two different matters.


I'd say that they're different matters. We don't support pre-XP at this point, 
but that doesn't mean that we can't provide the bindings to C functions for 
them. I'd be generally inclined not to bother though.

I think that Walter may have argued for not providing the A functions on the 
basis that they shouldn't be used, but I'd have to go digging through the 
archives to be sure. Regardless, that's still a bindings issue rather than 
whether we go to the effort of making anything pre-XP actually, properly work 
with D programs or not.


 Though I am inclined to remove the versioning for 9x, considering that
 
 - doing so would simplify the versioning quite a bit
 - character sets under Win9x are a PITA, especially in a language where
 you're meant to use only Unicode
 - some of it seems wrong anyway, in such matters as which W functions
 are supported


Supporting Win9x is far worse than supporting Win2K. Win2K is at least close 
to XP. In either case, I wouldn't really expect people to be writing D 
programs for them. D's too new for there to be any legacy stuff using D with 
those systems, and I wouldn't expect anyone to be using them for anything 
other than legacy stuff. I see no problem whatsoever with dropping any bindings 
that are specific to anything pre-XP. In fact, it would probably be far better 
to, since then there's less clutter to deal with in druntime.


 So you think the view Walter will take is that, if somebody wants to
 build a WinXP app (which may have been written by a DMD user) with a D
 compiler that happens to support Win2K, it's that somebody's
 responsibility to make sure -version=WindowsXP (or the equivalent switch
 for that compiler) has been set.


If someone is using another D compiler, then it's between them and that 
compiler vendor as to what the compiler does or what their version of druntime 
does. At this point, dmd, druntime, and Phobos only support XP and newer. So, 
I'd expect the Windows bindings in druntime to default to whatever is 
appropriate for that. If someone wants to target an older version of Windows, 
it's up to them to deal with that, since it's unsupported. If someone wants to 
target a newer version of Windows, then presumably they'd either just target 
XP and let it work on the newer version, or they'd have to compile with the 
appropriate version identifier to make druntime target the version that they 
wanted to target.

AFAIK, Walter has no reason to disagree with that assessment, but I don't know 
what he'll say until he says it.


 I suppose that you can add Win2K bindings to druntime if you really want
 to go to that extra effort, but only if it's not going to complicate
 things. And we're not supporting anything related to Win2K, so any
 bindings which are 2k- specific are just icing on the cake.


 
 Are there APIs that have been removed in XP?  I wasn't thinking about
 those ... and don't even know how the MS or MinGW C headers would deal
 with such a scenario.


I have no idea. I suspect not. Microsoft normally adds stuff rather than 
removing it. But my point is that it doesn't really matter what the deal with 
Win2K is, because we're not supporting it. If it happens to work, great. But 
if it doesn't, oh well. We're not planning to put in extra effort to make it 
work, and we may do things that break it (probably mostly by using functions 
that don't exist on Win2K).

- Jonathan M Davis
Dec 30 2012
prev sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
Hi Stewart,

I read the notes on the page of the win32 project. I looked at 
your request for first assigning a module to one's self before 
starting to work on it and I did not find any way to do so.

I thought maybe I had to be logged in on the site, so I created 
an account but when I log in it just redirects me to a blank 
page...

Also, in order to work on this specific project, should I check 
out all the bindings or only win32 from the trunk.

What is the dev process? Should I just check out stuff and commit 
changes like that?

Is there another channel where we can discuss this?

Phil
Jan 03 2013
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 26 2012