Why do program files go into the Program Files directory?


Some of Microsoft's software certification programs (such as the Windows Logo) require that applications set their default installation location to the Program Files directory. What is the reason for this?

One technical reason is that this ensures that the directory receives an appropriate default security descriptor. But the Program Files directory was introduced in Windows 95, which didn't have security descriptors, so that can't be the entire reason.

Rewind the clock to Windows 3.1. Microsoft didn't provide guidance on where applications should install by default. As a result, they went everywhere. Some installed into the root of your C: drive. Some installed to a C:\LitWare directory. Some installed into the Windows directory. It was total chaos.

Program Files was introduced in an attempt to bring order to chaos. Think of it as painting lines in a parking garage.

Bonus chatter: I recall an application compatibility investigation from the Windows 95 days. After you installed a particular program, it refused to run. This was clearly a serious problem, even more so when you realized that the program in question was a very popular commercial program. Eventually the source of the problem was identified: When you installed the program, you must accept the default installation location. If you tried to install the program somewhere else, it refused to run. The problem was not caused by Windows 95; you had the same problem if you installed the program on Windows 3.1 to a non-default directory.

Comments (74)
  1. WndSks says:

    It would also be nice if MS would follow the "program filescompanyproduct" layout and not just clutter the program files root with new folder(s) for each installed product…

    [Wait, so you're saying that Microsoft should ignore its own guidelines? -Raymond]
  2. Adam Rosenfield says:

    @WndSks: I don't mind the fact too much that each Microsoft program has its own directory within Program Files; what does annoy me is that each directory begins with "Microsoft" ("Microsoft Office", "Microsoft SDKs", "Microsoft Visual Studio 10.0", etc.).

    This makes it require excessive typing when trying to navigate to one of those directories by keyboard — instead of just typing "v" and a couple of letters or up/down strokes to get to Visual Studio, I have to type "microsoft v" to get there (or type "n" and go up many times).

    So actually I take it back, putting all of that in a Microsoft directory would be great, if they also removed the Microsoft prefix from the product subdirectories.

  3. AdamWu says:

    I remember for a couple of versions of Office, it uses hard coded short name "progra~1" in the registry, so that if the "program files" directory happens to have "progra~2" as its short name, a lot of things fail to work.

  4. P Wright says:

    I wonder what readers of this blog think about Google Chrome's default (i.e., non-MSI) installer installing into %APPDATA%. Always felt 'wrong' to me.

  5. Bob Hir says:

    I was under the impression that one of benefits of the logo requirements of "Program Files" was that apps would required to be compatible with a path with a space in the name. Of course some sneaks tried getting by with progra~1, but the intention was good.

    per Google and %APPDATA%, it was my impression that they did this to allow for non-admin installs of thier apps, because c:program files was locked from non-admins writing to it.

  6. TM says:

    I seriously hate the Program Files folder. I prefer my stuff on another partition so I usually change the folder manually when installing things. However, especially some microsoft programs installing shared files, still put them into Program Files cluttering my system drive.

  7. Jack Mathews says:

    If memory serves, wasn't another reason that you could only have 255 directory entries in the root folder in FAT, and since every 12 characters of a long file name was a directory entry in FAT this could make you run out of root folder file entries pretty quick?

  8. Ralph says:

    @P Wright A cunning ploy to allow users without admin rights to install the browser? Installing to program files gets me a UAC pop-up, but I can stick an executable in appdata and a shortcut on my desktop no problem. Ofcourse if your box is properly locked down by corporate overlords they should block executing random stuff downloaded from the internet anyway.

    I don't mind that behaviour, but the installer should really try and get permission to put it in program files before resorting to the users appdata.

  9. DWalker says:

    There is another program I recently tried, but I uninstalled it.  It insisted on installing its program files to %APPDATA%, just like Google Chrome.  The developers of this program claimed that installing program files into %APPDATA% does follow guidelines, and also that this is the only way to allow non-admins to update a program.  They also said "if it's good enough for Google Chrome, it's good enough for us".

    I am not sure I believe that.  Isn't there a way for non-admins to update, even if the program is installed in Program Files?

    Anyway, I hate programs installing to non-standard locations, which is why I uninstalled the program.

  10. DWalker says:

    By the way, there is one drawback to the default "C:Program FilesCompanyNameApplicationName".  Companies sell applications to each other all the time, and companies get bought out and renamed.  For example, the Act contact management program has been owned by Contact Software International, and Sales Logix, and Symantec, and Interact, and Sage Software, and maybe one or two other companies owned it at one time or another in its tortured corporate life.  

    This makes for scattered entries in Program Files and also in the registry.

  11. Italian programs failure says:

    As an aside – many italian programs in the late nineties failed to run on almost any non-italian version because they were tested only if installed in "C:programmi" and thus happened to work by chance even not supporting spaces in paths.

  12. Joshua says:

    We followed that for years and had to bail out because Microsoft introduced mass breakage with folder redirection. It turned out our program was so sensitive to folder redirection that even on Windows Server 2003 x64, we had to install to Program Files (x86) even though we were .NET AnyCPU, so we were not really surprised that the folder redirection that came with UAC broke us completely.

    We now install to C:Programs and will not change back. Microsoft brought this one on themselves.

  13. xpclient says:

    Why on 64-bit Windows was the Program Files directory not kept as C:Program Files and for 64-bit programs, a C:Program Files (x64) directory introduced? Why C:Program Files has to be for native 64-bit and 32-bit programs going to C:Program Files (x86)?. Because of this, there is no drive-letter independent way to always xcopy deploy or define paths to the 32-bit Program Files. %ProgramFiles% and %SystemDrive%Program Files differs depending on whether it's 32-bit Windows or 64-bit Windows and %ProgramFiles(x86)% doesn't exist on 32-bit Windows.

    [You should be able to guess the answer. Hint: 32-bit application compatibility. -Raymond]
  14. Wyatt says:

    Writing to %LOCALAPPDATA% was an option listed in a Microsoft White Paper for patching frequently updated game software:

    msdn.microsoft.com/…/ee418715(v=vs.85).aspx

  15. Joshua says:

    @xpclient: xcopy install doesn't go to Program Files anyway because of different issues.

  16. kinokijuf says:

    Why did NT4 allow Everyone full access to Program Files?

    [Explained here. -Raymond]
  17. Neil (SM) says:

    @WndSks:

    The reason I don't like the  "program filescompanyproduct" layout is it makes it harder to find some program directories. Especially considering how often I have to go digging in the Program Files directories (relatively not much).

    For example if I want to putz with some files for a program called "MusicPaint," I just look for the MusicPaint directory.  If it used the company layout, I would first look for MusicPaint not find it. So then either I'd start digging in other directories, or would need to go back to the program and figure out it's published by Xyzzy Systems Inc, then look for it in the Xyzzy Systems directory.

  18. Mike Dunn says:

    Another nice thing about "Program Files" is that it sped up the process of software properly handling spaces in paths.

  19. Joshua says:

    Wow. I knew Power Users had write permission to program files. I didn't know they could install unsigned drivers.

  20. Ray says:

    If I had a time machine, I'd have requested that instead of "Program Files", they just went with "Programs."

    It's not just the spaces in filenames, but the length of the path.

    I much prefer Vista/7's "c:users" to 2000/XP's "c:documents and settings" for the same reason.

  21. Christopher says:

    @Ray:

    I agree. I tend to install to Applications rather than Program Files on my home PC, a practice which I started when I had a separate OS partition but continue because I'm not that fond of the "Program Files" name.

  22. Jeremy says:

    Is there a recommended location for user-local installations (that don't require admin privileges to install)?  For instance, Google Chrome installs to %LOCALAPPDATA%GoogleChromeApplication …

  23. Evan says:

    Sorry Raymond, I just realized that you tend to not like mentions of specific products; I shouldn't have put that in my previous post.

  24. given the fast pace of updates in Chrome, I like that it doesn't require elevation and it just silently updates on its own; that's the same reason for which I installed Firefox and Thunderbird in %UserProfile%Apps. I have many portable application sitting there.

  25. Mike Caron says:

    I don't know why everyone is so concerned about moving Program Files to another partition. I guess it's so that they don't have to re-install everything if they have to wipe C:? Except, you still do since every application has its registry settings, DLL registrations, etc etc that aren't stored in Program Files anyway.

    In face, the only thing I /do/ bother moving on a new install is my User Profile, since the contents of that folder WOULD work in a new install.

  26. dave says:

    We now install to C:Programs and will not change back.

    What software is this, please?  I'd like to be sure I don't ever even think about installing something whose developers seem proud of violating system convention.

  27. Joshua says:

    @dave: What would you consider a rational response to "program does not work if installed to a folder where some programs on the system see a different view than other programs"?

  28. bla says:

    @Evan

    That does not make sense. The OS then boots fast, but the programs you use start slow?

  29. frymaster says:

    @bla:

    it still means you can selectively install your priority apps to your SSD, if it's too small to contain all your programs.  Also, the OS can cache programs; the reverse is not true

  30. RichardDeeming says:

    I think we need something similar to stop programs dumping all over our user profiles.

    For example, prior to Vista, "My Documents" was a top-level folder. On my computer today, it contains 47 folders, of which I created 5. That's 42 useless folders created by other programs cluttering up "my" folder, most of which should be in AppData. Microsoft is far from blameless – every version of Visual Studio adds a new folder; SQL Management Studio adds a new folder; Expression Studio adds a new folder; etc.

    Since Vista, the user profile replaced "My Documents" as the top-level folder. Today, my user profile contains 21 folders, of which I created 3. Again, Microsoft is the primary culprit – "Lync Recordings", "Tracing", "VSWebCache". etc.

    Maybe I should just ignore my profile directory and switch to libraries. I'd have to remove the "My" folders though, since they're obviously not mine.

  31. Evan says:

    @bla: "The OS then boots fast, but the programs you use start slow?"

    The OS still accesses a bunch of stuff in its own directory after it boots, you know.

    And "boot fast" is still better than "everything slow." I'm not at home so can't check it, but my Program Files directory is almost certainly over 100 GB. An SSD that can hold both my boot & program partitions is out of my price range. An SSD that can hold just my boot partition is rather more attractive.

    I still am sort of with you though — which is why I haven't gotten one for my boot drive yet. I have a "working set" that is just too large. (At least if I have to manually manage what goes on SSD and what doesn't. Something like the SSD caching in whatever Intel chipset that supports it sounds really attractive, but again, an upgrade isn't really in the cards.)

  32. DosFreak says:

    If you want Chrome to install to Program Files you can install "Google Chrome for Business"

    We use SRP to block all executables except Program Files and Windows directories.

    So when a user complains that Chrome doesn't work I know right off the bat why and I just email them the link to Chrome for Business ;)

    Since we implemented SRP incidents of malware have pretty much gone to 0 on domain joined machines. (Except for the cases where users actually download malware themselves manually and run it as admin :(  )

  33. 640k says:

    Visual Studio 6.0 (or maybe some of it's SPs) installs, and registers, com dlls in the TEMP directory if it cannot write to progra~1.

    Also, it's easy to install Chrome the old way, download the offline installer:

    support.google.com/…/answer.py

  34. Anonymous Coward says:

    I hate that Chrome installs itself to %APPDATA%. I recently needed to go to the installation folder (something to do with an extension) and I looked in Program Files and it wasn't there. I lost an hour trying to search the Program Files folder for various combinations of Google, Chrome and Chromium.

    I also hate it when software (usually games) installs itself in Program FilesCompanyProduct. Usually I only have one software package from any given company so it results in a lot of folders with just one subfolder and nothing else. I can just imagine the bloated ego of the developers: our software is so awesome, everyone'll want everything we make so we need our own folder!

  35. Evan says:

    @P Wright: "I wonder what readers of this blog think about Google Chrome's default (i.e., non-MSI) installer installing into %APPDATA%. Always felt 'wrong' to me."

    That's one reason I don't use Chrome. I install programs to a separate partition. Occasionally I'll run across a program that doesn't like that, or will stick a bunch of crap in "c:Program Files" anyway. Such a program has to be very compelling for me to use it… Chrome isn't.

    @DWalker: "By the way, there is one drawback to the default "C:Program FilesCompanyNameApplicationName".  Companies sell applications to each other all the time, and companies get bought out and renamed."

    NeilSM already said this, but I typed it out too so I'm leaving it. :-) There's another drawback: a lot of the time, I don't know or care what company made a piece of software. Just the other day I had reason to look through the folder of SecureCRT for something. I had to go to the start menu, right click its entry, open the property sheet, and look at the path it was starting because I didn't know that it would be in 'C:Program FilesVanDyke Software'.

    I actually often *remove* company names like that.

    @Ray: "If I had a time machine, I'd have requested that instead of "Program Files", they just went with "Programs.""

    As others have pointed out, the space in the path had the benefit of "forcing" things to work with spaces. So it's nice that they did that, IMO. Though I do sort of wish that Vista had changed %ProgramFiles% to Programs, similar to the Users thing.

    @xpclient: "Why on 64-bit Windows was the Program Files directory not kept as C:Program Files and for 64-bit programs, a C:Program Files (x64) directory introduced?"

    Actually I never really understood why there are separate directories in the first place. Is it so that you could happily install both versions of a program (perhaps something like Tortoise* that has a shell extension) side-by-side even if they weren't built for that?

  36. cheong00 says:

    @DWalker: Agreed. If it's that way, I might have trouble finding the Crystal Report and Java executables. (kidding)

  37. Evan says:

    @Mike Caron: 'I don't know why everyone is so concerned about moving Program Files to another partition.'

    There are a variety of reasons. I do it mostly in case that partition fills up, you can copy the contents of that partition to another a lot easier than copying the boot partition. (Or at least it sounds to me like the latter could be fraught with difficulty.) Also if it fills up, it's less likely to mess around with the system.

    A *very* convincing reason would be so you can put your boot partition (and thus Windows) on an SSD.

  38. Dave says:

    I wonder what readers of this blog think about Google Chrome's default (i.e., non-MSI)

    installer installing into %APPDATA%. Always felt 'wrong' to me.

    That's because anyone can scribble into %AppData%, while %ProgramFiles% requires an Admin and entails actual computer management, with policies and so on.  Using %AppData% is easier for Google than doing the 'cacls +everyone=everything %ProgramFiles%' that would otherwise have been necessary.

    (Google's approach to security under Windows is pretty dire.  After how many years of complaints, have they finally fixed Picasa so it doesn't simply die if you're not Admin?).

  39. Dave says:

    (Google's approach to security under Windows is pretty dire.  After how many years of complaints,

    have they finally fixed Picasa so it doesn't simply die if you're not Admin?).

    From some quick Googling, at least as late as 2011, it still simply died if you weren't Admin.  Mind you it's only been ten years, I guess we just have to wait a bit longer for them to get this fixed.

  40. Drak says:

    Uhm, could be me, but isn't %APPDATA% simply where click-once installed applications end up? And isn't click-once (supported) by Microsoft? So how exactly is Google doing things wrong here?

  41. AndyCadley says:

    %LOCALAPPDATA%Programs is the location Per-User installations are supposed to use as of Windows 7, so Chrome is almost following guidelines. Windows Installer knows about these on Windows 7 too, which finally fixed one of the biggest problems with trying to author per-user installs in previous versions of Windows.

    I'm fascinated by Raymond's link in the first comment though, I don't think I've seen a single application in all my years with Windows that has followed the advice of putting all dlls in a "System" subdirectory under the application's folder. Which probably says as much about how little Microsoft does to push this advice out as it does about how many devs ignore it!

  42. Ooh says:

    @Joshua: "program does not work if installed to a folder where some programs on the system see a different view than other programs"

    I'd say that program is extremely fragile and buggy, and desperately needs to be fixed.

  43. Neil says:

    @dave: Apparently you run into this issue when using a 32-bit installer to install a 64-bit or mixed-mode application, because it will always redirect from Program Files to Program Files (x86).

  44. Ian Yates says:

    (trouble posting comments – sorry if this appears multiple times)

    For those who want to have some programs on their boot drive and others on another drive, instead of moving C:program files all the way to D: (or wherever), simply use symbolic links.  I still need to use Delphi v7 for some of our development and instead of installing it the usual way and leaving it (after reconfiguring the several hundred control libraries, extensions, compiler batch scripts, etc) I

    a) did the installation

    b) made a folder called D:Delphi

    c) moved the contents of my Delphi7 folder to D:delphi

    d) made 2x symbolic links

      C:program filesborlanddelphi7 points to D:delphi

      C:program files (x86)borlanddelphi7 also points to D:delphi

    This way I installed Delphi the "normal" way with the installer but then just overwrote the D:delphi folder with the contents from my old PC and brought over the HKLM and HKCU registry keys.  This has worked for 2x laptop migrations so far without a hitch :)

    I've done it for the visual studio installations and also have a similar thing going when SharePoint 2010 first came out – a symbolic link was created at c:program files..blah..12 to point to c:program files..blah..14  (SharePoint 2010 was a "wave 14" product).  This increased compatibility with a lot of 2007 extensions that assumed the "12" folder name.

    The main reason for the Delphi trickery (I also did it for visual studio and several other apps)…  My new laptop has 2x 500GB HDDs (they're the Seagate XT things with 4GB of SSD as a cache) and I figured I'd like to upgrade to an SSD in the future.  Testing the software when first installed with symlinks allowed me to be certain that should I replace my boot drive with an SSD I can move files off it to the slower HDD and move some from the D: HDD back to C: if I want them to be fast.  I haven't had any compat issues yet (after 12 months)

    I tend to do database work for a week or two, then move to some Delphi maintenance, and, if I ever get time, new work in Visual Studio.  I don't know if it would be worth it, but I could move things around if I wanted them to be fast for a while without too much effort.  I also use my machine for some demos when we're at trade shows – demoing a 2GB SQL analysis services cube and an accompanying 20GB SQL database on the SSD temporarily would be nicer than saying "your server will run this better – please believe me" :)

    For those who don't know about symlinks, Raymond's written about them plenty of times in the past.  Run mklink from an elevated command prompt – it's easy to try out with a couple of test folders.  There's also a shell extension which I've installed but haven't really used called Link Shell Extension available at schinagl.priv.at/…/hardlinkshellext.html.  It's free and the documentation tells you just about everything you'd ever want to know about junctions, links, etc.  The versioning of files you can do with it (Delorean copy) seems pretty neat

  45. John says:

    @Neil

    Apparently you run into this issue when using a 32-bit installer to install a 64-bit or mixed-mode application

    > This is 2012 for pete's sake, this developer needs to pick up a copy of WiX and take 1 hour to learn the easy to pick up syntax.

    I second the opinion expressed here, whats the name of this software so I can avoid using/purchasing it.

  46. John says:

    @640k

    Visual Studio 6.0 (or maybe some of it's SPs) installs, and registers, com dlls in the TEMP directory if it cannot write to progra~1.

    > So because of a mistake made in 1998 (14 years ago) this needs to be perpetuated today?

  47. Stefan Kanthak says:

    | Hint: 32-bit application compatibility. -Raymond

    Really? Just consider the following case: a 32-bit application uses batch files to perform some sophisticated tasks. All paths in these batch files use "C:Program Files…program.exe" or "%ProgramFiles%…program.exe" to run the different application programs, and stop working on x64.

    Hint: the batch interpreter is a native x64 application.

    Hint2: *.LNK which are created with "%ProgramFiles%…" suffer the same problem: the shell is a native x64 application.

    [Presumably the batch file asks LitWare 2000 where it was installed, and LitWare 2000 says "I am located at C:Program Files (x86)LitWare 2000LitWare.exe". I find it interesting that people who hate file system redirection are suddenly demanding it. -Raymond]
  48. Random User 435668 says:

    @Stefan, Joseph

    I freely admit I may be remembering this wrong, but I seem to recall: when I ran into something like this, the 32bit app ended up launching the 32bit version of of command interpreter (cmd), which went on it's merry way running the batch script. All 32bit, all references to "Program Files" properly virtualized. (Obviously, if you were expecting the 32bit app to go mess with the 64bit folder, then this might be considered a bug.)

    As for shortcuts, I've not messed with those. If they are created with whatever appropriate API, instead of blindly copying them between systems, does it not adjust the path during the create?

  49. Joshua says:

    @Ooh: A program that assumes the classical model of filesystems is buggy? Really?

  50. voo says:

    All the people complaining about chrome not installing into Program Files clearly don't use FF or chrome (installed into Program Files), because if they did they would understand the reasoning at the first update (so in chromes case probably 10minutes after install ;) ).

    Having to have admin rights to update a browser makes for horrible design. Having the browser auto update itself is the best thing to protect the average user from malware – not being able to do so (or having to give them admin rights) completely defeats that..

  51. James Curran says:

    I had assumed at least one of the reasons for "Program Files" was to aid backups — the "My Documents" folder needed to be backed-up regularly, while the "Program Files" folder needed to be backup only after a new installation.

  52. jader3rd says:

    @voo,

    Gotta disagree with you there. I've seen too many hijacked installs of Chrome to think that running internet facing program from a non-admin installed location could possibly be a good idea. In addition to Google being able to update Chrome binaries, malware also has to the ability to "update" the Chrome binaries.

  53. Stefan Kanthak says:

    | I find it interesting that people who hate file system redirection are suddenly demanding it. -Raymond

    Have I demanded file system redirection anywhere, anytime?

    NEVER! File system redirection is the dumbest idea ever introduced in Windows.

    Examples: try to open "%SystemRoot%System32filename.ext" with a 32-bit application that is associated with .EXT. OUCH! Or drag&drop that file onto a 32-bit executable. OUCH!

    Or type the name of your 32-bit executable in a (32- or 64-bit) command processor window and complete the command line with drag&drop of the pathname. OUCH!

    | Presumably the batch file asks LitWare 2000 where it was installed

    This wasn't necessary before with Windows x86, and Windows x64 is said to be compatible to Windows x86.

    But let's assume the batch file does so: which command provides this kind of information?

    The batch file needs to know the path to "LitWare 2000" to be able to ask it. So: back to square 0!

    @Random …

    Start the batch in Windows Explorer.

    [The batch file needed to do this even on an all-x86 machine, because there's no guarantee that LitWare is installed into C:Program FilesLitWare 2000 if the user customized the installation directory. Maybe it's on D:Program Files, as so many commenters wish would be the default. -Raymond]
  54. Joshua says:

    I suspect Stefen Kanthak has far enough out of his way to ensure this will always be true (this is possible in a corporate environment) but was not expecting x64 to use Program Files (x86) for 32 bit programs having never seen it before writing the admin batch files.

    There really should be an alias for program files like there is sysnative for system32. Hmmm I wonder if a symlink can do that.

  55. MR says:

    "Having to have admin rights to update a browser makes for horrible design"

    At work I ran into a problem with an older Firefox install, which was unable to update itself because Program Files was locked down and would get stuck into an infinite loop of failing to update and automatically restarting and failing again. Took a call to IT to get it fixed. Later I found out how they avoided this problem for remote field installs: by simply not patching Firefox at all. For the next several years. They ultimately lost the install package, thank gods.

  56. Stefan Kanthak says:

    | The batch file needed to do this even on an all-x86 machine, because there's no guarantee that LitWare is installed into C:Program FilesLitWare 2000 if the user customized the installation directory. Maybe it's on D:Program Files, as so many commenters wish would be the default. -Raymond

    "LitWare 2000" can only be (or is always) installed in "%ProgramFiles%".

    This happens to be on D: if %SystemDrive% is D: (or my WINNT.SIF relocated "ProgramFiles" to "D:Program Files").-P

    @Joshua:

    No, I expect x64 to be compatible with x86.

    This includes batch files, scripts etc. too.

    Remember: the Windows Explorer is a 64-bit application. A batch file started from there needs to use %ProgramFiles(x86)% to address the directory which was well-known as %ProgramFiles% in x86 environment.

  57. @voo

    The solution isn't to make the binaries writable by everyone but to have a background service that can update the executables. That way the service can verify that the updates are safe and trusted, and then updates the binaries.

  58. Joseph Koss says:

    @Stefan

    I agree with you. Raymonds comment didnt make sense with regard to 32-bit compatibility. If the 32-bit location remained Program Files and the 64-bit location was Program Files (x64) then its hard to imagine that that creates *more* comparability issues than the current system, which also frustrates the users because what he see is sometimes no longer what he gets.

  59. voo says:

    @jader3rd Hmm personally I see only two variants at the moment: Give my users (well, people whom I fix their PCs, say parents, I don't do that stuff for work) admin rights and firefox, or let them use chrome. Firefox without admin rights means they will run ancient versions of it (I've seen similar things as MR there), which is bad, and I really don't want to give them the admin rights..

    @Master Programmer Yeah sounds like a good solution, but why oh why aren't the firefox guys implementing this? Seems simple enough that I'm sure there must be some catch (well we'd still need admin rights to install the browser, which chrome doesn't need, but that's much less of a problem than needing the rights at every update).

  60. Jojo Man says:

    The UNIX system made more sense with system software paths and local software paths. There is no reason why Windows does not have system/global program files and per-user program files. That way when installing a program the user can choose whether to install it for just themselves or for everyone on the machine. Software that is meant to be used by the system or everyone can mandate that it be installed to the system/global location if desired.

    Most people I know do not have multiple user accounts on their Windows PCs so nothing would change much if most applications like browsers installed to the per-user program files directory (UNIX equivalent of something like ~/programs). It definitely would make patching/upgrades doable for non-admin users and would also allow per-user licensing to be respected for software on machines that do have multiple user users/user-accounts.

    Plus its so much easier to type ~/documents or ~/programs to get to your documents and programs respectively than "c:documents and settingssomeusermy documents" and "c:program files" or "C:Documents and SettingssomeuserApplication DataPrograms" or something like that.

  61. Harry Johnston says:

    @Joshua: I'm puzzled by the issue you describe, because WOW64 doesn't do any file redirection for the Program Files directory, so all applications should see the same view as far as that is concerned.

    UAC redirection should only kick in if your application misbehaves by writing into the program directory at runtime.

  62. Joshua says:

    @Harry Johnston: The fault was caused by UAC redirection applied to some other application we invoked by out-of-process COM. After discovering that the necessary manifest varied by version of the other program (something we had no control over) that was end-game.

  63. Evan says:

    @JoJo Man: "The UNIX system made more sense with system software paths and local software paths."

    I'm not sure what you mean by that, because Unix doesn't have any standard for local software paths, and almost no package managers support installation as non-root. (/usr/local/bin, for the Unixes that use that, is different.) You can still do it if you go through the configure/make sequence yourself (for almost any program), but then again you can also install anywhere you like when installing a Windows program, including choosing something other than Program Files (for almost any program).

    Now, there is a difference in that Windows seems to automatically elevate most installers, so you can't even run them if you don't have the equivalent of sudo rights, but that's independent of file system layout. Nor is it universal; plenty of software runs under your credentials at the start, asks whether you want to install it for just your or any user, and elevates only if necessary.

  64. ender says:

    Regarding Program Files: it's not part of WoW64 redirection – 32bit programs can access C:Program Files just fine.

    As for batch files, 32-bit process will run them in 32bit cmd.exe (unless it specifically knows how to invoke the 64bit one), and %PROGRAMFILES% in 32-bit cmd.exe expands to C:Program Files (x86) (other affected environment variables are %CommonProgramFiles% and %PROCESSOR_ARCHITECTURE%).

    And speaking of installing programs with Windows Installer: it's not possible to create a single MSI file that would install either 32 or 64-bit version of a program, depending on the host OS.

  65. @Stefan Kanthak

    I guess the batch file needs to be updated then. Just remember to check the %PROCESSOR_ARCHITECTURE% and %PROCESSOR_ARCHITEW6432% environment variables. If you check %PROCESSOR_ARCHITECTURE% and it is x86 then it is either an x86 version of Windows or a WoW64 version of cmd, you should just do what you normally do. If you care to tell the difference, check for %PROCESSOR_ARCHITEW6432%. If this is set then it is a WoW64 version of cmd, but normally you shouldn't care.

    The real problem is when %PROCESSOR_ARCHITECTURE% is set to AMD64. This means you have a native 64 bit version of the command prompt and thus everything will just direct you to the normal 64 bit locations. This means you have to deal with it in one of two ways, first explicitly access the (x86) versions of the environment variables or secondly, %systemroot%syswow64cmd /c <path to your batch file>. It will launch your batch file with the 32 bit version of the shell and so everything should work fine.

    But to make one thing clear, 32 bit compatability means that applications will run without modification while they stick to the 32 bit world, and that means staying in WoW64 processes. As soon as you venture outside of this then you are out for pain. Your batch file is proof of this. You are claiming that WoW isn't there for 32 bit compatability, but it is more likely that you are running it in a 64 bit copy of cmd and so it isn't a 32 bit process, so why would 32 bit compatability apply there.

  66. DWalker says:

    The recommendation (and the trend) to install programs into %UserProfile%Apps is a security issue.  The Microsoft guidance page that Raymond pointed to in the first comment mentions this.  Yes, it's easier to let non-elevated users update programs there, and yes, it's easier to let malware update programs there.

    When programs are installed to the user Apps folder, malware has a known target — it replace an executable file that has a known name, in a known location (like Chrome.exe in the user's Apps folder), without the restrictions that are in place against updating files that are in the "Program Files" folder.

  67. Stefan Kanthak says:

    @ender

    | 32bit programs can access C:Program Files just fine.

    32bit programs^Wbatch files can't use neither "%ProgramFiles%" nor "%ProgramFiles(x86)%" to access that path WITHOUT knowledge of the drive letter etc. of the resp. Windows installation. See <support.microsoft.com/…/976039>

    There is also no CSIDL (see 16422, 16426, 16427 and 16428) that may serve that purpose.

    | As for batch files, 32-bit process will run them in 32bit cmd.exe

    A *.CMD, *.VBS, *.JS, *.PS1 etc. started from the Explorer runs in 64bit, not 32bit.

  68. Joshua says:

    @DWalker: Wow. Turing completeness leads to recursive insecurity.

    Not that I'm surprised. It turns out that Turing completeness requires on some large scale self-modifying code (the Harvard Architecture is only complete by emulating a machine that has Von Neumann Architecture), and perfect virus detection is a known unsolvable problem.

  69. Stefan Kanthak says:

    | and perfect virus detection is a known unsolvable problem.

    Strike out "perfect": even simple virus detection is an unsolvable problem!

    That's why antivirus programs and the like are useless: they can't protect against malware.

    To protect yourself and your users you need a restrictive system configuration, without administrative rights for users (no UAC doesn't work for that purpose), plus SAFER a.k.a. software restriction policies that allow execution only in %SystemRoot% (with exceptions for the user-writable subdirectories), %ProgramFiles% and %ProgramFiles(x86)%.

    Bonus: there is no more security issue with anything "installed" in %UserProfile%!

    JFTR: "installing" programs in user-writable locations in COMPLETE NONSENSE!

  70. Burak KALAYCI says:

    Stefan Kanthak: "File system redirection is the dumbest idea ever introduced in Windows".

    Well said. Can't agree more.

  71. Joshua says:

    @Stefan Kanthak: Congratulations. Developing for the platform now requires cross-compiling from a platform without those restrictions, and viruses are still possible as interpreted languages will still run.

  72. I'm surprised that no one has mentioned that Oracle still requires that their stuff be installed to C:Oracle and that the app won't work if installed to a path containing spaces.  (It's been 17 years since they first saw Windows 95, and 16 since NT4.)

    I disagree wholeheartedly with the "dumbest idea" assertions about file system redirection.  UAC's file/registry redirection ("virtualization") enables lots of apps to run on Vista/7 that required admin rights on XP.  And when a 32-bit process wants to load gdi32.dll, it needs to get the 32-bit GDI; if it tries to load the 64-bit, it will fail.  Redirection is the only way to make that happen.  And how often does a 32-bit app need to open a "filename.ext" in the System32 folder?  Why is that file in the System32 folder?  Does it really belong there?

  73. @Adam Rosenfield:  Here's what I did today when I needed to navigate to the "Microsoft SDKs" folder:  navigate down to "Program Files" (or the x86 if you're going there), then press "*SDK*" and press Tab.  Cmd.exe figures out which folders match *SDK* and cycle through those – or just pick the one that matches.

  74. Engywuck says:

    Well, if you *need* to have C:Program Files on a seperate HDD you could *try* mounting the partition as an NTFS path with name C:Program Files (never tried, though).

    Of course you should copy all folders already in there to the new partition before you do so :-)

Comments are closed.

Skip to main content