www.digitalmars.com         C & C++   DMDScript  

D - alias, typedef & windows.d

reply "Matthew Wilson" <matthew stlsoft.org> writes:
I was just wondering if anyone could tell me why we do not use typedef
rather than alias for such things as HKEY?

It seems to me this would be a simple and elegant tightening of the Win32
type-system.

Matthew
Aug 08 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh1j1d$t44$1 digitaldaemon.com...
 I was just wondering if anyone could tell me why we do not use typedef
 rather than alias for such things as HKEY?

 It seems to me this would be a simple and elegant tightening of the Win32
 type-system.

One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed in with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them and not worry about it. Save the clean designs for doing something new, not legacy API's.
Aug 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1j1d$t44$1 digitaldaemon.com...
 I was just wondering if anyone could tell me why we do not use typedef
 rather than alias for such things as HKEY?

 It seems to me this would be a simple and elegant tightening of the


 type-system.

One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed

 with the underlying types. Microsoft's own sample code is woefully
 inconsistent about it. It's so much easier to just use alias for them and
 not worry about it. Save the clean designs for doing something new, not
 legacy API's.

This doesn't make any sense to me. Since all the definitions are, by definition, in D, why does it matter what the existing definitions are. Having said that, I've not tried it, so if you can give me a single simple example I'll pull my head in. ;)
Aug 08 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh1m0l$vq8$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1j1d$t44$1 digitaldaemon.com...
 I was just wondering if anyone could tell me why we do not use typedef
 rather than alias for such things as HKEY?
 It seems to me this would be a simple and elegant tightening of the


 type-system.

Unfortunately, most code plays fast and loose with using C typedefs


 in
 with the underlying types. Microsoft's own sample code is woefully
 inconsistent about it. It's so much easier to just use alias for them


 not worry about it. Save the clean designs for doing something new, not
 legacy API's.

definition, in D, why does it matter what the existing definitions are.

Because to call them, you'll need to look at example code. The example code is inconsistent.
 Having said that, I've not tried it, so if you can give me a single simple
 example I'll pull my head in. ;)

Try explaining the elegant difference between GUID, UUID, IID, CLSID, FMTID? <g> Another I ran across repeatedly are the multiple ways of doing wchar_t's. There seems to be half-a-dozen different typedefs for those in the Microsoft headers, with overlapping usage. I ran into this a lot doing the javascript implementation. LPOLESTR vs LPWSTR anyone? Another is the constant typedefs for LPxxxxx, and then just using xxxxx* anyway. How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the DECLARE_HANDLE() macros?
Aug 08 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I can see the merit in some of what you say. LOL.

Nonetheless, if we have people who are across these issues (and I am
comfortable with every one of your examples - though I'm not volunteering
for the task!!), then I still fail to see why (i) it cannot be done, and
(ii) it would not be significantly advantageous.

I seriously suggest everyone give this some serious thought. Let's have some
votes on it.

For: 1
Against: 1

"Walter" <walter digitalmars.com> wrote in message
news:bh202k$18mj$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1m0l$vq8$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1j1d$t44$1 digitaldaemon.com...
 I was just wondering if anyone could tell me why we do not use




 rather than alias for such things as HKEY?
 It seems to me this would be a simple and elegant tightening of the


 type-system.

Unfortunately, most code plays fast and loose with using C typedefs


 in
 with the underlying types. Microsoft's own sample code is woefully
 inconsistent about it. It's so much easier to just use alias for them


 not worry about it. Save the clean designs for doing something new,



 legacy API's.

definition, in D, why does it matter what the existing definitions are.

Because to call them, you'll need to look at example code. The example

 is inconsistent.

 Having said that, I've not tried it, so if you can give me a single


 example I'll pull my head in. ;)

Try explaining the elegant difference between GUID, UUID, IID, CLSID,

 <g>

 Another I ran across repeatedly are the multiple ways of doing wchar_t's.
 There seems to be half-a-dozen different typedefs for those in the

 headers, with overlapping usage. I ran into this a lot doing the

 implementation. LPOLESTR vs LPWSTR anyone?

 Another is the constant typedefs for LPxxxxx, and then just using xxxxx*
 anyway.

 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?

Aug 08 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
If someone was going to try this, I suggest at least start out using
alias's. Then try a couple typedef's, and see what happens <g>. I predict it
won't be long until things go back to alias. You can't realistically
retrofit type safety on a system that's been aggregating new aliases for 15
years. Cleaning up the Windows API is something way beyond the scope of D.

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh20hh$18v0$1 digitaldaemon.com...
 I can see the merit in some of what you say. LOL.

 Nonetheless, if we have people who are across these issues (and I am
 comfortable with every one of your examples - though I'm not volunteering
 for the task!!), then I still fail to see why (i) it cannot be done, and
 (ii) it would not be significantly advantageous.

 I seriously suggest everyone give this some serious thought. Let's have

 votes on it.

 For: 1
 Against: 1

 "Walter" <walter digitalmars.com> wrote in message
 news:bh202k$18mj$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1m0l$vq8$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1j1d$t44$1 digitaldaemon.com...
 I was just wondering if anyone could tell me why we do not use




 rather than alias for such things as HKEY?
 It seems to me this would be a simple and elegant tightening of





 Win32
 type-system.

Unfortunately, most code plays fast and loose with using C typedefs


 in
 with the underlying types. Microsoft's own sample code is woefully
 inconsistent about it. It's so much easier to just use alias for




 and
 not worry about it. Save the clean designs for doing something new,



 legacy API's.

definition, in D, why does it matter what the existing definitions



 Because to call them, you'll need to look at example code. The example

 is inconsistent.

 Having said that, I've not tried it, so if you can give me a single


 example I'll pull my head in. ;)

Try explaining the elegant difference between GUID, UUID, IID, CLSID,

 <g>

 Another I ran across repeatedly are the multiple ways of doing


 There seems to be half-a-dozen different typedefs for those in the

 headers, with overlapping usage. I ran into this a lot doing the

 implementation. LPOLESTR vs LPWSTR anyone?

 Another is the constant typedefs for LPxxxxx, and then just using xxxxx*
 anyway.

 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?


Aug 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
I'm still unconvinced, so I guess I'll just have to break my hubris on the
rocks of experience, and try it myself.

Watch this space ...

"Walter" <walter digitalmars.com> wrote in message
news:bh21tm$1a47$1 digitaldaemon.com...
 If someone was going to try this, I suggest at least start out using
 alias's. Then try a couple typedef's, and see what happens <g>. I predict

 won't be long until things go back to alias. You can't realistically
 retrofit type safety on a system that's been aggregating new aliases for

 years. Cleaning up the Windows API is something way beyond the scope of D.

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh20hh$18v0$1 digitaldaemon.com...
 I can see the merit in some of what you say. LOL.

 Nonetheless, if we have people who are across these issues (and I am
 comfortable with every one of your examples - though I'm not


 for the task!!), then I still fail to see why (i) it cannot be done, and
 (ii) it would not be significantly advantageous.

 I seriously suggest everyone give this some serious thought. Let's have

 votes on it.

 For: 1
 Against: 1

 "Walter" <walter digitalmars.com> wrote in message
 news:bh202k$18mj$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1m0l$vq8$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh1j1d$t44$1 digitaldaemon.com...
 I was just wondering if anyone could tell me why we do not use




 rather than alias for such things as HKEY?
 It seems to me this would be a simple and elegant tightening of





 Win32
 type-system.






 Unfortunately, most code plays fast and loose with using C





 mixed
 in
 with the underlying types. Microsoft's own sample code is woefully
 inconsistent about it. It's so much easier to just use alias for




 and
 not worry about it. Save the clean designs for doing something





 not
 legacy API's.

definition, in D, why does it matter what the existing definitions



 Because to call them, you'll need to look at example code. The example

 is inconsistent.

 Having said that, I've not tried it, so if you can give me a single


 example I'll pull my head in. ;)

Try explaining the elegant difference between GUID, UUID, IID, CLSID,

 <g>

 Another I ran across repeatedly are the multiple ways of doing


 There seems to be half-a-dozen different typedefs for those in the

 headers, with overlapping usage. I ran into this a lot doing the

 implementation. LPOLESTR vs LPWSTR anyone?

 Another is the constant typedefs for LPxxxxx, and then just using



 anyway.

 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?



Aug 08 2003
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh20hh$18v0$1 digitaldaemon.com...
 I can see the merit in some of what you say. LOL.

 Nonetheless, if we have people who are across these issues (and I am
 comfortable with every one of your examples - though I'm not volunteering
 for the task!!), then I still fail to see why (i) it cannot be done, and
 (ii) it would not be significantly advantageous.

 I seriously suggest everyone give this some serious thought. Let's have

 votes on it.

 For: 1
 Against: 1

against : 2 before you start voting for I suggest you try porting some windows header and use them ..... then you'll see why alias is better (for now) see below.
 "Walter" <walter digitalmars.com> wrote in message
 Try explaining the elegant difference between GUID, UUID, IID, CLSID,

 <g>


 Another I ran across repeatedly are the multiple ways of doing


 There seems to be half-a-dozen different typedefs for those in the

 headers, with overlapping usage. I ran into this a lot doing the

 implementation. LPOLESTR vs LPWSTR anyone?


 Another is the constant typedefs for LPxxxxx, and then just using xxxxx*
 anyway.


 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?


most of these are legacy from the win3.xx days when windows run in realmode, 286 protected mode and 386 protected mode, so near and far pointers where needed PBOOL => int near * LPBOOL => int far * ULONG and DWORD are the same on x86 arch's but are they on Alpha or Mips NT ? LPOLESTR is a string that OLE uses (originally I believe this was `char far*`) LPWSTR is a wide char string not sure if that has to be 16bit or if it might be 32 bit in later MS OS's the question is should the D windows modules be kept inline with the MS C interface or should we define a new way to program on win32 platfroms. I think most ppl who use win32 will say keep it MS like, it might be a little rubbish, and polutes the global name space with 1,000,000's of type aliases but means that you can port C code to D without having to change vast sections of code. if someone was willing to put the effort in then maybe I'd say have 2 windows modules windows.d (imports what you need D style as much as pos) window_compat.d import a huge amount of aliases for ease of programming. just try using typedefs for Handles and their possible uses HMODULE, HDC, HBRUSH etc as an example think of using typedef void * HANDLE; typedef HANDLE HGDI_OBJECT; typedef HGDI_OBJECT HBRUSH; typedef HGDI_OBJECT HBITMAP; HBRUSH CreateSolidBrush( ... ); O.K. HGDI_OBJECT SelectObject( HDC, HGDI_OBJECT ); so every call to SelectObject requires a cast. it might be nice if you could alias on params i.e. alias HBRUSH SelectObject( HDC, HBRUSH ) SelectObject; alias HBITMAP SelectObject( HDC, HBITMAP ) SelectObject;
Aug 09 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Sounds like a challenge. I get your point, but the GDI handle thing can be
handled by a little fake polymorphism, surely?

Anyway, I understand that it's a practical challenge, and the only way I'll
win over anyone is by doing it. Alas, it's going to be a couple of months
before I'll be doing some serious D-programming, but I will certainly try
out my approach at that time and report in (with my tail between my legs, no
doubt).


"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:bh2pd0$2458$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh20hh$18v0$1 digitaldaemon.com...
 I can see the merit in some of what you say. LOL.

 Nonetheless, if we have people who are across these issues (and I am
 comfortable with every one of your examples - though I'm not


 for the task!!), then I still fail to see why (i) it cannot be done, and
 (ii) it would not be significantly advantageous.

 I seriously suggest everyone give this some serious thought. Let's have

 votes on it.

 For: 1
 Against: 1

against : 2 before you start voting for I suggest you try porting some windows header and use them ..... then you'll see why alias is better (for now) see below.
 "Walter" <walter digitalmars.com> wrote in message
 Try explaining the elegant difference between GUID, UUID, IID, CLSID,

 <g>


 Another I ran across repeatedly are the multiple ways of doing


 There seems to be half-a-dozen different typedefs for those in the

 headers, with overlapping usage. I ran into this a lot doing the

 implementation. LPOLESTR vs LPWSTR anyone?


 Another is the constant typedefs for LPxxxxx, and then just using



 anyway.


 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?


most of these are legacy from the win3.xx days when windows run in

 286 protected mode and 386 protected mode, so near and far pointers where
 needed
 PBOOL => int near *  LPBOOL => int far *

 ULONG and DWORD are the same on x86 arch's but are they on Alpha or Mips

 ?

 LPOLESTR is a string that OLE uses (originally I believe this was `char
 far*`)
 LPWSTR is a wide char string not sure if that has to be 16bit or if it

 be 32 bit in later MS OS's

 the question is should the D windows modules be kept inline with the MS C
 interface or should we define a new way to program on win32 platfroms. I
 think most ppl who use win32 will say keep it MS like, it might be a

 rubbish, and polutes the global name space with 1,000,000's of type

 but means that you can port C code to D without having to change vast
 sections of code.

 if someone was willing to put the effort in then maybe I'd say have 2
 windows modules
 windows.d (imports what you need D style as much as pos) window_compat.d
 import a huge amount of aliases for ease of programming.

 just try using typedefs for Handles and their possible uses HMODULE, HDC,
 HBRUSH etc
 as an example think of using
 typedef void * HANDLE;
 typedef HANDLE HGDI_OBJECT;
 typedef HGDI_OBJECT HBRUSH;
 typedef HGDI_OBJECT HBITMAP;

 HBRUSH CreateSolidBrush( ... ); O.K.
 HGDI_OBJECT SelectObject( HDC, HGDI_OBJECT );

 so every call to SelectObject requires a cast.
 it might be nice if you could alias on params
 i.e.
 alias HBRUSH SelectObject( HDC, HBRUSH ) SelectObject;
 alias HBITMAP SelectObject( HDC, HBITMAP ) SelectObject;

Aug 09 2003
prev sibling parent reply "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 Another is the constant typedefs for LPxxxxx, and then just using
 xxxxx* anyway.

 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?

One of my favourites is HINSTANCE vs HMODULE; both things specify exactly the same entity both in meaning and in underlying type, you sometimes need to pass values you can only acquire as HINSTANCEs to functions expecting HMODULEs, et cetera et cetera. I'm relatively sure that "cleaning up" this syntax would actually make the situation far worse than it currently is. -fg
Aug 09 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Fabian Giesen" <rygNO SPAMgmx.net> wrote in message
news:bh2qfv$254o$1 digitaldaemon.com...
 Another is the constant typedefs for LPxxxxx, and then just using
 xxxxx* anyway.

 How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
 DECLARE_HANDLE() macros?

One of my favourites is HINSTANCE vs HMODULE; both things specify exactly the same entity both in meaning and in underlying type, you sometimes need to pass values you can only acquire as HINSTANCEs to functions expecting HMODULEs, et cetera et cetera.

Which means that if you use typedef's, you'll have to load up the code with lots of casting. Lots of required casting will make it LESS typesafe, not more.
 I'm relatively sure that "cleaning up" this syntax would actually make the
 situation far worse than it currently is.

I agree.
Aug 09 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Which means that if you use typedef's, you'll have to load up the code

 lots of casting. Lots of required casting will make it LESS typesafe, not
 more.

I'm not sure you've all grokked what I was meaning, after all. HINSTANCE and HMODULE are a great case in point. Since, in Win32, they are identical, then they can be used interchangably. So, I'm *not* suggesting this: typedef void *HMODULE; typedef void *HINSTANCE; HMODULE hmod = GetModuleHandle(NULL); // Get our module handle // and use it to create our dialog INT_PTR v = DialogBoxParam(hmod, ...); // Ouch! Compiler error. That would just be totally stupid. Similarly we would not worry about whether something was LPCTSTR or PCSTR, etc. etc. What I'm suggesting is that we homogenise as appropriate. Hence, in the above example, we would define typedef void *HANDLE; typedef void *HINSTANCE; version(deprecated) { alias HINSTANCE HMODULE; // For people who really want to use this } HMODULE hmod = GetModuleHandle(NULL); // Get our module handle // and use it to create our dialog INT_PTR v = DialogBoxParam(hmod, ...); // Works a treat. CloseHandle(hmod); // Compiler error - good!! We would similarly fold all LPCTSTR, LPSTR, LPWSTR, etc. etc. into one type for each distinct "real" type. (This could be whatever we wanted) Now do you see that it would be desirable and workable? Matthew
Aug 09 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh3p3g$304v$1 digitaldaemon.com...
 We would similarly fold all LPCTSTR, LPSTR, LPWSTR, etc. etc. into one

 for each distinct "real" type. (This could be whatever we wanted)
 Now do you see that it would be desirable and workable?

I see your point. But it is still reengineering the Windows API. That's a massive undertaking. There's so much else to be done for D!
Aug 09 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bh45nu$akg$3 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bh3p3g$304v$1 digitaldaemon.com...
 We would similarly fold all LPCTSTR, LPSTR, LPWSTR, etc. etc. into one

 for each distinct "real" type. (This could be whatever we wanted)
 Now do you see that it would be desirable and workable?

I see your point. But it is still reengineering the Windows API. That's a massive undertaking. There's so much else to be done for D!

Yes it is, and yes there is. But we're going to be dependant on it for a very long time, methinks. I would suggest an incremental approach, whereby we maintain a true-typedef version and an alias version. Does D support any kind of namespace preferencing mechanism whereby we could kind of 'include' both, but the resolution of names would favour one (the typedef one) over the other? In this way we could build up gradually.
Aug 09 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 I would suggest an incremental approach, whereby we maintain a

 version and an alias version. Does D support any kind of namespace
 preferencing mechanism whereby we could kind of 'include' both, but the
 resolution of names would favour one (the typedef one) over the other? In
 this way we could build up gradually.

I put my windows headers into win32.* (with `win32.api` as the "entry point") to solve this issue. and masked off any bits that where in phobos with version( STANDALONE ) { ... } but I'm forever having to mask off extra bits as you only get warned about the clashes when you use them. not sure I would actually want a preferencing mechanism local vars hiding globals is enough trouble without worrying that a typedef might change due to the files I import. you might be able to use version = foo; -- win32/api.d -- version( TYPESAFE ) { import win32.typesafe_api; } else { import win32.nt; } --- win32/typesafe_api.d --- version = TYPESAFE; import win32.nt; ---- this way (I believe) you can import win32.api and get either depending on the -version=xxx you give dmd or use import win.typesafe_api; and get the typesafe version always.
Aug 09 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 you might be able to use version = foo;
 -- win32/api.d --
 version( TYPESAFE ) {
     import win32.typesafe_api;
 } else {
     import win32.nt;
 }
 --- win32/typesafe_api.d ---
 version = TYPESAFE;
 import win32.nt;
 ----

 this way (I believe) you can import win32.api and get either depending on
 the -version=xxx you give dmd
 or use import win.typesafe_api; and get the typesafe version always.

I like it! Excellent idea. That way the pedants (that's me) can have the type safety and correctness and the slobs (whomever they may be) can have type-laxity as they choose.
Aug 09 2003
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Mike Wynn wrote:

snip...

 I put my windows headers into win32.*  (with `win32.api` as the "entry
 point") to solve this issue.
 and masked off any bits that where in phobos with version( STANDALONE ) {
 ... }
 but I'm forever having to mask off extra bits as you only get warned about
 the clashes when you use them.

Mike, Thanks for releasing your port of the win32 headers. I was working on a similar effort, but yours seems much more complete and organized than my project. So I'm abandoning my project (for the most part) and I'm going to take advantage of your efforts. I agree that it's a pain how the clashes with windows.d appear one-by-one. If it helps, I've found some more conflicts with phobos from testing some of my example projects using your windows headers. Here are the ones I've found thus far... phobos\windows.d(217-224) conflicts with win32\winbase.d(106-112) phobos\windows.d(572-576) conflicts with win32\winbase.d(1444-1451) phobos\windows.d(555-563) conflicts with win32\winbase.d(1456-1464) phobos\windows.d(577-590) conflicts with win32\winbase.d(1467-1485) phobos\windows.d(263-265) conflicts with win32\winbase.d(2796-2804) phobos\windows.d(144-165) conflicts with win32\winnt.d(33-73) phobos\windows.d(853-862) conflicts with win32\winuser.d(3543-3556) phobos\windows.d(980-1009) conflicts with win32\winuser.d(3660-3690) phobos\windows.d(1049-1084) conflicts with win32\winuser.d(3733-3767) phobos\windows.d: WIN32_FIND_DATA conflicts with win32\ascii.d(58) phobos\windows.d(267): FindClose conflicts with win32\winbase.d(1371) phobos\windows.d(262): CloseHandle conflicts with win32\winbase.d(1374) phobos\windows.d(584): ... conflicts with win32\winbase.d(1479) phobos\windows.d: struct SYSTEMTIME conflicts with win32\winbase.d phobos\windows.d(1201): ... conflicts with win32\winuser.d(2681) phobos\windows.d(1205): ... conflicts with win32\winuser.d(2685) On another note, it might be helpful for some less experienced programmers if you include a batch file (or makefile) that shows how the source can be compiled into a library, such as the one I used ... build.bat --------- dmd api ascii commctrl commdlg ole2 oleextra unicode winbase windef wingdi winnt winuser com\docobj com\exdisp com\extras com\mshtmhst com\oaidl com\objidl com\oleidl directx\directdraw -c lib -c win32.lib api.obj ascii.obj commctrl.obj commdlg.obj ole2.obj oleextra.obj unicode.obj winbase.obj windef.obj wingdi.obj winnt.obj winuser.obj docobj.obj exdisp.obj extras.obj mshtmhst.obj oaidl.obj objidl.obj oleidl.obj directdraw.obj rem Copy into the the LIB directory... copy win32.lib ..\..\lib\win32.lib Justin
Aug 19 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
Cheer,
that's great stuff, I'll hopefully get some time over the weekend to get my
site(s) updated
I think I've done about 70% of what I'd want to use and about 10% of the
headers
the common controls need a bit more work, I don't think I've done anything
on ImageLists

we need a few more ppl porting the other headers and testing more fully what
have been done so far ( and checking that its all up to date with the 2003
SDK)



"J C Calvarese" <jcc7 cox.net> wrote in message
news:bhur9k$m0u$1 digitaldaemon.com...
 Mike Wynn wrote:

 snip...

 I put my windows headers into win32.*  (with `win32.api` as the "entry
 point") to solve this issue.
 and masked off any bits that where in phobos with version( STANDALONE )


 ... }
 but I'm forever having to mask off extra bits as you only get warned


 the clashes when you use them.

Mike, Thanks for releasing your port of the win32 headers. I was working on a similar effort, but yours seems much more complete and organized than my project. So I'm abandoning my project (for the most part) and I'm going to take advantage of your efforts. I agree that it's a pain how the clashes with windows.d appear one-by-one. If it helps, I've found some more conflicts with phobos from testing some of my example projects using your windows headers. Here are the ones I've found thus far... phobos\windows.d(217-224) conflicts with win32\winbase.d(106-112) phobos\windows.d(572-576) conflicts with win32\winbase.d(1444-1451) phobos\windows.d(555-563) conflicts with win32\winbase.d(1456-1464) phobos\windows.d(577-590) conflicts with win32\winbase.d(1467-1485) phobos\windows.d(263-265) conflicts with win32\winbase.d(2796-2804) phobos\windows.d(144-165) conflicts with win32\winnt.d(33-73) phobos\windows.d(853-862) conflicts with win32\winuser.d(3543-3556) phobos\windows.d(980-1009) conflicts with win32\winuser.d(3660-3690) phobos\windows.d(1049-1084) conflicts with win32\winuser.d(3733-3767) phobos\windows.d: WIN32_FIND_DATA conflicts with win32\ascii.d(58) phobos\windows.d(267): FindClose conflicts with win32\winbase.d(1371) phobos\windows.d(262): CloseHandle conflicts with win32\winbase.d(1374) phobos\windows.d(584): ... conflicts with win32\winbase.d(1479) phobos\windows.d: struct SYSTEMTIME conflicts with win32\winbase.d phobos\windows.d(1201): ... conflicts with win32\winuser.d(2681) phobos\windows.d(1205): ... conflicts with win32\winuser.d(2685) On another note, it might be helpful for some less experienced programmers if you include a batch file (or makefile) that shows how the source can be compiled into a library, such as the one I used ... build.bat --------- dmd api ascii commctrl commdlg ole2 oleextra unicode winbase windef wingdi winnt winuser com\docobj com\exdisp com\extras com\mshtmhst com\oaidl com\objidl com\oleidl directx\directdraw -c lib -c win32.lib api.obj ascii.obj commctrl.obj commdlg.obj ole2.obj oleextra.obj unicode.obj winbase.obj windef.obj wingdi.obj winnt.obj winuser.obj docobj.obj exdisp.obj extras.obj mshtmhst.obj oaidl.obj objidl.obj oleidl.obj directdraw.obj rem Copy into the the LIB directory... copy win32.lib ..\..\lib\win32.lib Justin

Aug 20 2003