Bug caused by sloppy programming [modified]
-
bool ProcessRegistryValue()
{
DWORD dwValue = 0;CRegKey key;
if (key.Open(HKLM, TEXT("Software\\Company\\Product")) == ERROR_SUCCESS)
{
if (key.QueryDWORDValue(TEXT("SomeValue"), dwValue) == ERROR_SUCCESS)
{
//Use the dwValuereturn true; }}
return false;
}//From some code
if (ProcessRegistryValue())
{
//Do some cool stuff
}
else
{
//Highly unexpected that the func will fail
//Suppress cool stuff and inform the user
}The registry value was written by the installer. The code worked for a few years without any issues and then one day a user got issues. The application was not doing cool stuff which some other users saw. -- modified at 12:05 Wednesday 27th September, 2006
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
-
bool ProcessRegistryValue()
{
DWORD dwValue = 0;CRegKey key;
if (key.Open(HKLM, TEXT("Software\\Company\\Product")) == ERROR_SUCCESS)
{
if (key.QueryDWORDValue(TEXT("SomeValue"), dwValue) == ERROR_SUCCESS)
{
//Use the dwValuereturn true; }}
return false;
}//From some code
if (ProcessRegistryValue())
{
//Do some cool stuff
}
else
{
//Highly unexpected that the func will fail
//Suppress cool stuff and inform the user
}The registry value was written by the installer. The code worked for a few years without any issues and then one day a user got issues. The application was not doing cool stuff which some other users saw. -- modified at 12:05 Wednesday 27th September, 2006
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Rama Krishna Vavilala wrote:
if (key.QueryDWORDValue(TEXT("SomeValue"), dwValue))
QueryDWORDValue() returns ERROR_SUCCESS if it works. ERROR_SUCCESS is zero, so the if() test fails if the call succeeds. Oh sure, modify your post so the bug is not so obvious. Now I have to start all over:doh:
Last modified: 4mins after originally posted -- Rama's mod made this post obsolete
You may be right I may be crazy -- Billy Joel -- Within you lies the power for good, use it!!!
-
Rama Krishna Vavilala wrote:
if (key.QueryDWORDValue(TEXT("SomeValue"), dwValue))
QueryDWORDValue() returns ERROR_SUCCESS if it works. ERROR_SUCCESS is zero, so the if() test fails if the call succeeds. Oh sure, modify your post so the bug is not so obvious. Now I have to start all over:doh:
Last modified: 4mins after originally posted -- Rama's mod made this post obsolete
You may be right I may be crazy -- Billy Joel -- Within you lies the power for good, use it!!!
Sorry Nish pointed that out. The QueryDwodValue is not the issue it was a typo.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
-
bool ProcessRegistryValue()
{
DWORD dwValue = 0;CRegKey key;
if (key.Open(HKLM, TEXT("Software\\Company\\Product")) == ERROR_SUCCESS)
{
if (key.QueryDWORDValue(TEXT("SomeValue"), dwValue) == ERROR_SUCCESS)
{
//Use the dwValuereturn true; }}
return false;
}//From some code
if (ProcessRegistryValue())
{
//Do some cool stuff
}
else
{
//Highly unexpected that the func will fail
//Suppress cool stuff and inform the user
}The registry value was written by the installer. The code worked for a few years without any issues and then one day a user got issues. The application was not doing cool stuff which some other users saw. -- modified at 12:05 Wednesday 27th September, 2006
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
The call to
key.Openrequests KEY_WRITE access by default, which will fail on some PCs as the user won't necessarily have Administrator rights (not to HKEY_LOCAL_MACHINE anyway!). I have been bitten by this in the past too.
Kicking squealing Gucci little piggy.
-
The call to
key.Openrequests KEY_WRITE access by default, which will fail on some PCs as the user won't necessarily have Administrator rights (not to HKEY_LOCAL_MACHINE anyway!). I have been bitten by this in the past too.
Kicking squealing Gucci little piggy.
Yes.:) Started happening after users moved to XP. Actually in the original code, HKEY_CLASSES_ROOT was causing the problem. The default security for HKCR in Windows 2000 was more permissive than in XP.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
-
Yes.:) Started happening after users moved to XP. Actually in the original code, HKEY_CLASSES_ROOT was causing the problem. The default security for HKCR in Windows 2000 was more permissive than in XP.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Rama Krishna Vavilala wrote:
The default security for HKCR in Windows 2000 was more permissive than in XP.
More likely that the user was a member of the Power Users group. I'm pretty sure that Windows 2000 and XP have the same permissions for Users. HKEY_CLASSES_ROOT, as of Windows 2000, is not really a root key. It's actually a merged view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes. The data under HKCU does not roam for a roaming profile, it's specific to the machine. HKCU overrides HKLM. Too few programs take advantage of this: Windows Media Player, for example, simply hides the 'File Types' tab if the user isn't an administrator, rather than writing the user's preferences to HKCU\Software\Classes.
Stability. What an interesting concept. -- Chris Maunder
-
Rama Krishna Vavilala wrote:
The default security for HKCR in Windows 2000 was more permissive than in XP.
More likely that the user was a member of the Power Users group. I'm pretty sure that Windows 2000 and XP have the same permissions for Users. HKEY_CLASSES_ROOT, as of Windows 2000, is not really a root key. It's actually a merged view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes. The data under HKCU does not roam for a roaming profile, it's specific to the machine. HKCU overrides HKLM. Too few programs take advantage of this: Windows Media Player, for example, simply hides the 'File Types' tab if the user isn't an administrator, rather than writing the user's preferences to HKCU\Software\Classes.
Stability. What an interesting concept. -- Chris Maunder
Might have been. It's been a long time since the bug got fixed
Mike Dimmick wrote:
Too few programs take advantage of this
Ahem.. http://www.codeproject.com/w2k/regsvrex.asp[^] :)
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
