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

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

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.

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

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

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.

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?

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?

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.

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.