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