So make iIndex2 an size_t type, rather than int.
--
Mats
So make iIndex2 an size_t type, rather than int.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I STRONGLY advise you NOT to use sprintf().
sprintf() will crash your app any time the string equals or exceeds the buffer size (if not in the sprintf() the mem corruption will crash it later).
Use _snprintf() with the size set to one less than the buffer size.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
It's many months after the thread has ended, but please let me support the accuracy and reliability of my work which BobS0327 rubbishes.
Regarding your "reputable source", yes, SHQueryValuEx "takes the same parameters" as RegQueryValueEx. It is plainly intended as a "drop-in replacement". However, as noted in my article, it is a replacement with an advantage. It varies the behaviour as described both in my article and (much less comprehensively) in Microsoft's SHLWAPI.H. Certainly, the expansion of environment variables in REG_EXPAND_SZ to be returned as REG_SZ data is easily verified with a test program.
That SHQueryValueEx also null-terminates REG_SZ data is more contentious - not for whether it does, but to what extent and with what deliberation. It's possible that where Microsoft (and your other "registry resources") talk of null-termination, they mean only the matter of how the string data gets stored in the caller's buffer. My analysis goes further, to ask how they deal with poor storage in the registry hive. If your own code did the storage, you might reasonably trust that all your strings are stored properly, but whether you should rely on other programmers "adhering to MS's guidelines" is a whole other question. SHQueryValueEx certainly behaves differently (indeed, better) in these bad cases than does RegQueryValueEx, though I can't say how much of this is due to explicit attention by Microsoft's programmers.
All the differences of behaviour that I describe in that article are carefully demonstrated. It's all open to reproduction. Now, if you know of a failed attempt to reproduce my demonstrations, then I would surely want you to question my accuracy and reliability, but if all you're doing is repeating from sources that obviously haven't even thought to attempt anything like the same depth, then take a little more care, please. Some of us trade on our reputations for checking facts.
On the matter of SHLWAPI versions, you again stress that you have "checked a lot of references" but of what quality and to what end? Although the first appearance of SHLWAPI in a Windows NT release is indeed (the original) Windows 2000, there is a SHLWAPI.DLL in Windows 95 OSR2 and in Internet Explorer 3.01, whatever any number of your references say to the contrary.
Though it is true that SHQueryValueEx is implemented primarily as pre-and-post-processing of calls to RegQueryValueEx which is in turn implemented primarily as pre-and-post-processing of a call to NtQueryValueKey, the idea that RegQueryValueEx and/or SHQueryValueEx "map directly" to any kernel function is entirely fanciful, whatever you think you've seen in a debugger. If nothing else, the kernel's registry functions don't know about the pre-defined keys such as HKEY_LOCAL_MACHINE. So, there has to be some non-trivial code (in ADVAPI32) to translate RegQueryValueEx to NtQueryValueKey - more than enough to defeat the casual inspection of all but experts.
Geoff Chappell
