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

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

"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
type
> 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!

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

>
> 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.
>
not that I've found ...
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.

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

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

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