James Hatheway james at
Fri Feb 16 08:07:56 CST 2001

Hi Francois,

Haven't heard from you in a while? How are
things shaking?  The Geek corner isn't the
same without you! ^_^

> Where's HEAP_strudupAtoW called from?

All over the place, not just in OLE/COM DLLs.
advapi32, commdlg, winspool, etc.  Basically,
anywhere where the functionality in a DLL is implemented
in the W version, and the A version is converting
to widechar and calling into W could have a call.

> For all OLE/COM DLLs, strings should
> be internally stored as OLECHAR* (wchar_t*) strings. I remember it wasn't
> the case with typelib.c when I started playing with it. A side-effect of
> that is that we had to HEAP_strdupAtoW / HEAP_strdupWtoA all over the place
> in that file - making ASCII-based stored strings more expensive than
> OLECHAR*-based strings (yeah yeah we're still converting back to ASCII
> strings a lot, but that's for tracing - not run-time)

True, storing as OLECHAR* makes sense.  The thing is, that
both HEAP_strdupAtoW and MultiByteToWideChar both return
wchar_t*.  The difference is that HEAP_strdupAtoW
does somethings like NULL ptr checks, memory allocation, etc.
for you.  Its basically a convenience function to MultiByteToWideChar.
Its in include/heap.h.  So even in COM/OLE DLLs you can
s/HEAP_strdupAtoW/MultiByteToWideChar boiler plate code/g
without any harm or change in functionality.

For the record, the reason why these macros are being phased
out is because it breaks DLL seperation.  Thanks to
Uwe for the info.


James Hatheway
Software Designer - Macadamian Technologies, Inc.
james at ~

  "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
  "One could be happy if the air were as pure as the beer"

More information about the wine-devel mailing list