Stewart Gordon wrote:
<snip>
> There are numerous other versioning #ifdefs in the C headers.  How many of them do we really need?  I'm in the process of rounding up a list of them....

Here's the list of versions that we _might_ want to keep in:

DIRECT3D_VERSION
ODBCVER

COBJMACROS
DESC_CHAR_UNICODE
INITGUID
MCI_USE_OFFEXT
NEC_98
ODBC_STD
OLE2ANSI
PROXY_CLSID
PROXY_CLSID_IS
PROXY_DELEGATION
REGISTER_PROXY_DLL
RPC_UNICODE_SUPPORTED
SERVERONLY
SH3
SNMPSTRICT
UNDER_CE
UNICODE_ONLY
USE_STUBLESS_PROXY
WIN32_LEAN_AND_MEAN
XFree86Server
_FIX_ENABLEMODELESS_CONFLICT
__COMPILING_LARGEINT
__USE_NTOSKRNL__
__USE_W32_SOCKETS
__W32API_USE_DLLIMPORT__


The first two of these identify versions in much the same way as _WIN32_WINDOWS and _WIN32_WINNT do, and so probably want to be treated in a similar way.

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?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Stewart Gordon wrote:
> <snip>
>> There are numerous other versioning #ifdefs in the C headers.  How many of them do we really need?  I'm in the process of rounding up a list of them....
> 
> Here's the list of versions that we _might_ want to keep in:
> 
> DIRECT3D_VERSION
> ODBCVER
> 
> COBJMACROS
> DESC_CHAR_UNICODE
> INITGUID
> MCI_USE_OFFEXT
> NEC_98
> ODBC_STD
> OLE2ANSI
> PROXY_CLSID
> PROXY_CLSID_IS
> PROXY_DELEGATION
> REGISTER_PROXY_DLL
> RPC_UNICODE_SUPPORTED
> SERVERONLY
> SH3
> SNMPSTRICT
> UNDER_CE
> UNICODE_ONLY
> USE_STUBLESS_PROXY
> WIN32_LEAN_AND_MEAN
> XFree86Server
> _FIX_ENABLEMODELESS_CONFLICT
> __COMPILING_LARGEINT
> __USE_NTOSKRNL__
> __USE_W32_SOCKETS
> __W32API_USE_DLLIMPORT__
> 
> 
> The first two of these identify versions in much the same way as _WIN32_WINDOWS and _WIN32_WINNT do, and so probably want to be treated in a similar way.

I'd like to see almost all of those things disappear. DIRECT3D is important, and probably ODBCVER, but most of the others should vanish. Many of them only exist to reduce compilation time.

There seem to be a few that are for compatibility with the DDK headers, but the ones I've seen are mostly to avoid duplicate definitions, so shouldn't be a problem with D.

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

It would be good to get rid of them, I don't think it will cause any problems (it's almost as if the WinAPI uses standard D types, and C code needs LARGE_INTEGER as a workaround for the absence of int64 in C. We don't need that stuff).

One other thing I've done is remove any macros that are stated as being only for Win16 compatibility *and* that have no effect.

We should probably remove the aliases for near pointers. There's not many of them, and most of them were a bad idea even in the Win 3.0 days.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:e10hmd$265q$1@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?

John C wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:e10hmd$265q$1@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.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Wed, 05 Apr 2006 11:26:20 -0400, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> John C wrote:
>> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:e10hmd$265q$1@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....)
>

They turn into the same mangled name; such functions can be overloaded to take either:

extern(Windows)
{
   BOOL QueryPerformanceCounter(LARGE_INTEGER* lpPerformanceCount);
   BOOL QueryPerformanceCounter(long* lpPerformanceCount);
}
int main()
{
   LARGE_INTEGER li;
   long l;
   assert(QueryPerformanceCounter(&li));
   assert(QueryPerformanceCounter(&l));
   return 0;
}

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:e10nit$2gk2$1@digitaldaemon.com...
> John C wrote:
>> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:e10hmd$265q$1@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?

Don Clugston wrote:
> Stewart Gordon wrote:
<snip>
>> Here's the list of versions that we _might_ want to keep in:
<snip>
> I'd like to see almost all of those things disappear. DIRECT3D is important, and probably ODBCVER, but most of the others should vanish. Many of them only exist to reduce compilation time.

Taken the words out of my mouth there.  And now that computers are faster and that D's symbolic imports are supposed to be more efficient than old-fashioned C preprocessor includes, this benefit isn't really there to the same extent.

> There seem to be a few that are for compatibility with the DDK headers, but the ones I've seen are mostly to avoid duplicate definitions, so shouldn't be a problem with D.

Yes, I cut those out of the list already.  And what's DDK?

<snip>
> We should probably remove the aliases for near pointers. There's not many of them, and most of them were a bad idea even in the Win 3.0 days.

Aliases for near pointers?  I thought there were only aliases for default pointers and aliases for far pointers.  But the distinction is irrelevant in Win32 and hence in D.  But the C headers still use both sets of aliases.  Personally I don't think we need either.  Shall we do away with them?

BTW it seems one of us made a slip-up with winbase.d and an older version ended up being re-committed to Dsource.  Revision 40 of this file is better than revision 43.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Don Clugston wrote:
>> Stewart Gordon wrote:
> <snip>
>>> Here's the list of versions that we _might_ want to keep in:
> <snip>
>> I'd like to see almost all of those things disappear. DIRECT3D is important, and probably ODBCVER, but most of the others should vanish. Many of them only exist to reduce compilation time.
> 
> Taken the words out of my mouth there.  And now that computers are faster and that D's symbolic imports are supposed to be more efficient than old-fashioned C preprocessor includes, this benefit isn't really there to the same extent.
> 
>> There seem to be a few that are for compatibility with the DDK headers, but the ones I've seen are mostly to avoid duplicate definitions, so shouldn't be a problem with D.
> 
> Yes, I cut those out of the list already.  And what's DDK?
The Device Development Kit. It's in the w32api\ddk\ directory in MinGW.
Microsoft distributes DDK seperately from the SDK, and it seems that there are some #defines that are different in the two files.
> 
> <snip>
>> We should probably remove the aliases for near pointers. There's not many of them, and most of them were a bad idea even in the Win 3.0 days.
> 
> Aliases for near pointers?  I thought there were only aliases for default pointers and aliases for far pointers. 

In Wingdi.h was
typedef LOGPALETTE * PLOGPALETTE, * NPLOGPALETTE, * LPLOGPALETTE;
and in winnt.h was
typedef CHAR * NPSTR;

I've just removed them. Grepping through the MinGW files I didn't find any other examples.

 But the distinction is
> irrelevant in Win32 and hence in D.  But the C headers still use both sets of aliases.  Personally I don't think we need either.  Shall we do away with them?

That one's tricky. Usage of LPSTR seems to be _really_ common. Much more common than PSTR. I think we need to get a D SDK that compiles before we  consider a cleanup on that scale.

> 
> BTW it seems one of us made a slip-up with winbase.d and an older version ended up being re-committed to Dsource.  Revision 40 of this file is better than revision 43.

'one of us' would be me <g>. Unclobbered.

BTW -
I think the primary goal for the short term should be to have the WIN32LEANANDMEAN subset compiling. Once we have that, this project will be a viable substitute for std.c.windows.windows. I think it would be good to split the file list in the wiki into the LEAN&MEAN files, which are high priority, and the more obscure stuff. It would be good to see how much we still need to do.

How is this progressing?

DBloke wrote:
> How is this progressing?

The current status is visible from the Wiki web page, and from the dsource bindings repository. In summary:

* Almost everything included by windows.h has now been converted. The only exceptions are the rpc stuff, which requires a big chunk of the COM code to be converted.
* Some of the macros and bit fields in structs haven't been converted yet -- but most have.
* During the conversion, many bugs in the MinGW code have been discovered and fixed. (Most of those bugs relate to Windows versioning).
* It's not very well tested yet.
* I believe that it's very close to being a viable alternative to the Windows header in Phobos. Almost all of the functions in Phobos are included.