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