Problem with INTERNET_BUFFERS under UNICODE

[Fred]

Hi, for "fun" I am trying/testing wininet asynchronous code.

If I compile under UNICODE compile option I can only get
InternetReadFileEx() to work if I "hardcode" to the ANSI Version thus:


char lpReadBuff[256];


INTERNET_BUFFERSA InetBuff;
FillMemory(&InetBuff, sizeof(InetBuff), 0);
InetBuff.dwStructSize = sizeof(InetBuff);
InetBuff.lpvBuffer = lpReadBuff;
InetBuff.dwBufferLength = sizeof(lpReadBuff) - 1;

err0=InternetReadFileExA( g_hRequest,
&InetBuff,
0,
(DWORD)p_rf);

this works returning (1) and accessing the callback function.

If I do:

TCHAR lpReadBuffT[256];

INTERNET_BUFFERS InetBuffX;
FillMemory(&InetBuffX, sizeof(INTERNET_BUFFERS), 0);
InetBuffX.dwStructSize = sizeof(INTERNET_BUFFERS);
InetBuffX.lpvBuffer = (LPVOID)lpReadBuffT;
InetBuffX.dwBufferLength = sizeof(lpReadBuffT) - 1;



err0=InternetReadFileEx( g_hRequest,
&InetBuffX,
0,
(DWORD)p_rf);

Then the function returns (0), the callback function isn't accessed and
GetLastError() gives:

120=INTERNET_STATUS_INTERMEDIATE_RESPONSE


If there isn't a ready fix, is it safe to stick with the ANSI version even
though the prog is compiled under UNICODE?

ie does InternetReadFileEx() just return a byte stream or does it
intrinsically perform some conversions.
I am downloading UTF-8 encoded data.

TIA

[James Brown [MVP]]

Post by Fred
Hi, for "fun" I am trying/testing wininet asynchronous code.
If I compile under UNICODE compile option I can only get
char lpReadBuff[256];
INTERNET_BUFFERSA InetBuff;
FillMemory(&InetBuff, sizeof(InetBuff), 0);
InetBuff.dwStructSize = sizeof(InetBuff);
InetBuff.lpvBuffer = lpReadBuff;
InetBuff.dwBufferLength = sizeof(lpReadBuff) - 1;
err0=InternetReadFileExA( g_hRequest,
&InetBuff,
0,
(DWORD)p_rf);
this works returning (1) and accessing the callback function.
TCHAR lpReadBuffT[256];
INTERNET_BUFFERS InetBuffX;
FillMemory(&InetBuffX, sizeof(INTERNET_BUFFERS), 0);
InetBuffX.dwStructSize = sizeof(INTERNET_BUFFERS);
InetBuffX.lpvBuffer = (LPVOID)lpReadBuffT;
InetBuffX.dwBufferLength = sizeof(lpReadBuffT) - 1;
err0=InternetReadFileEx( g_hRequest,
&InetBuffX,
0,
(DWORD)p_rf);
Then the function returns (0), the callback function isn't accessed and
120=INTERNET_STATUS_INTERMEDIATE_RESPONSE
If there isn't a ready fix, is it safe to stick with the ANSI version even
though the prog is compiled under UNICODE?
ie does InternetReadFileEx() just return a byte stream or does it
intrinsically perform some conversions.
I am downloading UTF-8 encoded data.
TIA

dwBufferLength must be the *length* of the buffer, in TCHARs, not the *size*
of the buffer in bytes, which is what you have specified it to be..

inetBuf.dwBufferLength = sizeof(lpReadBuf) / sizeof(lpReadBuf[0]);

Also here's a shortcut to avoid the FillMemory call:

INTERNET_BUFFERS inetBuf = { sizeof(inetBuf) };


James

[Fred]

Post by James Brown [MVP]

Post by Fred
Hi, for "fun" I am trying/testing wininet asynchronous code.
If I compile under UNICODE compile option I can only get

dwBufferLength must be the *length* of the buffer, in TCHARs, not the *size*
of the buffer in bytes, which is what you have specified it to be..
inetBuf.dwBufferLength = sizeof(lpReadBuf) / sizeof(lpReadBuf[0]);
INTERNET_BUFFERS inetBuf = { sizeof(inetBuf) };
James

Hi,

Nope that didn't fix it.

Here's a ref to a little MS sample which exhibits the problem.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;275046

Now if I run "as is" it works fine.
I hardcode the parameters thus:


char *lpszUrl, *lpszServer;

lpszServer = "www.microsoft.com";
lpszUrl = "";
bVerbose=TRUE;



If I add the preprocessor definitions
UNICODE,_UNICODE

and make the necessary changes to the code to make it compile, eg I just
hardcode the params thus:

TCHAR *lpszUrl, *lpszServer;

lpszServer = L"www.microsoft.com";
lpszUrl = L"";
bVerbose=TRUE;

I get the InternetReadFileEx() failing as per my original post.

The amendment you suggested doesn't fix it.
ie:
TCHAR lpReadBuff[256];

INTERNET_BUFFERS InetBuff = { sizeof(InetBuff) };
InetBuff.dwStructSize = sizeof(InetBuff);
InetBuff.lpvBuffer = lpReadBuff;
InetBuff.dwBufferLength = sizeof(lpReadBuff) / sizeof(lpReadBuff[0]);

Can you or anyone else get it to work?

I've tried it under VC6 and VC7 with the same results

TIA

[Fred]

Post by Fred
Can you or anyone else get it to work?
I've tried it under VC6 and VC7 with the same results

A poster on *.programming.wininet told me the UNICODE version doesn't
work!!!!!!!!!!!!!!

[<ctacke/>]

Does it really need to? I mean it's simply a stream of bytes. Pull it down
with the ANSI method and then convert it device side when needed. In fact
this might be preferable, at it halves the amount of data being transmited,
and a large majority of what's not transferred is a whole lot of nothing
anyway.

-Chris

Post by Fred

Post by Fred
Can you or anyone else get it to work?
I've tried it under VC6 and VC7 with the same results

A poster on *.programming.wininet told me the UNICODE version doesn't
work!!!!!!!!!!!!!!

[Fred]

Post by <ctacke/>
Does it really need to? I mean it's simply a stream of bytes. Pull it down
with the ANSI method and then convert it device side when needed. In fact
this might be preferable, at it halves the amount of data being transmited,
and a large majority of what's not transferred is a whole lot of nothing
anyway.
-Chris

Well it shouldn't be there if it doesn't work :) But I take your point.

But I don't understand how half of the data is transmitted. If it is just a
stream of bytes and UTF-8 encoded, then wont you still get the same raw data
no matter what version of InternetReadFileEx() is used?

[James Brown [MVP]]

Post by <ctacke/>

Post by <ctacke/>
Does it really need to? I mean it's simply a stream of bytes. Pull it

down

Post by <ctacke/>
with the ANSI method and then convert it device side when needed. In fact
this might be preferable, at it halves the amount of data being

transmited,

Post by <ctacke/>
and a large majority of what's not transferred is a whole lot of nothing
anyway.
-Chris

Well it shouldn't be there if it doesn't work :) But I take your point.
But I don't understand how half of the data is transmitted. If it is just a
stream of bytes and UTF-8 encoded, then wont you still get the same raw data
no matter what version of InternetReadFileEx() is used?

Correct, using the ANSI/Unicode version of an API has no bearing on the
underlying data that is being transmitted....any data would be converted
once it had been received.

As to the original problem, without a minimal (compilable) source-listing
that clearly exhibits the problem I doubt you'll get much more help..

James

[<ctacke/>]

Ah, I see. I was assuming you were trying to transmit data as Unicode,
which would be irrelevent.

-Chris

Post by <ctacke/>

Post by <ctacke/>
Does it really need to? I mean it's simply a stream of bytes. Pull it

down

Post by <ctacke/>
with the ANSI method and then convert it device side when needed. In fact
this might be preferable, at it halves the amount of data being

transmited,

Post by <ctacke/>
and a large majority of what's not transferred is a whole lot of nothing
anyway.
-Chris

Well it shouldn't be there if it doesn't work :) But I take your point.
But I don't understand how half of the data is transmitted. If it is just a
stream of bytes and UTF-8 encoded, then wont you still get the same raw data
no matter what version of InternetReadFileEx() is used?