Make no assumptions about your access to the system

Windows 2000 provides a secure operating environment. This means that access controls can be placed on various system resources to restrict users from performing certain operations. For most applications, these issues come up most often when writing data to the file system or the registry. Security is enforced by the Operating system at a low level and typically cannot be circumvented by applications When trying to access data, make no assumptions about your access to the system. You may not have sufficient privilege to do anything but read and must run anyway. The following sections provide some guidelines to help your application avoid system access problems.

• Support running in a read-only environment. Administrators are always looking to tighten up security and reduce complexity for their users. Well, it doesn't get much better than a user inserting your CD, or clicking on an icon pointing to a network share, and the application just starts up and runs the first time and every time - without ever needing to write application data to the local machine at run time.
• Open files and registry keys with minimum access required. Windows 2000 introduces new security settings that make it possible for system administrators to restrict access to most of a machine. You can avoid unneccessary errors in your application by only opening registry keys and files with the minimum access you need to get the job done.
• Handle access-denied errors and degrade gracefully. “Out of memory or disk space” messages are misleading and frustrating to users that know they have lots of both. Many times the application mistakenly assumed it had sufficient access to the registry or file system without actually checking beforehand. Other times the level of error handling is simply deficient to report and handle the event that actually occurred.
• Provide hard-coded defaults for all application settings. Finally, something it's okay to hard-code! Whether it's due to a disk error or an administrator's security settings, you may not be able to depend on access to the registry or local drives. Since your program may not be able to read any settings, you'll need to have usable defaults on hand to fall back on.
• Use GetTempPath to locate appropriate storage for temporary files. In the managed environment, it’s never been good practice to assume your application has sufficient privilege to read and write the local hard drive, or to assume that you know where the system administrator wants temporary storage placed. With the advent of Windows Terminals and thin clients, it’s not even safe to assume there is local storage!