Problem with binary Registry I/O
I have used the following code to attempt to place a binary array into and then retrieve from the Registry. I am a member of the local Administrator group. I have verified that the Registry for the app has a binary array 32 bytes in length under the key "settings" / "keyb" ab 12 cd ...
Code:
// in header
unsigned char m_key[32];
int m_nKeySize;
// in implmentation
// int ctor
AfxGetApp()->GetProfileBinary(_T("settings"), _T("keyb"), (LPBYTE*)&m_key, (UINT*)&m_nKeySize);
// in OnDestroy
AfxGetApp()->WriteProfileBinary(_T("settings"), _T("keyb"), (LPBYTE)&m_key, m_nKeySize );
Here is a copy of the binary array in the Registry:
7D DE 2B 30 E7 06 12 AC 99 60 8C 26 21 FC 8E 5B 66 DB 72 9E A2 00 BE 15 E1 8B 67 31 E5 EC 8B 15
Here is the binary key retrieved from the Registry using the code above:
D0 EB 26 00 CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC
What am I doing wrong here?
Re: Problem with binary Registry I/O
In ctor of what class do you read from registry?
What does GetProfileBinary return?
What is the value of m_nKeySize after GetProfileBinary returns?
Re: Problem with binary Registry I/O
Mike, you definitely failed to read documentation on the API you use
Quote:
ppData
Points to a pointer that will receive the address of the data
Quote:
Note
GetProfileBinary allocates a buffer and returns its address in *ppData. The caller is responsible for freeing the buffer using delete [].
So having this
Code:
D0 EB 26 00 CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC
you should understand the first four bytes as a LPBYTE pointer to the data you need.
Mike, you should be very careful with any API you unfamiliar with, and read docs prior to posting questions here.
Re: Problem with binary Registry I/O
I confess that the syntax is confusing to me. But after fooling with it for awhile, bearing in mind Igor's remarks, I came up with this that works:
Code:
unsigned char * pbkey;
//AfxGetApp()->GetProfileBinary(_T("settings"), _T("keyb"), (LPBYTE*)m_key, (UINT*)&m_nKeySize);
AfxGetApp()->GetProfileBinary(_T("settings"), _T("keyb"), &pbkey, (UINT*)&m_nKeySize);
for(int i = 0; i < m_nKeySize; i++) { TRACE1("%0.2x ", pbkey[i]); m_key[i] = pbkey[i]; } TRACE0("\n");
delete [] pbkey; pbkey = NULL;
Please note that m_key is a declared member variable (CMyDlg::m_cKey - unsigned char m_key[32]), I am unclear as to where the memory for the byte pointer pbkey is allocated and whether or not it needs to be deallocated. Edit: Apparently it does because without deleting it there is a memory leak which is eliminated by deleting pbkey. One wonders how large a binary can be thus stored and retrieved from the Registry. Interestingly, if the end user is not a member of the Local Administrator Group, there appears to be no way to store binaries in a PrivateProfile *.ini file (tediously worked around by using CStrings and reformating to binary)
Victor, the m_nKeySize returns as 32 which is correct. Also notable is that I cannot seem to use m_key in place of pbkey, or I have not figured out how to make that work (which would be simpler than dealing another pointer variable, pbkey), since in my particular instance, the length of the Registry binary will ALWAYS BE 32.
Re: Problem with binary Registry I/O
Quote:
Originally Posted by
Mike Pliam
I confess that the syntax is confusing to me. But after fooling with it for awhile, bearing in mind Igor's remarks, I came up with this that works:
Code:
unsigned char * pbkey;
//AfxGetApp()->GetProfileBinary(_T("settings"), _T("keyb"), (LPBYTE*)m_key, (UINT*)&m_nKeySize);
AfxGetApp()->GetProfileBinary(_T("settings"), _T("keyb"), &pbkey, (UINT*)&m_nKeySize);
for(int i = 0; i < m_nKeySize; i++) { TRACE1("%0.2x ", pbkey[i]); m_key[i] = pbkey[i]; } TRACE0("\n");
delete [] pbkey; pbkey = NULL;
Please note that m_key is a declared member variable (CMyDlg::m_cKey - unsigned char m_key[32]), I am unclear as to where the memory for the byte pointer pbkey is allocated and whether or not it needs to be deallocated.
Considering the way how it is to be deleted, allocation occurs in GetProfileBinary by means of new [], allocation is on-heap byte array of m_nKeySize bytes, and the array address is assigned to pbkey pointer.
Quote:
Also notable is that I cannot seem to use m_key in place of pbkey,
Of course you cannot, as the method semantic implies that allocation occurs inside GetProfileBinary, and you are not allowed to provide your own buffer for receiving the binary key value.
Quote:
or I have not figured out how to make that work (which would be simpler than dealing another pointer variable, pbkey), since in my particular instance, the length of the Registry binary will ALWAYS BE 32.
This is what you know, but Windows registry never knows that, and it always must be ready to ingest data of any size.
Looking at your code I cannot figure out what's wrong with storing your key as REG_SZ? Why binary?
Re: Problem with binary Registry I/O
Why not REG_SZ ?
REG_SZ is technically unicode, while this string appears to be non-unicode (it could be actual binary or it could be ansi).
writing an ansi string may result in an unwanted conversion to unicode and a subsequent incorrect conversion back to ansi if the writing app and the reading app are run under different code pages
If the data is actually binary but just happens to binary appear similar to your current code page. then you could mess up things reading it back and expecting to get the same binary values.
Re: Problem with binary Registry I/O
Why store as binary rather than REG_SZ? Actually, I've done both because I had to since I couldnt get REG_BINARY working as I've noted. In fact, you are right, REG_SZ can be converted to binary with a bit of effort. First I thought it would be easier to use REG_BINARY directly. As it turns out, that is not the case. But still, I was curious as to how to use REG_BINARY. Thanks to you guys, I now understand how it works. Thank you.
Re: Problem with binary Registry I/O
Quote:
Originally Posted by
Mike Pliam
First I thought it would be easier to use REG_BINARY directly. As it turns out, that is not the case.
Actually I still don't understand what was your problem other than not reading MSDN and MFC sources. Ultimately, what GetProfileBinary does is straightforward, plain, dull, old school C++. In case you don't like MFC way, you always can go with ATL::CRegKey or even with pure RegQueryValueEx.
BTW, CRegKey::QueryBinaryValue does exactly what you want, as it uses the buffer allocated by the caller. :)
