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
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@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
-
Hans Leidekker -
James Hawkins