www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows API headers again

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
We've talked about it quite a bit, but not got far.  Has anyone actually 
undertaken the task of translating the Windows API headers into D?

If not, I hereby propose we get started on it now!  We can do this as a 
team effort, with each member translating one or more of the Windows .h 
files.  I suggest we proceed as follows:

1. Decide on some rules.  I have some ideas for rules, as well as a few 
open issues in this respect, which I'll post a bit later (assuming I'm 
going to get some interest in this project).

2. Set up a page on Wiki4D for the project, which would enable 
individuals to 'take' individual modules that they're going to work on.

3. Find somewhere to keep the translated modules for the time being. 
Maybe dsource?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 28 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Stewart Gordon wrote:
 We've talked about it quite a bit, but not got far.  Has anyone actually 
 undertaken the task of translating the Windows API headers into D?
 
 If not, I hereby propose we get started on it now!  We can do this as a 
 team effort, with each member translating one or more of the Windows .h 
 files.  I suggest we proceed as follows:
 
 1. Decide on some rules.  I have some ideas for rules, as well as a few 
 open issues in this respect, which I'll post a bit later (assuming I'm 
 going to get some interest in this project).
 
 2. Set up a page on Wiki4D for the project, which would enable 
 individuals to 'take' individual modules that they're going to work on.
 
 3. Find somewhere to keep the translated modules for the time being. 
 Maybe dsource?
 
 Stewart.
 
Can't we just resort to a tool like h2d?
Jan 28 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
zwang wrote:
<snip excessive quote>
 Can't we just resort to a tool like h2d?
Oh, I hadn't realised that someone had actually undertaken to write h2d. It must've slipped through my reading. In any case, I doubt we can *just* resort to it. We'd need to deal with the FIXME comments, and the output could probably do with some tidying anyway. That's before you consider the other possible inadequacies of such a tool.... Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jan 28 2005
prev sibling parent reply Vathix <vathix dprogramming.com> writes:
 Can't we just resort to a tool like h2d?
But wouldn't the output be owned by Microsoft still and we'd need their permission to distribute it?
Jan 28 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Vathix" <vathix dprogramming.com> wrote in message 
news:opslbh4lsfkcck4r esi...
 Can't we just resort to a tool like h2d?
But wouldn't the output be owned by Microsoft still and we'd need their permission to distribute it?
I've been wondering about that, too. The header file for winuser.h says "all rights reserved". So does that mean we can or can't run it through a translator and distribute the result? I don't know. IANAL but by reserving all rights and not saying we can do anything I take it that means we can't do anything without their permission. I've never liked putting restrictions on header files - it seems counter-productive. -Ben
Jan 28 2005
parent bobef <bobef_member pathlink.com> writes:
What about mingw headers?

In article <ctdkid$2p5o$1 digitaldaemon.com>, Ben Hinkle says...
"Vathix" <vathix dprogramming.com> wrote in message 
news:opslbh4lsfkcck4r esi...
 Can't we just resort to a tool like h2d?
But wouldn't the output be owned by Microsoft still and we'd need their permission to distribute it?
I've been wondering about that, too. The header file for winuser.h says "all rights reserved". So does that mean we can or can't run it through a translator and distribute the result? I don't know. IANAL but by reserving all rights and not saying we can do anything I take it that means we can't do anything without their permission. I've never liked putting restrictions on header files - it seems counter-productive. -Ben
Jan 28 2005
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <opslbh4lsfkcck4r esi>, Vathix says...
 Can't we just resort to a tool like h2d?
But wouldn't the output be owned by Microsoft still and we'd need their permission to distribute it?
I think you're right, but we should be able to get around that by using MinGW's (http://www.mingw.org/) public domain headers for Windows. We've discussed this earlier at dsource, but I haven't gotten around to doing jcc7
Jan 28 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
We've talked about it quite a bit, but not got far.  Has anyone actually 
undertaken the task of translating the Windows API headers into D?
Yes. More than one person, in fact. For example: http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
If not, I hereby propose we get started on it now!  We can do this as a 
team effort, with each member translating one or more of the Windows .h 
files.  I suggest we proceed as follows:

1. Decide on some rules.  I have some ideas for rules, as well as a few 
open issues in this respect, which I'll post a bit later (assuming I'm 
going to get some interest in this project).
I've heard there's some header-to-D programs out there. We should probably make use of some of those.
2. Set up a page on Wiki4D for the project, which would enable 
individuals to 'take' individual modules that they're going to work on.

3. Find somewhere to keep the translated modules for the time being. 
Maybe dsource?
Kind of like http://www.dsource.org/projects/core32/?
Stewart.
jcc7
Jan 28 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
3. Find somewhere to keep the translated modules for the time being.
Maybe dsource?
Kind of like http://www.dsource.org/projects/core32/?
What's the state of that project? I think it makes sense to try to make that one the "standard". -Ben
Jan 28 2005
parent J C Calvarese <jcc7 cox.net> writes:
In article <ctdhkt$2lf3$1 digitaldaemon.com>, Ben Hinkle says...
3. Find somewhere to keep the translated modules for the time being.
Maybe dsource?
Kind of like http://www.dsource.org/projects/core32/?
What's the state of that project? I think it makes sense to try to make that one the "standard". -Ben
Last time that I checked, everything compiles, and it works as far as I know. Mike Wynn (ak/a One_mad_alien, a/k/a l8night) started the project and has done the vast majority of the work. I haven't heard from in the a while. It's possible he's lost interest in D or just doesn't have the time to play with it. I've become the maintainer of the Core32 and L8night (GUI library) projects, so I can fix what's easy to fix. I haven't done much. A little change to get it to compile here, a little change to prevent a conflict with Phobos's Windows headers here. Not much. Not all of the headers have been converted, but I think the most popular ones are there. There might be a problem with copyright issues though. I suspect the files were directly converted from Microsoft's headers. The only way to eliminate this problem for sure would be to start over from scratch. (What fun!) We might be able get pretty far by running MinGW's (http://www.mingw.org/) public domain headers through H2D-type program. I might be able to help out someone else a little, but I don't really have time to redo the whole project presently. jcc7
Jan 28 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
J C Calvarese wrote:
 In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
 
 We've talked about it quite a bit, but not got far.  Has anyone actually 
 undertaken the task of translating the Windows API headers into D?
Yes. More than one person, in fact. For example: http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
Just looking at it (with the aid of Google's translator): 1. It's been compressed in an obscure format I'll have to investigate. And then evaluate it once that's done. 2. Does anyone have any guesses of what the W and A columns mean? 3. What's with some of them being labelled as "Never"? Are they beyond the scope of this particular project just because they're not in the include tree from windows.h? <snip>
 Kind of like http://www.dsource.org/projects/core32/?
Just looked at this one. Not bad, but I guess it could be cleaned up a bit. And why is the WNDPROC definition commented out? And what is version(STANDALONE) about? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jan 28 2005
next sibling parent J C Calvarese <jcc7 cox.net> writes:
In article <ctdk6d$2ols$1 digitaldaemon.com>, Stewart Gordon says...
J C Calvarese wrote:
 In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
 
 We've talked about it quite a bit, but not got far.  Has anyone actually 
 undertaken the task of translating the Windows API headers into D?
Yes. More than one person, in fact. For example: http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
Just looking at it (with the aid of Google's translator): 1. It's been compressed in an obscure format I'll have to investigate. And then evaluate it once that's done.
I guess he's still using 7-Zip (http://www.7-zip.org/) for archiving. I use it all the time (they compress pretty well), but I usually don't upload it to websites.
2. Does anyone have any guesses of what the W and A columns mean?
I think it's something like Wide (2-byte UNICODE) and ANSI (or ASCII?). I've never quite understood that convention.
3. What's with some of them being labelled as "Never"?  Are they beyond 
the scope of this particular project just because they're not in the 
include tree from windows.h?
I don't think he plans on converting everything. "Never" would be a file he doesn't want to convert.
<snip>
 Kind of like http://www.dsource.org/projects/core32/?
Just looked at this one. Not bad, but I guess it could be cleaned up a bit. And why is the WNDPROC definition commented out? And what is version(STANDALONE) about?
These are some very tedious files. They can always be cleaned up a bit. Ad infinitum. I don't know about the WNDPROC issue. It was probably commented out for a reason. I'm sure it can be commented back in (but it should probably be versioned out then). Someone would compile with version(STANDALONE) if they don't want to import std.c.windows.windows. The default (compiling without STANDALONE set) has many of the conflicts with Phobos versioned out. (When I find a conflict, I go into the code and add a version(STANDALONE).)
Stewart.
jcc7
Jan 28 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
I use these headers all the time with very few problems. They're far more complete than the windows header that comes with D, and at the most, they only need to be updated to add in some casts where needed and whatnot.
Jan 28 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
J C Calvarese wrote:
<snip>
 For example:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
<snip> I finally got around to checking this out over the weekend. It seems a decent effort, but I noticed a few quirks: 1. It's far from complete, if the DMC collection of Windows headers is anything to go by. 2. There are many enum blocks defining just a single constant. How about grouping these by what set of constants they belong to? 3. State-of-the-art as the compression algorithm may be, the download could've been made even smaller if it weren't for the amount of commented-out C code and the complete duplication for ANSI and Unicode versions (was there any problem with using a version block for this?) 4. String constants are defined twice, in direct mimic of the C headers. Where we have const char[] WC_TREEVIEWA = "SysTreeView32"; const wchar[] WC_TREEVIEWW = "SysTreeView32"; alias WC_TREEVIEWA WC_TREEVIEW; it can be reduced to const TCHAR[] WC_TREEVIEW = "SysTreeView32"; Strangely, this shorter form has been used one-off for DRAGLISTMSGSTRING. All this duplication does is enables both forms of CreateWindow(Ex) to be called in the course of a program using these constants. But is there any real point in doing this? And even if you do want to mix the forms, can't you just use the string literals directly? (On second thoughts, would this be portable to Win64?) OTOH, I can't see any point in mixing the A and W forms of RegisterWindowMessage, and so constants of this sort (of which there are several in commdlg) certainly might as well be defined just once. 5. Many structs have their own size as the first member. How about using member initialisers here? The only limitation is that one'll have to be careful if switching between Windows header translations. But once we have a translation incorporated into Phobos, this'll pretty much become irrelevant. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 28 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>
 I finally got around to checking this out over the weekend.  It seems a 
 decent effort, but I noticed a few quirks:
<snip> 6. I noticed a function IsEqualGUID. This didn't seem to exist in the standard Windows API when I looked at the files on my machine, but the MSDN site claims it exists. The translation implements this function from scratch, effectively viewing the structure as a uint[4] and comparing the uints one by one. If we really need to reimplement a function that's redundant with D's built in == on structs, why not implement it in terms of this? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 28 2005
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
One thing I don't like with these ports of the Windows SDK headers is the 
many aliases for basic types - eg, typedef long LONG, typedef LONG LONG_PTR, 
typedef LONG_PTR LRESULT. Not only does it look ugly (all those caps 
screaming off the screen), it's also confusing and misleading in D. It may 
be fine in C/C++ -- many of these are a hangover from the 16-bit days when 
WPARAM was an unsigned short (I think) or WORD, so the "W" made sense, but 
it's an unsigned int now. Even worse, LRESULT is a 32-bit long in C (hence 
the "L" prefix) but a long is 64 bits in D.

There are already plenty of basic types in D to remember, so why add this 
layer of obfuscation? I also note that the D style guide 
(http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
said, the header translations in Phobos ignore the guideline.

Which is more readable/understandable?

    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
wParam, LPARAM lParam)

or

    typedef void* Handle = (void*)0; // a typedef, but a useful one
    extern (Windows) int windowCallback(Handle handle, uint message, uint 
param1, int param2)

(Another thing: how I wish we could wrap callbacks in delegates without 
proxy classes.)

John.

"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:cvv081$2gpf$1 digitaldaemon.com...
J C Calvarese wrote:
 <snip>
 For example:
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
<snip> I finally got around to checking this out over the weekend. It seems a decent effort, but I noticed a few quirks: 1. It's far from complete, if the DMC collection of Windows headers is anything to go by. 2. There are many enum blocks defining just a single constant. How about grouping these by what set of constants they belong to? 3. State-of-the-art as the compression algorithm may be, the download could've been made even smaller if it weren't for the amount of commented-out C code and the complete duplication for ANSI and Unicode versions (was there any problem with using a version block for this?) 4. String constants are defined twice, in direct mimic of the C headers. Where we have const char[] WC_TREEVIEWA = "SysTreeView32"; const wchar[] WC_TREEVIEWW = "SysTreeView32"; alias WC_TREEVIEWA WC_TREEVIEW; it can be reduced to const TCHAR[] WC_TREEVIEW = "SysTreeView32"; Strangely, this shorter form has been used one-off for DRAGLISTMSGSTRING. All this duplication does is enables both forms of CreateWindow(Ex) to be called in the course of a program using these constants. But is there any real point in doing this? And even if you do want to mix the forms, can't you just use the string literals directly? (On second thoughts, would this be portable to Win64?) OTOH, I can't see any point in mixing the A and W forms of RegisterWindowMessage, and so constants of this sort (of which there are several in commdlg) certainly might as well be defined just once. 5. Many structs have their own size as the first member. How about using member initialisers here? The only limitation is that one'll have to be careful if switching between Windows header translations. But once we have a translation incorporated into Phobos, this'll pretty much become irrelevant. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 28 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
John C wrote:
 One thing I don't like with these ports of the Windows SDK headers is the 
 many aliases for basic types - eg, typedef long LONG, typedef LONG LONG_PTR, 
 typedef LONG_PTR LRESULT. Not only does it look ugly (all those caps 
 screaming off the screen), it's also confusing and misleading in D. It may 
 be fine in C/C++ -- many of these are a hangover from the 16-bit days when 
 WPARAM was an unsigned short (I think) or WORD, so the "W" made sense, but 
 it's an unsigned int now. Even worse, LRESULT is a 32-bit long in C (hence 
 the "L" prefix) but a long is 64 bits in D.
Yes, I'm made to wonder why the Windows API needs so many meaningless type aliases. My guess is that M$ was trying to come up with a cross-language set of type names.
 There are already plenty of basic types in D to remember, so why add this 
 layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
 said, the header translations in Phobos ignore the guideline.
Indeed. I did mention this briefly (see my reply to Mark T on this thread), but there was no comment. I'm inclined to agree - we D programmers are comfortable with D type names, so we should use them. I use D type names rather than these aliases throughout SDWF.
 Which is more readable/understandable?
 
     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)
 
 or
 
     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)
I think we both agree on this.
 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)
<snip top of upside-down reply> What do you mean by this? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Feb 28 2005
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:cvvl9a$776$1 digitaldaemon.com...
 John C wrote:
 One thing I don't like with these ports of the Windows SDK headers is the 
 many aliases for basic types - eg, typedef long LONG, typedef LONG 
 LONG_PTR, typedef LONG_PTR LRESULT. Not only does it look ugly (all those 
 caps screaming off the screen), it's also confusing and misleading in D. 
 It may be fine in C/C++ -- many of these are a hangover from the 16-bit 
 days when WPARAM was an unsigned short (I think) or WORD, so the "W" made 
 sense, but it's an unsigned int now. Even worse, LRESULT is a 32-bit long 
 in C (hence the "L" prefix) but a long is 64 bits in D.
Yes, I'm made to wonder why the Windows API needs so many meaningless type aliases. My guess is that M$ was trying to come up with a cross-language set of type names.
 There are already plenty of basic types in D to remember, so why add this 
 layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
 said, the header translations in Phobos ignore the guideline.
Indeed. I did mention this briefly (see my reply to Mark T on this thread), but there was no comment. I'm inclined to agree - we D programmers are comfortable with D type names, so we should use them. I use D type names rather than these aliases throughout SDWF.
 Which is more readable/understandable?

     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

 or

     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)
I think we both agree on this.
 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)
<snip top of upside-down reply> What do you mean by this?
Simply that there were some way for function pointers (including those requiring an extern attribute, such as callbacks) and delegates to be used interchangably. The workaround I've adopted is to encapsulate both the callback and the delegate in a template class. I'm not sure it's a good design, since the delegate needs to be static, so perhaps it can be improved upon: class Callback(R, T1, T2, T3, T4) { private alias R delegate(T1, T2, T3, T4) Method; private extern (Windows) alias R function(T1, T2, T3, T4) Function; public this(Method method) { method_ = method; } public Function opCast() { return &callback; } public static extern (Windows) R callback(T1 arg1, T2 arg2, T3 arg3, T4 arg4) { return method_(arg1, arg2, arg3, arg4); } private static Method method_; }; alias Callback!(int, Handle, uint, uint, int) WndProc; class Control { void registerClass() { WNDCLASS wc; wc.lpfnWndProc = (WNDPROC)(new WndProc(&windowProc)); } private int windowProc(Handle handle, uint message, uint param1, int param2) { // Now I have access to the class's non-static members. Hurrah. ... } }
Feb 28 2005
next sibling parent "John C" <johnch_atms hotmail.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message 
news:cvvnj1$9ic$1 digitaldaemon.com...
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:cvvl9a$776$1 digitaldaemon.com...
 John C wrote:
 One thing I don't like with these ports of the Windows SDK headers is 
 the many aliases for basic types - eg, typedef long LONG, typedef LONG 
 LONG_PTR, typedef LONG_PTR LRESULT. Not only does it look ugly (all 
 those caps screaming off the screen), it's also confusing and misleading 
 in D. It may be fine in C/C++ -- many of these are a hangover from the 
 16-bit days when WPARAM was an unsigned short (I think) or WORD, so the 
 "W" made sense, but it's an unsigned int now. Even worse, LRESULT is a 
 32-bit long in C (hence the "L" prefix) but a long is 64 bits in D.
Yes, I'm made to wonder why the Windows API needs so many meaningless type aliases. My guess is that M$ was trying to come up with a cross-language set of type names.
 There are already plenty of basic types in D to remember, so why add 
 this layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; 
 that said, the header translations in Phobos ignore the guideline.
Indeed. I did mention this briefly (see my reply to Mark T on this thread), but there was no comment. I'm inclined to agree - we D programmers are comfortable with D type names, so we should use them. I use D type names rather than these aliases throughout SDWF.
 Which is more readable/understandable?

     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

 or

     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, 
 uint param1, int param2)
I think we both agree on this.
 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)
<snip top of upside-down reply> What do you mean by this?
Simply that there were some way for function pointers (including those requiring an extern attribute, such as callbacks) and delegates to be used interchangably. The workaround I've adopted is to encapsulate both the callback and the delegate in a template class. I'm not sure it's a good design, since the delegate needs to be static, so perhaps it can be improved upon: class Callback(R, T1, T2, T3, T4) { private alias R delegate(T1, T2, T3, T4) Method; private extern (Windows) alias R function(T1, T2, T3, T4) Function; public this(Method method) { method_ = method; } public Function opCast() { return &callback; } public static extern (Windows) R callback(T1 arg1, T2 arg2, T3 arg3, T4 arg4) { return method_(arg1, arg2, arg3, arg4); } private static Method method_; }; alias Callback!(int, Handle, uint, uint, int) WndProc; class Control { void registerClass() { WNDCLASS wc; wc.lpfnWndProc = (WNDPROC)(new WndProc(&windowProc)); } private int windowProc(Handle handle, uint message, uint param1, int param2) { // Now I have access to the class's non-static members. Hurrah. ... } }
Talking of templates, I'd love to be able to use an alternative syntax for specifying arguments: // C++ version, separates out return type and function arguments typedef Callback<int (Handle, uint, uint, int)> WndProc; // possible D version, although looks unweildy alias Callback!(int (Handle, uint, uint, int)) WndProc;
Feb 28 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
John C wrote:
<snip>
 (Another thing: how I wish we could wrap callbacks in delegates without 
 proxy classes.)
<snip top of upside-down reply> What do you mean by this?
Simply that there were some way for function pointers (including those requiring an extern attribute, such as callbacks) and delegates to be used interchangably. The workaround I've adopted is to encapsulate both the callback and the delegate in a template class. I'm not sure it's a good design, since the delegate needs to be static, so perhaps it can be improved upon:
<snip> The problem is that a delegate consists of two pieces of information: the function pointer and the 'this' pointer. C-based APIs such as the Windows API cannot use delegates, at least directly. To pass in a delegate where a function pointer is expected would mean losing the 'this' pointer, and consequently the external API cannot call the function. Your hack would work only if throughout your program, you use only one delegate per function signature as a callback. But if that's so, there's a simpler hack still: have a global variable referencing the object on which it is called, and define a function that simply calls that method of this object. This approach also makes it possible to do a small, defined number of delegates with the same signature. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 01 2005
prev sibling parent reply "Rob Grainger" <nospam nospam.com> writes:
Hi folks,

As a D newbie, but experience Windows developer, I though these comments may 
be worth considering...

 One thing I don't like with these ports of the Windows SDK headers is the 
 many aliases for basic types - eg, typedef long LONG, typedef LONG 
 LONG_PTR, typedef LONG_PTR LRESULT. Not only does it look ugly (all those 
 caps screaming off the screen), it's also confusing and misleading in D. 
 It may be fine in C/C++ -- many of these are a hangover from the 16-bit 
 days when WPARAM was an unsigned short (I think) or WORD, so the "W" made 
 sense, but it's an unsigned int now. Even worse, LRESULT is a 32-bit long 
 in C (hence the "L" prefix) but a long is 64 bits in D.
Here, there is actually a semantic difference. A LONG is a 32-bit value, easy enough. LONG_PTR however was introduced with Win64 and varies to be a 32-bit or 64-bit number depending on platform, basically a LONG that is guaranteed big enough to hold a pointer. Allowing for the fact that API styles frequently require you to pass a pointer as a LPARAM-type value (also pointer-sized), this makes a lot of sense actually
 Yes, I'm made to wonder why the Windows API needs so many meaningless type 
 aliases.  My guess is that M$ was trying to come up with a cross-language 
 set of type names.
Again, the purpose here is not to be cross-language (these kind of names never made an appearance in VB), but to support C compilers where the basic types have different sizes (a rare occurence on Windows, but theoretically possible) - all such a compiler-vendor would need to do is define a few thousand typedef's appropiately (that was sarcasm).
 There are already plenty of basic types in D to remember, so why add this 
 layer of obfuscation? I also note that the D style guide 
 (http://www.digitalmars.com/d/dstyle.html) discourages the practice; that 
 said, the header translations in Phobos ignore the guideline.
Indeed. I did mention this briefly (see my reply to Mark T on this thread), but there was no comment. I'm inclined to agree - we D programmers are comfortable with D type names, so we should use them. I use D type names rather than these aliases throughout SDWF.
Must confess, I'm new to D, and so far impressed with what I see. However, I am definintely not new to Windows API programming, been doing that since Windows 2.0, and from that perspective having the Windows typenames available makes a lot of sense - otherwise you end in the VB scenario of looking up something in the platform API, working what 'D' type to use for the appropriate function - I'd much prefer a predictable mapping.
 Which is more readable/understandable?

     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

 or

     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)
I think we both agree on this.
Me too, but think it would slow down a lot of Windows developers (myself included). Hope these comments are useful - at least worth a moments consideration. Rob
Mar 01 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> wrote:
 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that  
 was
 sarcasm).
Ok, so given that D does not have different sized basic types, but fixed sized basic types, what do you recommend we do here? I believe the point you were making is that on some systems pointers are 32bit, and others 64bit, and you need a type that will definately hold a pointer. D can do this with typedef, or alias, eg. version(32bit) { typedef ptr_t uint } version(64bit) { typedef ptr_t ulong } or similar. What do you think? Regan
Mar 01 2005
next sibling parent reply "Rob Grainger" <nospam nospam.com> writes:
Regan,

Yes, that's exactly the approach I'd recommend. Closest in concept to the 
Win32 approach, so
more familiar to Win API programmers.

Rob

"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsmzpakfh23k2f5 ally...
 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> wrote:
 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that 
 was
 sarcasm).
Ok, so given that D does not have different sized basic types, but fixed sized basic types, what do you recommend we do here? I believe the point you were making is that on some systems pointers are 32bit, and others 64bit, and you need a type that will definately hold a pointer. D can do this with typedef, or alias, eg. version(32bit) { typedef ptr_t uint } version(64bit) { typedef ptr_t ulong } or similar. What do you think? Regan
Mar 01 2005
parent reply "Rob Grainger" <nospam nospam.com> writes:
Regan,

As a brief postscript, I do like the increased type safety typedef gives - 
its
always annoyed me in C++ not being able to overload on different typedef's.

As long as there no interactions at ABI level to prevent this, making alias
a better choice.

Rob

"Rob Grainger" <nospam nospam.com> wrote in message 
news:d03ah5$1jl1$1 digitaldaemon.com...
 Regan,

 Yes, that's exactly the approach I'd recommend. Closest in concept to the 
 Win32 approach, so
 more familiar to Win API programmers.

 Rob

 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsmzpakfh23k2f5 ally...
 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> 
 wrote:
 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that 
 was
 sarcasm).
Ok, so given that D does not have different sized basic types, but fixed sized basic types, what do you recommend we do here? I believe the point you were making is that on some systems pointers are 32bit, and others 64bit, and you need a type that will definately hold a pointer. D can do this with typedef, or alias, eg. version(32bit) { typedef ptr_t uint } version(64bit) { typedef ptr_t ulong } or similar. What do you think? Regan
Mar 01 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Rob Grainger" <nospam nospam.com> wrote in message 
news:d03bmk$1khd$1 digitaldaemon.com...
 Regan,

 As a brief postscript, I do like the increased type safety typedef 
 gives - its
 always annoyed me in C++ not being able to overload on different 
 typedef's.
You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>
 As long as there no interactions at ABI level to prevent this, making 
 alias
 a better choice.
Walter's said many times in the last few years that this approach is unmanageable, yet it's brought me nothing but goodness. Go figure!
Mar 01 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

As a brief postscript, I do like the increased type safety typedef 
gives - its
always annoyed me in C++ not being able to overload on different 
typedef's.
You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>
That does it! ;-) Now it seems like there is *no* alternative but to fork out the $60 that the local bookstore wants for it, or this will just never stop... (Might as well get DDJ for $20, as well, so that I can read Walter's and Matthew's articles in it ?) http://isbn.nu/0321228774 --anders
Mar 02 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:
 Matthew wrote:
 
 As a brief postscript, I do like the increased type safety typedef 
 gives - its
 always annoyed me in C++ not being able to overload on different 
 typedef's.
You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>
That does it! ;-) Now it seems like there is *no* alternative but to fork out the $60 that the local bookstore wants for it, or this will just never stop... (Might as well get DDJ for $20, as well, so that I can read Walter's and Matthew's articles in it ?) http://isbn.nu/0321228774
If you only had money for a single magazine subscription, then I'd say DDJ is it!
Mar 02 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 If you only had money for a single magazine subscription, then I'd say 
 DDJ is it!
I got it... So far DDJ is $10 per article read, but that's about the usual rate from when I used to buy it on the magazine stand. :-) Shipping paper to us europeans just isn't very cost-effective... I actually got all of DDJ, Software Development mag and CUJ now! "The D Programming Language" http://www.ddj.com/documents/ddj0202c/ "printf Revisited" http://www.ddj.com/documents/ddj0501e/ So now I know some more about Walter's decisions behind D and writef. Too bad I can't share or discuss with the rest of you, due to ©... I guess the upcoming book will have a similar problem, unless we all sign up for it in advance and get a private chatroom or something ? --anders
Mar 02 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d0419i$2aeg$1 digitaldaemon.com...
 Matthew wrote:

As a brief postscript, I do like the increased type safety typedef 
gives - its
always annoyed me in C++ not being able to overload on different 
typedef's.
You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>
That does it! ;-) Now it seems like there is *no* alternative but to fork out the $60 that the local bookstore wants for it, or this will just never stop... (Might as well get DDJ for $20, as well, so that I can read Walter's and Matthew's articles in it ?) http://isbn.nu/0321228774
What an excellent idea. May I recommend that everyone goes out and buy it? <CG>
Mar 02 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 02 Mar 2005 16:00:10 +1300, Regan Heath wrote:

 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com> wrote:
 Again, the purpose here is not to be cross-language (these kind of names
 never made an
 appearance in VB), but to support C compilers where the basic types have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that  
 was
 sarcasm).
Ok, so given that D does not have different sized basic types, but fixed sized basic types, what do you recommend we do here? I believe the point you were making is that on some systems pointers are 32bit, and others 64bit, and you need a type that will definately hold a pointer. D can do this with typedef, or alias, eg. version(32bit) { typedef ptr_t uint } version(64bit) { typedef ptr_t ulong } or similar. What do you think? Regan
Just letting you know that in object.d we already have ... version (AMD64) { alias ulong size_t; alias long ptrdiff_t; } else version (X86) { alias uint size_t; alias int ptrdiff_t; } Which probably means all you need to do is ... alias size_t ptr_t; -- Derek Melbourne, Australia 2/03/2005 2:26:46 PM
Mar 01 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 2 Mar 2005 14:28:34 +1100, Derek Parnell <derek psych.ward> wrote:
 On Wed, 02 Mar 2005 16:00:10 +1300, Regan Heath wrote:

 On Wed, 2 Mar 2005 02:21:51 -0000, Rob Grainger <nospam nospam.com>  
 wrote:
 Again, the purpose here is not to be cross-language (these kind of  
 names
 never made an
 appearance in VB), but to support C compilers where the basic types  
 have
 different sizes
 (a rare occurence on Windows, but theoretically possible) - all such a
 compiler-vendor
 would need to do is define a few thousand typedef's appropiately (that
 was
 sarcasm).
Ok, so given that D does not have different sized basic types, but fixed sized basic types, what do you recommend we do here? I believe the point you were making is that on some systems pointers are 32bit, and others 64bit, and you need a type that will definately hold a pointer. D can do this with typedef, or alias, eg. version(32bit) { typedef ptr_t uint } version(64bit) { typedef ptr_t ulong } or similar. What do you think? Regan
Just letting you know that in object.d we already have ...
Thanks Derek, I had forgotten where this was.
 version (AMD64)
 {
     alias ulong size_t;
     alias long ptrdiff_t;
 }
 else version (X86)
 {
     alias uint size_t;
     alias int ptrdiff_t;
 }

 Which probably means all you need to do is ...

   alias size_t ptr_t;
Or perhaps we want/need to add ptrsize_t to object.d? Regan
Mar 01 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 Just letting you know that in object.d we already have ...
 version (AMD64)
 {
     alias ulong size_t;
     alias long ptrdiff_t;
 }
 else version (X86)
 {
     alias uint size_t;
     alias int ptrdiff_t;
 }
Thanks Derek, I had forgotten where this was.
Side Note: In the portable version of Phobos, this passage reads: version (GNU) { version (GNU_BitsPerPointer32) { alias uint size_t; alias int ptrdiff_t; } else version (GNU_BitsPerPointer64) { alias ulong size_t; alias long ptrdiff_t; } else { static assert(0); } } else version (AMD64) { alias ulong size_t; alias long ptrdiff_t; } else version (X86) { alias uint size_t; alias int ptrdiff_t; } else { static assert(0); } Where GNU_BitsPerPointer is set automagically by GDC:
 #if UNITS_PER_WORD == 4
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerWord32");
 #elif UNITS_PER_WORD == 8
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerWord64");
 #endif
 #if POINTER_SIZE == 32
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerPointer32");
 #elif POINTER_SIZE == 64
     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerPointer64");
 #endif
And those C macros are in turn set by GCC's configure. --anders PS. You still need Wine for the Win32 API's, though... :-) http://www.winehq.com/
Mar 02 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Rob Grainger wrote:

Which is more readable/understandable?

    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
wParam, LPARAM lParam)

or

    typedef void* Handle = (void*)0; // a typedef, but a useful one
    extern (Windows) int windowCallback(Handle handle, uint message, uint 
param1, int param2)
I think we both agree on this.
Hope you mean the first version, because even I recognize that one... And when reading Win32 API documentation, it would be the one I'd find. Here is one article, which you might find interesting: (it's about interfacing OS APIs with Java, but anyway) http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html Maintaining the one-to-one mapping is important, and I would say this also includes the types being used ?
 Me too, but think it would slow down a lot of Windows developers (myself 
 included).
 
 Hope these comments are useful - at least worth a moments consideration.
Many other libraries also add their own types, which are D aliases. Some examples are: OpenGL, libSDL, and Mac OS X's Carbon API... It's easier to add a dozen aliases, than to change all the functions... EXAMPLES ======== OpenGL: (gl.gl)
 alias ubyte GLboolean;
 alias byte GLbyte;
 alias short GLshort;
 alias int GLint;
 alias int GLsizei;
 alias ubyte GLubyte;
 alias ushort GLushort;
 alias uint GLuint;
libSDL: (sdl.types)
 enum SDL_bool : int {
         SDL_FALSE = 0,
         SDL_TRUE  = 1
 }
 alias ubyte     Uint8;
 alias byte      Sint8;
 alias ushort    Uint16;
 alias short     Sint16;
 alias uint      Uint32;
 alias int       Sint32;
 alias ulong     Uint64;
 alias long      Sint64;
Carbon: (macosx.carbon)
 alias ubyte Boolean;
 alias  ubyte UInt8;
 alias   byte SInt8;
 alias ushort UInt16;
 alias  short SInt16;
 alias   uint UInt32;
 alias    int SInt32;
 alias  ulong UInt64;
 alias   long SInt64;
Even for "pure" D code, some aliases are good. Like bool and str :-) But interfacing with C libraries is different, and has way more legacy. --anders
Mar 02 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d040oi$2a02$1 digitaldaemon.com...
 Rob Grainger wrote:

Which is more readable/understandable?

    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)

or

    typedef void* Handle = (void*)0; // a typedef, but a useful one
    extern (Windows) int windowCallback(Handle handle, uint message, 
 uint param1, int param2)
I think we both agree on this.
Hope you mean the first version, because even I recognize that one... And when reading Win32 API documentation, it would be the one I'd find.
You recognise it because you're familiar with reading the C API, as am I. But we can't assume all users of our libraries will share that experience. And they won't be looking up things on MSDN - they'll (hopefully) be reading the library's documentation. I think it's more important to make life easier for them than for ourselves. It might also turn off people coming from Java An alternative is to put the SDK version of a declaration in the library's documentation, or in comments in your code, thereby keeping both camps happy.
 Here is one article, which you might find interesting:
 (it's about interfacing OS APIs with Java, but anyway)

 http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

 Maintaining the one-to-one mapping is important, and
 I would say this also includes the types being used ?


 Me too, but think it would slow down a lot of Windows developers (myself 
 included).

 Hope these comments are useful - at least worth a moments consideration.
Many other libraries also add their own types, which are D aliases. Some examples are: OpenGL, libSDL, and Mac OS X's Carbon API... It's easier to add a dozen aliases, than to change all the functions... EXAMPLES ======== OpenGL: (gl.gl)
 alias ubyte GLboolean;
 alias byte GLbyte;
 alias short GLshort;
 alias int GLint;
 alias int GLsizei;
 alias ubyte GLubyte;
 alias ushort GLushort;
 alias uint GLuint;
libSDL: (sdl.types)
 enum SDL_bool : int {
         SDL_FALSE = 0,
         SDL_TRUE  = 1
 }
 alias ubyte     Uint8;
 alias byte      Sint8;
 alias ushort    Uint16;
 alias short     Sint16;
 alias uint      Uint32;
 alias int       Sint32;
 alias ulong     Uint64;
 alias long      Sint64;
Carbon: (macosx.carbon)
 alias ubyte Boolean;
 alias  ubyte UInt8;
 alias   byte SInt8;
 alias ushort UInt16;
 alias  short SInt16;
 alias   uint UInt32;
 alias    int SInt32;
 alias  ulong UInt64;
 alias   long SInt64;
Even for "pure" D code, some aliases are good. Like bool and str :-) But interfacing with C libraries is different, and has way more legacy. --anders
Mar 02 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John C wrote:

Hope you mean the first version, because even I recognize that one...
And when reading Win32 API documentation, it would be the one I'd find.
You recognise it because you're familiar with reading the C API, as am I.
And I suppose all the rest trying to use the API in question, as well ? Like in all sample code and in all printed books that can be found...
 But we can't assume all users of our libraries will share that experience. 
 And they won't be looking up things on MSDN - they'll (hopefully) be reading 
 the library's documentation.
Porting the C/C++ headers into a D import module is enough work *without* having to translate all types and documentation, IMHO.
 I think it's more important to make life easier 
 for them than for ourselves. It might also turn off people coming from Java 

That's too bad for them, isn't it... ? It's a good thing D has it.
 An alternative is to put the SDK version of a declaration in the library's 
 documentation, or in comments in your code, thereby keeping both camps 
 happy.
Duplicating each function, as if people read documentation ? :-) As long as it can be fully automated, I guess that *could* work... My thoughts: The more copy-and-paste the H2D process of translating is, the better. As it is now, it's pretty straightforward - with a few minor caveats. And if it's easy to use C libraries, it makes D all that more useful. (even if those libs are not using Exceptions or GC or OOP or anything) Like Walter says: (in http://www.digitalmars.com/d/phobos.html)
 D provides direct access to C runtime library functions and operating  system
 API functions. Pointless D wrappers around those functions just adds
 blather, bloat, baggage and bugs. 
With the aliases, I've found porting at least three major APIs and a few smaller ones to be a doable task (at least with some Perl help) That doesn't stop the D programs and libraries from being high-level, of course. Here I was just talking about the actual low-level C APIs. --anders
Mar 02 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
John C wrote:
 Which is more readable/understandable?
 
     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
 wParam, LPARAM lParam)
 
 or
 
     typedef void* Handle = (void*)0; // a typedef, but a useful one
     extern (Windows) int windowCallback(Handle handle, uint message, uint 
 param1, int param2)
It is extremely important to _never_ try to rename things like LRESULT, HWND, UINT, WPARAM, LPARAM to anything else. Most especially HWND, LPARAM and WPARAM. Were these renamed, then their users could never ask any Windows savvy programmers for advice. These words are _cornerstone_ words in Windows programming. They also bring a certain level of independence of architecture. Ideally one's own programs should work on any hardware platform that Windows supports now or in the future, and only by using these words as such is there hope for it. I'm not too happy either with the first example above, and I admit that the second is more readable. But this is only at the beginning. Using the second version will keep people from getting familiar with the standard way of Windows programming, and thus just move the same barrier down the road, where it's waiting for you with a vengeance. :-) So the suggestion is as useful as converting all keywords of the D language to Finnish, for Finnish programmers.
Mar 02 2005
prev sibling next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
We've talked about it quite a bit, but not got far.  Has anyone actually 
undertaken the task of translating the Windows API headers into D?

If not, I hereby propose we get started on it now!  We can do this as a 
team effort, with each member translating one or more of the Windows .h 
files.  I suggest we proceed as follows:

1. Decide on some rules.  I have some ideas for rules, as well as a few 
open issues in this respect, which I'll post a bit later (assuming I'm 
going to get some interest in this project).
style rules? I would suggest all files be public domain or without any claims of copyright etc, KISS
2. Set up a page on Wiki4D for the project, which would enable 
individuals to 'take' individual modules that they're going to work on.
good idea what needs to be done?
3. Find somewhere to keep the translated modules for the time being. 
Maybe dsource?
a good place to put them - I wish we could get more people to use it (someone started a Java to D translator and then disappeared and of course there is no source code anywhere) maybe someone could start with: http://hp.vector.co.jp/authors/VA028375/d/windows.h.html or is Core32 the way to go? a standard .zip package is always best for source code which compresses very nicely
Jan 29 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Mark T wrote:
 In article <ctdc6n$2e4l$1 digitaldaemon.com>, Stewart Gordon says...
<snip>
 1. Decide on some rules.  I have some ideas for rules, as well as a 
 few open issues in this respect, which I'll post a bit later 
 (assuming I'm going to get some interest in this project).
style rules?
Rules, guidelines, whatever it would make sense to call them. Basically so that the modules look reasonably tidy and consistent and, more importantly, use module names and versioning consistently.
 I would suggest all files be public domain or without any claims of 
 copyright etc, KISS
You're probably right. But what is the copyright of the standard Windows C headers? I guess this would count as a derivative work - so what are the implications? <snip>
 maybe someone could start with: 
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
That sounds as though it's a single module encompassing the whole of the windows.h include tree. (I meant to investigate, but didn't quite get that far.) I was thinking of something whereby .h files are converted 1:1 to .d files.
 or is Core32 the way to go?
<snip> Maybe. Maybe we don't need to reinvent the wheel, but merely refine it. BTW here are the rules/guidelines I had in mind (if we're merely going to refine the wheel, maybe it would be overkill to try applying them all to what's already done): Name your module as etc.c.windows.xyz, where xyz.h is the C header of which it is a translation. (The hope is that Walter will eventually replace "etc" with "std" in what we end up with....) Use D notations in preference to legacy C ones (e.g. array and pointer notations attached to the type, function pointers). Get rid of STRICT (treat as always defined), and assume WINVER >= 0x400. Otherwise, replace #ifdefs with version blocks. Use anonymous enums for sets of constants, with an appropriate base type. (For those constants that are outside the arbitrary restrictions on enum base types, use consts.) Use aliases, not typedefs (except for HANDLE, since handles aren't interchangeable with pointers). Get rid of the C struct tags, and instead use the 'normal' name of the struct as the struct name. Mark functions as deprecated as indicated in the API documentation. Indent by one tab character within {...} blocks. Use spaces to align values of enum constants and names of struct members in a column. Open questions: Should we use the many meaningless type aliases, or just declare everything with the real types hiding behind them? There are three options: - declare and use - declare but don't use - don't declare or use The answer could be considered separately for each kind of type: - generic primitive type aliases (e.g. UINT, DWORD) - specific or semi-specific primitive type aliases (e.g. WPARAM, LRESULT) - primitive-derived pointer types (e.g. PINT, LPSTR) - struct pointer types (e.g. LPRECT) - moreover, we can consider P/PC/LP/LPC separately for pointer types, considering that D doesn't have near/far or const pointers - function pointer types (e.g. WNDPROC) - I'd say we should definitely use these Should we dot version(UNICODE) blocks all over the place as done in the C headers? Or just move them all to one block at the end of each module? Does HANDLE really need to be defined as void*? Or would it make more sense to define it as int, uint or something? (Does the Windows mangling/calling convention allow this?) This would be one step towards dealing with potential copying GC troubles. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jan 31 2005
next sibling parent Mark T <Mark_member pathlink.com> writes:
 I would suggest all files be public domain or without any claims of 
 copyright etc, KISS
You're probably right. But what is the copyright of the standard Windows C headers? I guess this would count as a derivative work - so what are the implications?
start with mingw headers and use their copyright
- struct pointer types (e.g. LPRECT)
- moreover, we can consider P/PC/LP/LPC separately for pointer types, 
considering that D doesn't have near/far or const pointers
near/far is obsolete for Win32 just ignore it
Jan 31 2005
prev sibling parent Mark T <Mark_member pathlink.com> writes:
<snip>
 maybe someone could start with: 
 http://hp.vector.co.jp/authors/VA028375/d/windows.h.html
That sounds as though it's a single module encompassing the whole of the windows.h include tree. (I meant to investigate, but didn't quite get that far.) I was thinking of something whereby .h files are converted 1:1 to .d files.
I prefer his simple win32 folder vs etc.stuff it's 1:1 win32 ansi <DIR> 01-31-05 7:36p ansi commctrl d 210,057 05-07-04 11:30a commctrl.d commdlg d 28,951 10-08-03 11:56p commdlg.d dde d 2,653 10-09-03 12:14a dde.d ddeml d 13,549 10-09-03 12:14a ddeml.d dlgs d 6,001 10-09-03 12:14a dlgs.d guiddef d 606 05-07-04 11:01a guiddef.d imm d 23,070 10-08-03 11:54p imm.d mmsystem d 112,046 05-07-04 11:34a mmsystem.d shellapi d 23,237 10-08-03 11:57p shellapi.d winbase d 171,588 05-07-04 11:50a winbase.d wincon d 16,210 10-09-03 12:15a wincon.d windef d 7,534 01-23-04 5:28a windef.d windows d 3,835 10-27-03 11:23a windows.d winerror d 178,637 05-07-04 1:07p winerror.d wingdi d 144,163 05-07-04 12:39p wingdi.d winnls d 36,356 10-09-03 12:13a winnls.d winnt d 168,115 07-08-04 1:39p winnt.d winreg d 17,106 05-07-04 1:11p winreg.d winsock d 19,903 03-13-04 10:34p winsock.d winspool d 69,654 10-09-03 12:06a winspool.d winuser d 227,269 07-08-04 1:38p winuser.d winver d 7,250 10-09-03 12:07a winver.d
Jan 31 2005
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon, all the older Blaze demos have worked for me, but this time it
gives me:

...
Registering widget: Angle
Registering widget: SceneView
derelict.util.exception.SharedLibLoadException: Failed to load shared library
devil.dll

And stops.
The DevIL.dll is present beside the exe.

Bye,
bearophile
Mar 16 2009
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
bearophile wrote:
 Stewart Gordon, all the older Blaze demos have worked for me, but this time it
gives me:
 
 ...
 Registering widget: Angle
 Registering widget: SceneView
 derelict.util.exception.SharedLibLoadException: Failed to load shared library
devil.dll
<snip> I'm not sure what this has to do with the Windows API bindings project. I also don't know anything about Blaze, but maybe someone else on the 'group knows and may be able to help, or you could have a look around yourself for the code that throws that exception. Stewart.
Mar 16 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:
 I'm not sure what this has to do with the Windows API bindings project. 
   I also don't know anything about Blaze, but maybe someone else on the 
 'group knows and may be able to help, or you could have a look around 
 yourself for the code that throws that exception.
I am sorry, it's a mistake of mine caused by the online forum. Ignore that post of mine please. Bye, bearophile
Mar 16 2009