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

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

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

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

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.

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

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

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.

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.

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.