dbghelp functions are A only

[Vincent Béron]

Hi,

I noticed that dbghelp's functions are only implemented as A variant,
while MSDN says they're available as either Unicode or Ascii variant.
Should we rename the current ones A and create stub W before properly
implementing in W and make the A call the W?

Also, I noticed quite a lot of prototypes in dbghelp.dll from MSDN with
PTSTR or PCTSTR types for strings instead of LPTSTR. Should the
prototype in dbghelp.h and the actual implementation use PTSTR or
LPTSTR?

The origin of all this is because following email from François
yesterday about wineapi_check, I wanted to add the types for each dll in
win32.api to reduce the number of lines emitted by the tool, but I have
questions as to how to do it properly.

Vincent

[Francois Gouget]

On Thu, 7 Oct 2004, Vincent Béron wrote:
[...]
> Also, I noticed quite a lot of prototypes in dbghelp.dll from MSDN with
> PTSTR or PCTSTR types for strings instead of LPTSTR. Should the
> prototype in dbghelp.h and the actual implementation use PTSTR or
> LPTSTR?

TSTR is the same as TCHAR: it's either ANSI or UNICODE depending on 
whether UNICODE is defined or not. Their use is forbidden in Wine.
> The origin of all this is because following email from François
> yesterday about winapi_check, I wanted to add the types for each dll in
> win32.api to reduce the number of lines emitted by the tool, but I have
> questions as to how to do it properly.

Here's a question I meant to ask... What's the purpose of win16.api and 
win32.api? Why do we need them?

[Eric Pouech]

Vincent Béron a écrit :
> Hi,
>
> I noticed that dbghelp's functions are only implemented as A variant,
> while MSDN says they're available as either Unicode or Ascii variant.
> Should we rename the current ones A and create stub W before properly
> implementing in W and make the A call the W?

you shouldn't rename to A (at leat in the .spec files), because, sadly 
enough, MS didn't use for dbghelp the standard A/W naming, but started 
with pure ASCII functions (without any A suffix), and then added unicode 
afterwards.
anyway, I still wonder why you would need unicode for debugging info 
(you would need them for the file names) ? I don't know of a programming 
language with variables outside the 7bit range (at least not for C, C++, 
asm... which are currently supported in debugging)
A+

[Vincent Béron]

Le ven 08/10/2004 à 13:48, Eric Pouech a écrit :
> Vincent Béron a écrit :
> > Hi,
> >
> > I noticed that dbghelp's functions are only implemented as A variant,
> > while MSDN says they're available as either Unicode or Ascii variant.
> > Should we rename the current ones A and create stub W before properly
> > implementing in W and make the A call the W?
>
> you shouldn't rename to A (at leat in the .spec files), because, sadly 
> enough, MS didn't use for dbghelp the standard A/W naming, but started 
> with pure ASCII functions (without any A suffix), and then added unicode 
> afterwards.

You know better than me. I only noticed in MSDN that those functions
were available as both Ascii and Unicode variant. And as MSDN doesn't
document the A or W version but only the postfix-less variant with
TCHARs, it's a bit difficult for me to judge how this should be handled.
> anyway, I still wonder why you would need unicode for debugging info 
> (you would need them for the file names) ? I don't know of a programming 
> language with variables outside the 7bit range (at least not for C, C++, 
> asm... which are currently supported in debugging)

I have no idea for which languages this would be needed, only that it
looks like it's provided by MS and our implementation looked (at first
look) different.

Vincent