WinHttp problems

[liut]

Hi, recently I meet 2 strange problems when using WinHttp functions to get the configuration info of internet proxy.

1) WinHttpOpen: I create a program in WinXP 32bit/PellesC 6.5 env. with the code below, no problem when running in this env., but after I copy the execute file (32bits code) to Win7 64bits env., I always gets error "Insufficient buffer".
hs=WinHttpOpen((LPCWSTR)"GetProxyInfo",WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,WINHTTP_NO_PROXY_NAME,WINHTTP_NO_PROXY_BYPASS,0);

2) WinHttpGetProxyForUrl: I created a completed function to get all proxy info (WPAD or PAC script) by using these WinHttp functions. When I put this self-defined function at the beginning of the source code, and call it immediately at the beginning of WinMain, no problem is found and all info can be retrieved; but as my program has some other functions to get other info (all these functions run very well), if I but this self-defined function at the middle of the program, or call it at the middle of the WinMain after other calling, when running at this WinHttp function, I always get error 12166...
WinHttpGetProxyForUrl(hs,L"http://www.microsoft.com",&ProxyOptions,&ProxyInfo);

I fully follow the instruction of MSDN and API SDK to coding. I doubt there is something wrong in the lib winhttp.lib. Does anybody have ideas of the problems?

[CommonTater]

1) WinHttpOpen: I create a program in WinXP 32bit/PellesC 6.5 env. with the code below, no problem when running in this env., but after I copy the execute file (32bits code) to Win7 64bits env., I always gets error "Insufficient buffer".
hs=WinHttpOpen((LPCWSTR)"GetProxyInfo",WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,WINHTTP_NO_PROXY_NAME,WINHTTP_NO_PROXY_BYPASS,0);

1) Use #define UNICODE at the top of your source code.
2) hs = WinHttpOpen(L"GetProxyInfo",...

That may not fix all your problems but it should get you one step closer.

2) WinHttpGetProxyForUrl: I created a completed function to get all proxy info (WPAD or PAC script) by using these WinHttp functions. When I put this self-defined function at the beginning of the source code, and call it immediately at the beginning of WinMain, no problem is found and all info can be retrieved; but as my program has some other functions to get other info (all these functions run very well), if I but this self-defined function at the middle of the program, or call it at the middle of the WinMain after other calling, when running at this WinHttp function, I always get error 12166...
WinHttpGetProxyForUrl(hs,L"http://www.microsoft.com",&ProxyOptions,&ProxyInfo);

I fully follow the instruction of MSDN and API SDK to coding. I doubt there is something wrong in the lib winhttp.lib. Does anybody have ideas of the problems?

For this we're going to have to see your code...  If you look in the Project menu you will find an option to zip your project files...  Zip them up and attach them to a message here.

[liut]

Hi, I think I found the cause. Originally I wrote the code as below:

WinHttpOpen((LPCWSTR)"GetProxyInfo",...)

Now I change it to:

WinHttpOpen(L"GetProxyInfo",...)

Everything suddenly works afterwards! I think I misunderstood the "unicode" arguments and ignored the importance. I guess the previous usage caused wrong size of the string and then caused unexpected memory overflow.

BTW, I don't define UNICODE. I tried it, but it causes more errors: each ASCII string argument would bring an error of type. I have to spend more time to study the UNICODE programming... 

Thank you again for your help!

[CommonTater]

Hi, I think I found the cause. Originally I wrote the code as below:

WinHttpOpen((LPCWSTR)"GetProxyInfo",...)

Now I change it to:

WinHttpOpen(L"GetProxyInfo",...)

Everything suddenly works afterwards!

... because you cannot typecast a char array to wchar, they're different sizes. 

You have to actually hand the function a wide character array, which is what the L does... it tells the compiler "this is a wide string".

I think I misunderstood the "unicode" arguments and ignored the importance. I guess the previous usage caused wrong size of the string and then caused unexpected memory overflow.

BTW, I don't define UNICODE. I tried it, but it causes more errors: each ASCII string argument would bring an error of type. I have to spend more time to study the UNICODE programming... 

It's only a problem if you don't adjust your coding to it. When you #define UNICODE at the top of your source page (before including anything) you fundimentally change the way Windows handles strings... Any function that normally takes a CHAR now needs WCHAR or TCHAR.  So you change everything you do over to wide strings... Don't mix them together, use excusively one or the other.
 
Windows also has a series of string handling functions that are "agile" in that when you define UNICODE they switch with the functions... lstrcpy(), lstrcat() etc. can be found in the windows api documentation.
 

Thank you again for your help!

No worries....
 

Edit:
Since nobody writes ascii anymore, I'm attaching a really basic unicode editor example that should help you get started with unicode....
 
 

[liut]

Thanks for your program. I tried it. But I find the unicode for Chinese is totally different from the Windows default. I created 2 txt files for the word "我们" by using TinyEditor and Notepad, both sizes are 4-bytes,  but the hex codes are:
11 62 EC 4E (TinyEditor)
CE D2 C3 C7 (Notepad)

I think unicode string can't be shown by windows directly, and there should be some functions to convert Unicode string to "readable" string... Char's encoding become complicated...

[CommonTater]

The difference you are seeing is that there are several "flavours" of unicode.

Windows uses UTF16-LE ... that is 16 bit characters in little endian format.
Other formats are UTF16-BE, UTF32-LE, UTF32-BE, UTF8 ...

The internet runs dominantly on UTF8 because it's very efficient and relatively easy to convert to an operating system's internal unicode formats.

FWIW... Windows is internally unicode (utf16le) when you are working with char strings it has to internally convert them to unicode before it uses them.  (Same with Pelles C, btw.)

Give this a read ... http://msdn.microsoft.com/en-us/library/windows/desktop/dd374081(v=vs.85).aspx