Re: VerQueryValue[A|W]

[François Jacques]

James,

Where's HEAP_strudupAtoW called from? 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)

For all OLE/COM DLLs, I would internally store the strings as OLECHAR*
strings (or BSTR, as you wish...) wherever it makes sense to do it, e.g.
most places.

Cheers,
Francois

-----Message d'origine-----
De : James Hatheway 
À : [e-mail] 
Cc : WineHQ Devel 
Date : 15 février, 2001 10:44
Objet : Re: VerQueryValue[A|W]
> > > To convert an ASCII string to Unicode, you can use the
> > > function HEAP_strdupAtoW, as in:
> >
> > Wrong ;-)
>
> Yeah, I know, Huw already set me straight on that. ^_^
> > HEAP_str* is deprecated (the header file says so).
> > Use MultiByteToWideChar() or WideCharToMultiByte() instead.
>
> I'll admit I wrote the email when my brain wasn't quite
> working (by def'n anytime after 1am), thought to
> myself "what is that API again?", did a quick search in
> WINE, said to myself "oh HEAP_strdupAtoW"
> sent a quick email and went to bed. :)  That teaches me to
> send email without thinking.
>
> But that gets me to my point.  HEAP_strdupAtoW is used in
> this capacity 78 times in the WINE source tree (WtoA another
> 182 times).  We should probably change it sometime, since a
> lot of people who are writing new code are sure to use
> the current code base as an example of "how to do things".
>
> Out of curiosity, why are we killing these macros?  They
> seem quite convenient.  If it is because they aren't in
> standard windows headers, can't we put them somewhere
> in include/wine?
>
> -James
>
> --
> James Hatheway
> Software Designer - Macadamian Technologies, Inc.
> [e-mail] ~ http://www.macadamian.com
>
> "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"

VerQueryValue[A|W]

[James Hatheway]

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

--
James Hatheway
Software Designer - Macadamian Technologies, Inc.
[e-mail] ~ http://www.macadamian.com

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