How can I read data from registry using VC++6

[msole]

Hi,
Does anyone know how to read data fom registry, say data is of type REG_SZ ? Just a simple straight forward code.

Thanks !

Mar :wave:

[Luzhi]

Use this functions, its not complcated

RegOpenKeyEx
RegQueryValueEx
RegCloseKey

[muthuis]

Check this link

http://www.codersource.net/win32_registryoperations.html


Muthu

[Andreas Masur]

Take a look at the following FAQs:

How can I access the registry? (http://www.codeguru.com/forum/showthread.php?s=&threadid=247024)
How can I read data from the registry? (http://www.codeguru.com/forum/showthread.php?s=&threadid=247020)
How can I write data to the registry? (http://www.codeguru.com/forum/showthread.php?s=&threadid=247022)

[Sam Hobbs]

For very simple needs, you can use SHGetValue, as in: char Buffer[50];
DWORD rv, dwType, cbData=sizeof(Buffer);
rv = SHGetValue(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\Windows\\CurrentVersion",
"ProductId", &dwType, Buffer, &cbData);You will need the following header:#include <shlwapi.h>And you will need the shlwapi library for linking; you can modify your project settings for that or put the following in your program:#pragma comment(lib, "shlwapi")Note that SHGetValue requires Internet Explorere to be installed, which is for most versions of Windows. If you include shlwapi.h but the compiler says it can't find SHGetValue, then you might need to put the following at the beginning or your program before all the #include statements:#define _WIN32_IE 0x0400

One final thing. We should always check for errors whenever relevant, as in: LPTSTR lpMsgBuf=NULL;
DWORD Size;
if (rv == ERROR_SUCCESS)
cout << "Windows ProductId: " << Buffer << '\n';
else {
Size = FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL, rv, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR)&lpMsgBuf, 0, NULL);
if (lpMsgBuf) {
cout << "Error reading registry: " << lpMsgBuf;
LocalFree(lpMsgBuf);
}
else
cout << "Unknown error reading registry\n";
}

[Sam Hobbs]

Originally posted by Andreas Masur
Take a look at the following FAQs:

How can I access the registry? (http://www.codeguru.com/forum/showthread.php?s=&threadid=247024)
How can I read data from the registry? (http://www.codeguru.com/forum/showthread.php?s=&threadid=247020)
How can I write data to the registry? (http://www.codeguru.com/forum/showthread.php?s=&threadid=247022) Note that for the "MFC" solution the ATL CRegKey class is used, which is not MFC and does not require MFC. Therefore the CRegKey class can be used in a program without MFC.

[indiocolifa]

using the Windows API.

suppose you want to read three DWORDs from HKEY_CURRENT_USER\Software\MyApp\Config



HKEY hk; // handle to reg key
LONG result; // return values

DWORD dw1, dw2, dw3; // this is data to read
DWORD dwSize = sizeof(DWORD); // size of data

result = RegOpenKeyEx (HKEY_CURRENT_USER, "Software\\MyApp", "Config", 0, KEY_READ, &hk);

if (result != ERROR_SUCCESS)
{
// failed...
}

// read data
RegQueryValueEx (hk, "appdata_1", 0, 0, (BYTE*) &dw1, &dwSize);
RegQueryValueEx (hk, "appdata_2", 0, 0, (BYTE*) &dw2, &dwSize);
RegQueryValueEx (hk, "appdata_3", 0, 0, (BYTE*) &dw3, &dwSize);

RegCloseKey(hk);



hope this helps...

[wey97]

Be sure not to use deprecated API calls like RegOpenKey().

Instead always use RegOpenKeyEx() for win32 and there are a lot more like this.

[Sam Hobbs]

Originally posted by wey97
Be sure not to use deprecated API calls like RegOpenKey().

Instead always use RegOpenKeyEx() for win32 and there are a lot more like this.Is there a particular reason you say that, other than because the documentation says that?

Note that in my copy of VC 6 the MFC source code uses RegOpenKey (not RegOpenKeyEx) in more than a dozen places. This is the type of thing where the Microsoft documentation is not reliable. Some functions, such as WinExec, do seem to be ones to avoid. However there are many that the documentation says should be avoided that are definitely not avoided by Microsoft programmers.

There is another function that the documentation said to avoid that MFC still uses. I forget the exact function, but I wrote a message to MSDN about it. The documentation was changed and the statement saying that the function was obsolete was removed. I don't know if I had anything to do with that happening but at least I noticed that it happened. We should send MSDN feedback saying that MFC still uses RegOpenKey.

[indiocolifa]

yes, and many Microsoft Programming Books are using "obsolete" API functions. See the Clipboard section of Charles Petzold Programming Windows... it uses GlobalAlloc, GlobalUnlock, etc.

[Mick]

RegOpenKey is forwarded to RegOpenKeyEx....so a good reason not to call RegOpenKey(...) rather than RegOpenKeyEx(...) is performance...unless that is you like additional processing.....much again like the Ansi Vs Unicode under NT<->w2k<->xp

[indiocolifa]

may be it's forwarded, but I don't think so it's true for ALL "obsolete" functions (see e.g LoadBitmap is marked as obsolete, and I'm not sure if it "wraps" directly to LoadImage).

[Mick]

Originally posted by indiocolifa
may be it's forwarded, but I don't think so it's true for ALL "obsolete" functions (see e.g LoadBitmap is marked as obsolete, and I'm not sure if it "wraps" directly to LoadImage).

depends, you have to look. Most of the Ex functions do as I recall, simple thing to look though. I wouldn't say go back and re-write your code, just because you got a extended function, but when doing performance tweaks, you should look at it in the least. Any new code should use the newer functionality, there is no reason to use depreciated functions, they may go bye bye duing any OS release though it's highly doubtful they do, but it can happen.

[indiocolifa]

yes, that's true... the fear the many APIs will be vanished in the next OS.

Check out the Longhorn SDK, ... no more APIs?

http://longhorn.msdn.microsoft.com/

[msole]

Hey Guys !
Thanks..I've already got it .

Mar;)

[Mick]

Originally posted by indiocolifa
yes, that's true... the fear the many APIs will be vanished in the next OS.

Check out the Longhorn SDK, ... no more APIs?

http://longhorn.msdn.microsoft.com/

wake me up after they release the first couple of service packs ;)

[Mick]

Originally posted by msole
Hey Guys !
Thanks..I've already got it .

Mar;)

yes we know ;) we are now talking about depreciated api's and usage of....sometimes threads wander based on comments....

[Sam Hobbs]

Originally posted by indiocolifa
it uses GlobalAlloc, GlobalUnlock, etc. Thank you, I am nearly certain that GlobalAlloc is the function I was referring to. In my July 1999 copy of the MSDN the GlobalAlloc documentation says:Note This function is provided only for compatibility with 16-bit versions of Windows.However look at the GlobalAlloc (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/globalalloc.asp) documentation now; it does not say that. Instead, it says:Note The global functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use the heap functions. However, the global functions are still used with DDE, the clipboard functions, and OLE data objects.

[wey97]

Originally posted by Sam Hobbs
Is there a particular reason you say that, other than because the documentation says that?

Note that in my copy of VC 6 the MFC source code uses RegOpenKey (not RegOpenKeyEx) in more than a dozen places. This is the type of thing where the Microsoft documentation is not reliable. Some functions, such as WinExec, do seem to be ones to avoid. However there are many that the documentation says should be avoided that are definitely not avoided by Microsoft programmers.

There is another function that the documentation said to avoid that MFC still uses. I forget the exact function, but I wrote a message to MSDN about it. The documentation was changed and the statement saying that the function was obsolete was removed. I don't know if I had anything to do with that happening but at least I noticed that it happened. We should send MSDN feedback saying that MFC still uses RegOpenKey.
The main reason for using RegOpenKeyEx() is for security, permissions, and access rights beginning with Windows 2000. By deprecated, I don't mean it can't be used, I would guess it just isn't supported or isn't recommended to use (same difference ?!) on anything with a security model (i.e. win2000 or newer).

When you call the RegOpenKeyEx function, the system checks the requested access rights against the key's security descriptor. If the user does not have the correct access to the registry key, the open operation fails. If an administrator needs access to the key, the solution is to enable the SE_TAKE_OWNERSHIP_NAME privilege and open the registry key with WRITE_OWNER access. For more information, see Enabling and Disabling Privileges.

So if your system is win95, 98, or NT it wouldn't matter if you use RegOpenKey() and it may still work on 2000 or XP if you have the appropriate registry permissions before making the function call.

MSDN says the non-Ex functions are only for 16-bit compatibility but that's incorrect because anything before 32-bit win95 didn't have a registry anyway!

[Sam Hobbs]

Originally posted by wey97
By deprecated, I don't mean it can't be used, it just isn't supported on newer systems.Do you know what version of Windows does not support it or are you just guessing that there is a version of Windows that doesn't?

I know that this is a trivial point, but I think it is not trivial when someone says something that is not factual but is instead a guess and yet they don't say it is a guess. If it is true that there is a version of Windows that does not support RegOpenKey then I apologize for dwelling on this minor issue.

However note that (probably nearly all) programs using MFC in versions of VC up to at least version 6 will not be supported by any version of Windows that does not support RegOpenKey.

I agree that it is better to use RegOpenKeyEx, but I just think that people are saying innaccurate things. It is good to say to avoid using RegOpenKey, but the extra stuff that is said to support that is not necessary.

[Mick]

Originally posted by Sam Hobbs

I agree that it is better to use RegOpenKeyEx, but I just think that people are saying innaccurate things. It is good to say to avoid using RegOpenKey, but the extra stuff that is said to support that is not necessary.

well so far I don't see anybody saying anything inaccurate.

EDIT: well let me amend this, why is it that you go the long way around to do something Sam??? your initial post, goes to what I said...lets go so far out of our way to make a call to _RegOpenKeyExA(...)...how about you spend some time understanding the operating system your using...

[Sam Hobbs]

Originally posted by Mick
well so far I don't see anybody saying anything inaccurate.Then answer my question. If you answer my question, then the implication will be the same as what you are saying here. Instead you are being critical but not answering the question.
Originally posted by Mick
EDIT: well let me amend this, why is it that you go the long way around to do something Sam??? your initial post, goes to what I said...lets go so far out of our way to make a call to _RegOpenKeyExA(...)...how about you spend some time understanding the operating system your using... This makes no sense to me. You are just being typically critical. perhaps you don't understand my question and if so then you should say so instead of being so quick to criticize.

[wey97]

Originally posted by Sam Hobbs
This makes no sense to me. You are just being typically critical. perhaps you don't understand my question and if so then you should say so instead of being so quick to criticize.
It seems like you are the one being typically critical, Sam.

[Sam Hobbs]

Originally posted by wey97
It seems like you are the one being typically critical, Sam. I assume then that there is not a version of Windows that does not support RegOpenKey and you are avoiding saying so. You have not been a member long enough to know what is typical.

[wey97]

Originally posted by Sam Hobbs
I assume then that there is not a version of Windows that does not support RegOpenKey and you are avoiding saying so.
If you'll notice I edited my post to include "I would guess" to appease your need for technically precise language. :rolleyes:

You should know just as well as I do that nowhere on MSDN does it say that RegOpenKey is not supported! I thought deprecated functions aren't supported, BUT I COULD BE WRONG.

The point is you need to write code with RegOpenKeyEx to make sure it performs properly on any OS without having to rewrite your app. If you use RegOpenKey on 2000 or XP then the user may not have the appropriate permissions that you can specify with RegOpenKeyEx. I think I've said this before.
Originally posted by Sam Hobbs
You have not been a member long enough to know what is typical.
That comes from the negative reaction I've gotten from you on several of my threads I've posted on this forum. If you can't help with a question, why say anything at all?

[Sam Hobbs]

Originally posted by wey97
If you'll notice I edited my post to include "I would guess" to appease your need for technically precise language. :rolleyes:

You should know just as well as I do that nowhere on MSDN does it say that RegOpenKey is not supported! I thought deprecated functions aren't supported, BUT I COULD BE WRONG.If you make a mistake, then say so. I have.
Originally posted by wey97
The point is you need to write code with RegOpenKeyEx to make sure it performs properly on any OS without having to rewrite your app. If you use RegOpenKey on 2000 or XP then the user may not have the appropriate permissions that you can specify with RegOpenKeyEx. I think I've said this before.Yes, you said that and it is good to warn others about things like that. Then if they choose to use RegOpenKey anyway then they have the option to do that.
Originally posted by wey97
That comes from the negative reaction I've gotten from you on several of my threads I've posted on this forum. If you can't help with a question, why say anything at all? There must be a reason why I make the comments I have. Note that if most of my 10,000 posts were only criticisms, I would not have been allowed to make so many.

[wey97]

Well if all this bothers you that much then I suggest you try to convince Microsoft to change their wording like you did before.

I think we'll all sleep a little easier.

[Mick]

Originally posted by Sam Hobbs
Then answer my question. If you answer my question, then the implication will be the same as what you are saying here. Instead you are being critical but not answering the question.
This makes no sense to me. You are just being typically critical. perhaps you don't understand my question and if so then you should say so instead of being so quick to criticize.

umm let me know when you had a question....

if there every was a sam'ism depreciate was it....


/wey97 right there with you bud.

edit: btw do tell how SHGetValue(...) isn't the long way around town??? do tell, we are hanging on words here...my ears are so perky right now....

[indiocolifa]

Originally posted by wey97
... anything before 32-bit win95 didn't have a registry anyway!

that's incorrect. If i remember correctly, NT 3.51 used a registry like the Win95 reg.

[Andreas Masur]

Originally posted by indiocolifa
that's incorrect. If i remember correctly, NT 3.51 used a registry like the Win95 reg.
Sorry...although you are right in regard to the fact that NT 3.51 used a registry...it came out way after Windows 95...so anything before 32-bit did not have a registry... :cool:

[indiocolifa]

yes you're right...