Re: _SHExpandEnvironmentStrings() should return input string if no % found to expand?

[Hans Leidekker]

On Sunday 24 October 2004 01:35, James Hawkins wrote:
> The reason why I said to ignore this patch is because there has to be
> both an A and   a W version of it.  I'm pretty sure that this cast:

No, I believe this is an exception. I assume that the spec file
is correct in that there are no A and W versions of this function
in shell32, it's just WSCEnumProtocols().
> (PROTOCOL_INFOA *)buffer
> from a LPWSAPROTOCOL_INFOW structure isn't going to work.

No, it will work. The cast probably there because the original author
didn't want to write two functions. Instead he added a bool to the 
internal function that specifies whether the buffer is unicode or 
not. The cast is then needed to keep the compiler happy.
> WSAPROTOCOL_INFO and PROTOCOL_INFO don't even have the same fields:

No, but WSCEnumProtocols() wants WSAPROTOCOL_INFOW structures, just
like WSAEnumProtocolsW(). Quote from MSDN:

int WSCEnumProtocols(
  LPINT lpiProtocols,
  LPWSAPROTOCOL_INFOW lpProtocolBuffer,
  LPDWORD lpdwBufferLength,
  LPINT lpErrno
);

 -Hans

_SHExpandEnvironmentStrings() should return input string if no % found to expand?

[James Hawkins]

> No, it will work. The cast probably there because the original author
> didn't want to write two functions. Instead he added a bool to the
> internal function that specifies whether the buffer is unicode or
> not. The cast is then needed to keep the compiler happy.

The fact that the structures have a string in them is one issue that
you're ignoring.  You can't make a cast from a unicode to an ansi
string just by casting.  You have to call RtlMultiByteToWideChar to
convert it.  The major problem that you're ignoring is that you're
casting from one kind of struct to another, and they aren't the same. 
The cast wont work.  You would have to individually pull out the
relevant fields into a new PROTOCOL_INFO struct like I said in the
last post.  If by original author I'm assuming you're talking about
the author of the spec file.  In which case, there was only one
function in the spec file to begin with, because all functions only
have one in the spec file originally until someone stubs out that
function and finds out that it needs and A and a W...which is why I
didn't want my patch committed.


On Sun, 24 Oct 2004 12:55:32 +0200, Hans Leidekker <hans(a)it.vu.nl> wrote:
> On Sunday 24 October 2004 01:35, James Hawkins wrote:
> > The reason why I said to ignore this patch is because there has to be
> > both an A and   a W version of it.  I'm pretty sure that this cast:
>
> No, I believe this is an exception. I assume that the spec file
> is correct in that there are no A and W versions of this function
> in shell32, it's just WSCEnumProtocols().
> > (PROTOCOL_INFOA *)buffer
> > from a LPWSAPROTOCOL_INFOW structure isn't going to work.
>
> No, it will work. The cast probably there because the original author
> didn't want to write two functions. Instead he added a bool to the
> internal function that specifies whether the buffer is unicode or
> not. The cast is then needed to keep the compiler happy.
> > WSAPROTOCOL_INFO and PROTOCOL_INFO don't even have the same fields:
>
> No, but WSCEnumProtocols() wants WSAPROTOCOL_INFOW structures, just
> like WSAEnumProtocolsW(). Quote from MSDN:
>
> int WSCEnumProtocols(
>   LPINT lpiProtocols,
>   LPWSAPROTOCOL_INFOW lpProtocolBuffer,
>   LPDWORD lpdwBufferLength,
>   LPINT lpErrno
> );
>
> -Hans

-- 
James Hawkins