CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 8 of 8
  1. #1
    Join Date
    May 2002
    Posts
    1,798

    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?
    Last edited by Mike Pliam; February 12th, 2013 at 03:23 AM.
    mpliam

  2. #2
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,395

    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?
    Victor Nijegorodov

  3. #3
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Problem with binary Registry I/O

    Mike, you definitely failed to read documentation on the API you use
    ppData

    Points to a pointer that will receive the address of the data
    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.
    Last edited by Igor Vartanov; February 12th, 2013 at 05:41 AM.
    Best regards,
    Igor

  4. #4
    Join Date
    May 2002
    Posts
    1,798

    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.
    Last edited by Mike Pliam; February 12th, 2013 at 03:25 PM.
    mpliam

  5. #5
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Problem with binary Registry I/O

    Quote Originally Posted by Mike Pliam View Post
    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.

    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.

    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?
    Best regards,
    Igor

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    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.

  7. #7
    Join Date
    May 2002
    Posts
    1,798

    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.
    mpliam

  8. #8
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: Problem with binary Registry I/O

    Quote Originally Posted by Mike Pliam View Post
    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.
    Best regards,
    Igor

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured