Yet another effort at translating the Win32 API headers

[John C]

"Stewart Gordon" <smjg_1998 at yahoo.com> wrote in message 
news:e10nit$2gk2$1 at digitaldaemon.com...
> John C wrote:
>> "Stewart Gordon" <smjg_1998 at yahoo.com> wrote in message 
>> news:e10hmd$265q$1 at digitaldaemon.com...
>>> Stewart Gordon wrote:
>>> <snip>
>>> And I'm not sure if the largeint stuff is necessary at all.  I suppose 
>>> there's no point in translating largeint.h, as it's all stuff that D has 
>>> built in.  But do we need to keep the LARGE_INTEGER and ULARGE_INTEGER 
>>> structures (defined in winnt.h) for compatibility?
>>
>> Can't these just be changed to long and ulong?
>
> That's what I'd begun to think.  But it depends on:
>
> - whether the Windows calling/name mangling convention relies on the 
> distinction between structs and primitive types that have the same size
>
> - whether there are enough Windows programmers out there who rely on the 
> quick access to the high and low dwords that the LARGE_INTEGER and 
> ULARGE_INTEGER structures provide (but considering that casts, bitmasks 
> and bitshifts are always available....)
>
> Stewart.

I usually overload those functions to provide a choice. It's especially nice 
to be able to have both inout and pointer versions for functions that take 
pointers to structs.

I meant to ask, what are you doing with all those ghastly LPARAM, LRESULT, 
INT/UINT and handle typedefs? Is there a clean way that you can use native D 
types for these instead without losing portability for example to Win64?