I'm wondering what the thoughts are on using the Windows Registry.
In our application we store the data path, current build, and some other system information in the HKEY_CURRENT_USER hive of the registry. One of the things this allows us to keep the local copy of the executable in synch with the version that is stored on the file server. This way, to upgrade the application, all that needs to be done is to copy the executable to the server, then as each client starts the local copy of the application, it checks version information and will update the local copy of the application as needed.
We currently have a customer that is complaining about this. They don't allow users access the the registry at all, even the HKEY_CURRENT_USER hive. So our implementation is causing them problems. Obviously, we can redesign our application not to use the registry, but the rest of our customer base have no issues with this.
What are some of your thoughts on Windows Registry Security, and what is the purpose of the HKEY_CURRENT_USER hive?
I don't use the Registry. One obvious reason is the one you mention, where some organizations lock the Registry for security reasons.
Another reason is that the Registry is bloated as it is in many PCs and I don't want to add more bloat to it.
You could, should you decide not to use the Registry, use an INI file or an XML file instead for setup information. -- Alex Feldstein
Not allowing users have even read access to the registry is stupid. Only allowing write access to admin or power users is fine, they would then need to log in as such to upgrade your application if that upgrade needs to update the registry. Using an XML file is a good idea for some settings, although of course it is easily changeable with a text editor. -- Alan Bourke
I would create a settings file (INI, XML or DBF) in the same directory as your application's data files are stored. The registry is more apt to be corrupted since it is open all the time, versus an INI file that is opened only at the start of your application.
Also, I am a big fan of limiting the scope of an application on the hard drive so that it's impact on other apps or system functions is limited and debugging any problems is easier. That means only using the Program Files folder, individual user's Application Data folder, and All Users Application Data folder (if possible). -- Ben Creighton
I agree with both Ben and Alex. Further it's really easy to compare the version # of two different .EXE files.
IF laFirstEXE # laSecondExe
*Get the new version
-- Mike Yearwood
Although I agree that using the registry for checking versions probably isn't the best idea, I do like to use the registry for storing registration keys for the application. Unlike information stored in an INI file or a DBF, it's not as likely the user is going to find it and start hacking the key. Whether I use HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE depends on whether or not the client want to license the app for a user or for the machine. -- Barbara Peisch
That's fine Barbara, but it is not any more secure that any other storage file. Security by obscurity does not gain you anything. If the user is sophisticated enough, and it doesn't take much, they know how to find a reg key. If your key is properly encrypted there's nothing to fear. If they still find it and change or delete the key, their program stops working. Simple as that. So, why would they mess with it? If a malicious or stupid user does it, they must call for a replacement key, just as with a new HD reinstall. First key generation is free. If they do it again, start charging for the hassle. You'll see how fast the boss stops the shenaningans. -- Alex Feldstein
For years we have been storing information in an INI file. Our INI file is simply a mem file containing a single strong. Embedded in that string, and it changes with each new version, are codes indicating whether they are running in "demo" mode or if it is a live version. The great thing about the INI file is it is not deleted if they uninstall and re-install in an attempt to bypass the 30 day trial period. Include in our EXE are the locations and keys that it looks for in the MEM file disguised as an INI file. This seems like a much easier to administer option than the registry, which we considered but opted not to mess with because of the alarms we might set off. -- John J. Fatte'
I'll chip in here too. It has long been my view that using the registry for application specific items is a major cause of the registry bloat that Alex referred to. The primary purpose of the registry is to register things that need to be available system wide so that applications can find them by looking in one place. Application specific data (settings, preferences, registration keys etc) does NOT fall into this category and should, in my humble opinion, not be in the registry. -- Andy Kramek
Well, I ended up here almost by accident, but since this is one of my pet peeves, I'll chime in. I agree that the registry should be avoided. Microsoft itself is moving away from using it so much and I believe that I've heard them cast doubt on whether it was such a great idea to begin with. As John F. mentioned, any app settings stored in the registry get blown away when the OS is upgraded/reinstalled/whatever. I use a USER_PROP table in the main data folder and so when a machine is upgraded or replaced, it has no effect on my app and the user loses no settings (form size and position, last record accessed in each table, column positions and widths in grids, etc.). I think the registry has some legitimate reasons to exist, but the desire on the part of this industry to use it to store all application settings just because we can is misguided. Application settings usually belong with the app to insulate it from upgrades and machine replacements (of course, this applies mostly to network-based apps, since any app running on the local hard drive will get wiped out if the machine is replaced or the hard drive is reformatted and everything from the OS on up gets reinstalled). Russell Campbell
This should probably be moved somewhere better, but I was looking for a simple way to read registry entries using VFP (without having to build in the ffc classes etc.) and found this: How to use the Windows Script Host to read, write, and delete registry keys. In summary:
local loWSH as wscript.shell
loWSH = createobject("wscript.shell")
Hope that helps someone, Tom
Pavel Celba - Above code does not work in Vista and W7 - you have to call Windows API instead
Look at this code
Category Open Questions
( Topic last updated: 2011.08.31 05:06:32 PM )