I've been active in the DC community for quite some time now (I co-develop NextHub), and I just stumbled onto ApexDC++ not too long ago after using StrongDC++ for a while. I quite like it, but I have one gripe. Currently, the settings are stored in the Settings directory inside the install directory. I noticed not too long after I began using it that I was experiencing some strange errors. When I closed the hub, it would always ask me if I really wanted to close it even though I repeatedly told it to remember my decision. Then I noticed that I was getting the popular "Error saving hash data" error. I instantly recognized the problem, ran it as administrator, and voila, the problem is fixed. The problem is that the settings are being stored in the install directory. The installer naturally installs to %PROGRAMFILES(X86)% (I'm running Windows 7 64-bit Pro). This is fine because that's where it should install. However, administrator access is needed to write to that directory. This isn't a problem during installation, but it is when the settings need to be written/updated. As a computer scientist, I recognized this right away. However, other users on the hubs that I recommend didn't understand why their settings weren't being stored properly. There are 3 solutions to this problem: - Run the program as administrator at all times (as recommended at http://forums.apexdc...cess-is-denied/). - Install the program elsewhere (perhaps to C:\ApexDC++). - Save the settings in the correct location (%appdata%\ApexDC++). I was shocked to see that a project manager is actually recommending running the program as administrator at all times. This is terrible advice and should absolutely not be carried out because it sets a bad precedent for other developers/users (it's a terrible security hole). The 2nd solution might be more viable if it were the default install location for the installer, but it's not. Most users will install a program to the default location given in the installer, and it's expected that the program should fully function from this location. Installing to the root directory is bad practice anyway, so this really isn't a great solution either. The third solution is the most appropriate. The program is indeed installed to program files, and the settings are stored in a local user directory where the user is guaranteed to have write access. The reason I have placed this thread in bugs is because it really is a bug and needs to be fixed. I hope the developers understand this problem and why changing the settings to %appdata% is the only real solution here. Thanks for the solid software, and I look forward to this being fixed in the future.