I primarily develop on Linux where there is /usr/bin and /bin directories. I know that Windows does not have any real equivalent of either of these besides C:\Windows and C:\Windows\System32. Many command line programs that I port to windows, I simply will write an installer that will copy them to C:\Windows, because I do not feel like having to set a PATH variable. I know that the proper way is to set a PATH variable, but to me C:\Windows is == to /usr/bin. What do Windows programmers have to think about this? Is this a good habit, is there any real disadvantages, and should I actually install to Programs Files and set a path variable via the registry instead?
2 回答
Install to Program Files (or even the user's AppData folder for user-specific installs), and provide an option to add the directory to %PATH%
.
Installing to Program Files has a number of advantages:
- Won't conflict with any other files that happen to be in C:\Windows
- Won't override some other tool already on the user's PATH
- Makes the components of your program more obvious, instead of a random scattering of files in C:\Windows
- Avoids dependency conflicts (DLL hell) if you need to include your own DLLs
Giving users the option to add to %PATH%
allows users to skip that step if they run into some other kind of conflict with your app (which is less likely with Program Files, but still possible). If you installed into C:\Windows, you'd have no way to avoid such conflicts.
You should install applications to the proper Program Files directory, generally; there are exceptions though. And there are numerous Environment Variables already set for numerous paths on Windows, %PROGRAMFILES%
being one of them (and %PROGRAMFILES(X86)%
being another, hence 'appropriate' path).