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