Why is the Program Files directory called Program Files instead of just Programs?


Some people suggest that one thing Microsoft Research could do with that time machine they're working on is to go back in time and change the name of the Program Files directory to simply Programs.

No, it really should be Program Files.

Program Files are not the same as Programs. Programs are things like Calc, Notepad, Excel, Photoshop. They are things you run.

Program Files are things like ACRORD32.DLL and TWCUTCHR.DLL. They are files that make programs run.

If the directory were named Programs, then people who wanted to run a program would start digging into that directory and seeing a page full of weird DLL names and wonder "What the heck kind of programs are these?" And eventually they might figure out that if they want to run PowerPoint, they need to double-click on the icon named POWERPNT. "Computers are so hard to use."

WLCM2DOS

If you want to find your programs, go to the Start menu. The Program Files directory is like the pantry of a restaurant. You aren't expected to go in there and nibble on things that look interesting. You're expected to order things from the menu.

Comments (97)
  1. Uli Gerhardt says:

    Somehow that got lost in the German translation which is "Programme" and not "Programmdateien".

  2. KanjiMonster says:

    The translation teams did not seem to be that much concerned about the difference; at least in German versions this folder was just called "Programme" ("Programs"). With the nice side effect that programs that do not like spaces in their path could be installed and used there.

  3. Andrew says:

    The clutter of the Program Files directory was a real turnoff for me, coming from a "classic" Mac background.  In classic Mac OS, the filesystem was also the app launcher and programs were generally self-contained things you could put wherever you wanted them (thanks to resource forks).

  4. Michael says:

    As I recall the Swedish version of Windows 95 did the same thing, calling the directory "Program" (literally, (computer) program or programs) rather than for example "Programfiler" which would have been the literal translation of Program Files.

    And that doesn't even begin to touch on the issue of translating directory names… like, nobody thought to translate the name of the Windows directory.

  5. Raphael says:

    "With the nice side effect that programs that do not like spaces in their path could be installed and used there."

    Though really, if your program has a problem with spaces in its path, there's a bigger issue somewhere.

    WinDDK team, I'm looking at you.

  6. John says:

    I don't know; that justification sounds kind of silly.

    "Oh, a 'Programs' directory.  Better click all the things!"

    "Oh, a 'Program Files' directory.  Better not click all the things!

    It seems to me the type of person who would browse "Programs" would also browse "Program Files".  According to your own link people still browse the directory and click all the things anyway.  I'm just going to pretend the real reason was to force applications to handle paths with spaces correctly.

  7. Adam Rosenfield says:

    How about a locale like en_X-POWER-USERS which changes the localized directory name to just "Programs" for nitpicky programmers?

  8. Michael says:

    Yes @Adam Rosenfield, because localized directory names was totally around in Windows 95. :)

  9. alegr1 says:

    And this, ladies and gentlemen, why Windows has to resort to horrible kludges to support a command line with missing quotes. Thanks, Program Files. This is why we can't have nice things.

    [You probably also think they should have used the Space Shuttle to rescue the Apollo 13 astronauts. Program Files appeared with Windows 95 in 1995. Funky treatment of spaces in command lines was introduced in 1993 with Windows NT 3.1. (Or are you saying that the Windows NT 3.1 team had a time machine?) -Raymond]
  10. Jason Warren says:

    As well as the program files, doesn't Program Files also contain the programs? What I mean is along with ACRORD32.DLL there is also ACRORD32.EXE which like your POWERPNT.EXE example most people consider the program. I guess what you're saying is at the Windows restaurant ACRORD32.EXE is the recipe for baking up the Adobe Acrobat Reader program which the shell server delivers to your high resolution table where you will eat your PDF with your mouse, keyboard, or hands if you have one of those new tablet utensils.

  11. Jonimus says:

    Sure programs should handle spaces in path names correctly but having spaces in paths is just such a pain for everything. So much escaping and quoting could just be gotten rid of if they were removed. Thankfully Vista got rid of the abomination that was "Documents and Settings", Users just makes more sense, though why they couldn't just copy unix at that point and use home, then again Users is a bit more accurate.

  12. Michael says:

    And when I said localized directory names in the comment 7:33 above, I meant localized on a per-user basis. Sorry for the confusion.

  13. Jason Warren says:

    @Adam Rosenfield: If that existed developers would develop solely in that locale and wonder why their directory strings containing "C:Programs" only work on their computers.

  14. Dave says:

    @Michael: This is all about what the research team could do with their time machine. Obviously, localised directory names would get added when they create the new locale so @Adam's comment holds.

  15. Alex says:

    Let alone 'Program Files' or even 'Documents and Settings' (really silly lengthy name). What about the ubiquitous 'My' prefix? Why oh why not just 'Computer', 'Documents', 'Pictures' or 'Music'. And yes, I know you may have some shared folders or see other user's folders. But they did not exist in Windows 95 where the almighty 'My' was first introduced.

  16. Kit says:

    I suppose, following this argument through, that the "Users" directory actually contains real users, and not just files belonging to users.

  17. Daniel says:

    @Michael

    Well, they were there, only with actually renamed directories rather than virtual labels. I remember the first time I noticed Windows Vista folders were actually in English in the file system, I was quite surprised!

  18. Daniel says:

    @Kit

    To be fair, "Users" is a much newer directory in Windows-land, and whoever came up with it probably wasn't the same person who thought "Program files" was a good idea in the nineties.

    Personally, "Program Files" never bothered me much; "Documents and Settings" is where my hatred lies.

  19. gvaerg says:

    My father used to call the Start Menu folder "Program Files". I think it was an example of hypercorrection.

  20. CL says:

    It's pretty redundant to have files with "files" in their name!

  21. Mike says:

    "If you want to find your programs, go to the Start menu."

    Can't find it on Windows 8 ?!

    * ducks and runs ….

    [Click the downward-pointing arrow to see All Programs. -Raymond]
  22. ErikF says:

    Knowing the rigorous testing that many developers use, if Microsoft didn't have commonly-used paths that used spaces, every program in the known universe would die when given them (see: Unicode). I'm glad that this issue is largely moot nowadays.

  23. Daniel says:

    Program Files? –> While I hate spaces in file and directory names, I can survive it.

    But if you really want to have fun then look at the following two folders on windows 64 system:

    System32 (this is where the 64-bit code is placed)

    WOW64 (this is where the legacy 32-bit code is placed)

    if you want to register a 64-bit COM server you simply call regsvr32.exe (logic isn't it?)

    On the other hand if you want to register a 32-bit COM server you cannot simply call regsvr32.exe. You need always to ensure that you either specify the full path or call it from a 32-bit process (e.g. 32-bit console). Thank you VERY MUCH…

    [I thought I already discussed this. Yup, I did. The "32" doesn't mean "32" any more. It means "the same bitness as the app you are running." The confusing name is for backward compatibility. -Raymond]
  24. /bin says:

    can we use the time machine to change it from Program Files to bin?

  25. asdbsd says:

    Whoever goes outside of Desktop and My Documents is already in the pantry. I don't think calling folder "Program Files" helps much. I would prefer it if the Explorer team went with some kind of special presentation for these folders, e.g. Explorer display every subfolder as a big descriptive block with an icon and "Program Name, by Corporation Name", "Takes this much space", and if you double-click it it runs whatever is in this folder in Start Menu, and by Right-click it lets you "View program files", "Uninstall", and all this can be disabled if you're power-user. I guess it would have been nicer.

    Anti-nitpick corner: time travel is impossible, every feature starts with 100 points, Raymond has nothing to do with this.

    [This requires each app to be installed into its own directory, which can be a problem for suites. But we tried that in Windows 2000. And again in Windows Vista. Failed both times. -Raymond]
  26. Evan says:

    @Glen: "To heck with the fact that it was going to break millions of scripts, and a huge percentage of existing software."

    Those scripts and software were already broken. "Program Files" just made it more obvious.

    I think I've heard something very similar to your description, but with a different spin: that MS deliberately included the space specifically to try to force programs to be written correctly to deal with spaces. I don't know if it's true or not, but given the level that MS attempted to keep compatibility, I find it more plausible than "Hey look at us with spaces! Aren't WE cool!"

  27. Lars Viklund says:

    Pretty much any Swedish computer you come across will upon logon show an Explorer window opened at C:Program. The sacred art of properly quoting Run registry strings is something that most software will never master.

  28. 640k says:

    The latest fail from the company who brought us System32:

    C:Program Files (x86)MSBuild12.0binamd64

    "amd64" isn't even MS own official name of the architecture! (it's x64) This was done in year 2013.

    @Michael: Yes, the the Swedish version of Progra~1 is called "C:Program" which makes Raymonds reasons invalid. But the problems don't stop there with the Swedish windows version. "C:Program", is of course much worse than the german "Programme". Why? Because when some english installers with hard coded paths create "C:Program Files", commands wont work any more, because the path parser in windows mixup the two folders.

    This was such a common and bad problem that MS had to do something about it, but the cure was worse than the disease. When newer versions of windows explorer detect that you have both folders, it shows a modal dialog box, suggesting to rename one of the folders, causing at least one, usual several, installed program to stop working. And it doesn't help that many of MS own programs have hard coded "C:Program Files" in its installers, which destroys the Swedish OS.

    ["amd64" was the internal code name for the architecture, and one thing about code names is that they tend to hang around long after the official name has been chosen because nobody wants to go around renaming everything and risking introducing all sorts of bugs. -Raymond]
  29. Narr says:

    >If you want to find your programs, go to the Start menu.

    Start Screen. You're getting old ;)

  30. Anon says:

    @640k

    I'm sure I'll regret responding to the ages-old troll:

    AMD64 is AMD's name. You have a problem with it, talk to AMD.

    "x64" is the generic term used because most consumers don't give a damn about the official name, and "AMD64" would confuse them. 'What, I can't run this on my Intel?!'

    System directories are not localized. The DISPLAY NAMES are localized, but that has nothing whatsoever to do with the actual directory structure on disk. If you're using non-English directory names for anything other than presentation to the user, stop. You're doing it wrong.

  31. 640k says:

    @Raymond: Why do a path contain both "x86" and "amd64"? What is supposed to exist in this folder? There's already a perfectly good program files folder for 64-bit binaries.

    [Presumably it was to allow all the files to reside in a single directory tree. This avoids having to store global configuration information. ("Where are the x86 binaries?" "Where are the x64 binaries?") But I'm just guessing. You can ask the MSBuild folks if you want to know for sure. -Raymond]
  32. Brian_EE says:

    "digging into that directory"… this links to a discussion about how programs gain points to end up in the start menu. Yet, the VB.net Click-Once app that I wrote and launch everyday at work never shows up in the list, while apps I use rarely (like Windows Virtual PC) hang around forever.

    Explain that one…

  33. 640k says:

    @Anon: Choosing the name of C:Program is not an option the end user have. That's where several version of windows install all program files to when using the localized version. Why was the folder name localized? And why wasn't "Document and settings" localized at all?

    What would be more confusing for the end user than having different display name and actual folder name? Changing conventions several times between different windows versions!

    ["Documents and Settings" was also localized. In German, for example, it was called "Dokumente", as I recall. -Raymond]
  34. Maurits says:

    What is the significance of the "WLCM2DOS" in this post?

  35. Evan says:

    @640k: "Why do a path contain both "x86" and "amd64"? What is supposed to exist in this folder? There's already a perfectly good program files folder for 64-bit binaries."

    Really?

    Maybe because if I install a "program" (like VS) that has both 32-bit and 64-bit components, I'd rather have them co-located then have the 32-bit components put into "c:program files (x86)blah" and the 64-bit components put into "c:program filesblah", even if it means that the directory name isn't 100% right?

  36. amd64 fan says:

    @640k: Maybe "C:Program Files (x86)MSBuild12.0binamd64" contains the x86 binary toolset to build binaries that target AMD64 (x64)?

  37. 640k says:

    @Evan: That's not how Office, SQLServer, and all other components of VS are installed. Other components are installed in a the correct folders, i.e. 64-bit binaries are installed in C:Program Files on 64-bit windows. That way you can assume binaries in C:Program Files are using the native bitness of the OS.

    @amd64fan: That assumption would be wrong.

  38. yuhong2 says:

    @Maurits [MSFT]: Welcome to DOS.

  39. Ken in NH says:

    @Michael

    "And that doesn't even begin to touch on the issue of translating directory names… like, nobody thought to translate the name of the Windows directory."

    I suspect that the Windows directory does not get translated for the same reason that Volkswagen is not called "People's Car" or SAAB is not called SAC (Swedish Aeroplane Corporation) in the English speaking world. It is a trade name, not a description.

  40. 640k says:

    "Translating" from WINNT to Windows wasn't that hard.

  41. Robotussin says:

    This made me smile because I used to forcibly rename C:Program Files to C:Programs after installation (and then had to do a bunch of shortcut and registry modifications to make things work).  Then I got a bit smarter and found a way to do it with the unattended install file.  It was always fun to see which software failed because someone had hard-coded "Program Files" in their paths.  Even some installers would still default to this, even though the Windows API would return Programs as the correct location.  "Good" times.

  42. 640k says:

    @Raymond: ["Documents and Settings" was also localized. In German, for example, it was called "Dokumente", as I recall. -Raymond]

    No, the Swedish windows XP didn't localize the "Documents and Settings" folder, it was called "Documents and Settings".

  43. DWalker says:

    @Andrew: in Mac, "programs were generally self-contained things".  Umm, shared code, anyone?  Code reuse?  DLLs that contain functions that are used by different pieces of an application are a good idea, even when those different pieces are invoked by different EXEs.

  44. Joshua says:

    […amd64…]

    It looks natural to engineers if you look outside of the MS world. i386 is normally the cpuarch name for x86. amd64 is normally the cpuarch name for x64.

    The platform triplet for Windows x86 is i386-pc-mingw32. You would expect the x64 to be amd64-pc-mingw64; however it is in fact x86_64-pc-mingw32. The Cygwin variants are i386-pc-cygwin and amd64-pc-cygwin as expected. Platform triplets don't change once assigned.

  45. 640k says:

    @DWalker: Umm, dll hell, anyone? Shared binary files may sound like a good thing in theory, but is not a good idea in practice after all. MS figured that out years ago, and has in recent years tried to promote side-by-side binaries instead.

    @Joshua: The folder in question was named "amd64" because it contains x64 binaries. An application should not put some of its 64-bit dlls in "program files", and some of them in "program files (x86)". That's plain wrong.

  46. rwilke says:

    If you want to hear the truth about it, read this:

    secretgeek.net/ex_ms.asp

    Rüdiger

  47. ErikF says:

    @640k: IME "translating" from WINNT to Windows wasn't a hard choice because too many programs from the 3.x/9x side of the Windows tree believed that Windows always lived in the Windows directory.

  48. John Doe says:

    Don't start with the Mac, it's got worse problems than Windows:

    – Oh, just copy that .app thing; but what about shared libraries/frameworks, Finder integrations, etc?

    – Oh, use a .pkg (kind of Mac's .msi); but there's no standard, and more important, GUI way of uninstalling things installed through packages… Welcome to App/Bundle Hell

    – Some (official) apps deal well with spaces, others don't (go figure! it's *nix, it already receives a proper argv!)

    – For some (stupid?) reason, file system names with e.g. accented names use the NFD form, where é ( en.wikipedia.org/…/Unicode_equivalence ) is two code units instead of just one

    – The UI is not only single-threaded, it's "main"-threaded, meaning that the first thread (the one that executed "main") is special and the only that can reliably manage windows

    – Oh, but some other things also require the "main" thread, like the initialization of CoreFoundation; as a cool side effect, if you load a library that depends on it and it hasn't yet been loaded, it will crash if not running in the "main" thread, how cool is that? you must send a message to the main thread to load the library for you and sync the result back, or do as suggested here: openradar.appspot.com/7209349

    – You know the spinning wheel of death? ( en.wikipedia.org/…/Spinning_pinwheel ) Well, in a Mac, you'll see it quite a lot, specially in Safari

    – You don't like fuzzy letters? Hahahahahahahaha! Jobs did

    So, although some things in OS X are very nice (e.g. an open menu changes dynamically when you press shift, control, option or command while in Windows it only changes the next menu you open; searching in the Help menu highlights top-level menu items http://www.youtube.com/watch ), I find it way more cumbersome.

  49. James Schend says:

    @DWalker:

    You have to remember MacOS was developed:

    1) in 1984 on computers with 128k of RAM, and

    2) with a very very large, and very complete built-in API

    Therefore its designers never saw a point to shared libraries, and they weren't fully implemented until years and years later (System 7 finally had them, IIRC.) Classic's lack of memory protection made them more prone to crashing for a long while. (The first app I remember really embracing DLLs on Mac without crashing was Office 98, actually.)

  50. Larry Osterman says:

    One major nit about some of the commentary above: MS-DOS 2.0 allowed spaces in file names. And lots of apps would break if you used them. Win95 just made it more obvious.

  51. Joshua says:

    I wonder how Joker_vD expects cross-compiling to work.

  52. Evan says:

    @Joker_vD: "VS by default puts different platform binaries into different output folders by default, and it doesn't mess things up"

    Oh yeah, I forgot to respond to this.

    Note, however, that both directories are (by default) still under your project. You don't have your source in "c:usersmeprogramsfancy-thingsrc" and it compiles to "c:vs-buildsfancy-thingx86" or something like that.

  53. Nicks says:

    I can't imagine how many unix script would break if an OS manufacturer put spaces in common folders like bin, usr, dev, lib, usr, etc. That would be considered crazy.

  54. Nick says:

    > Storing the profiles under the Windows directory was a terrible setup

    Oh, I agree with that.  I just meant the simplicity of the name "Profiles" and "Users" versus "Document and Settings".

  55. Escaper says:

    Sorry if that was already mentions, but here's my two cents. I always thought that naming Program Files like that was specifically to introduce a space character in a system's "mission critical" directory. And the purpose of it was to eliminate all thinkable bugs with having a space in a folder name. In the older DOS days directories could only have names consisting of not more than eight characters and no spaces. To ensure smooth transition to directory names where spaces are allowed this thing was done with Program Files directory. But that always was just my subjective guess.

  56. Joker_vD says:

    @Joshua: Exactly how it works now—with aid of Makefiles full of cryptic stuff (so that those Makefiles occupy half as much space as the actual source), "config.h" files with lots of slightly less cryptic macro stuff, and other textual files of magical lore and incantations.

    [Sure has. IShellFolder::BindToStorage. -Raymond]

    Well, I was sorta sarcastic. Of course, now that the whole Win32 API seems to be superceeded by WinRT, the joke "Just wait until MS make even the most kernel stuff exposed as COM interfaces" is hard to tell jokingly.

  57. Rick C says:

    @Evan "I now have a folder that I can't delete because the name is too long and I've been too lazy to get a utility I can use to remove it."

    Dos prompt, dir/x from enclosing folder to get the short name, then delete by short name.

    If there's no short name, you should still be able to delete the directory by using a carefully-chosen wildcard.

    Finally, you don't need to use a special backup tool.  There's a KB article about how to do it.  I don't remember the details, but it boils down to something like "delete everything in the steam directory but steam.exe and the games you want to keep, then move whatever's left where you want it and run steam.exe, which will patch everything up."  I didn't move to a different computer, but I did move my Steam installation to a different drive to get it off my SSD, and I found that KB article and it worked.  I searched for something fairly obvious like "move my steam installation".

  58. Klimax says:

    @Evan:

    Just rename it and delete. If regular rename doesn't work, use SVN… (yes, it works, because it accesses files and directories by relative paths and those will work always and by this way SVN also can create nice directory structure.)

  59. alegr1 says:

    ["amd64" was the internal code name for the architecture, and one thing about code names is that they tend to hang around long after the official name has been chosen]

    You haven't been around when (whatever would become) Windows 8 was being developed? In those days, to invoke MSBUILD and build your binaries, you were supposed to specify whatever code-name-du-jour Windows 8 had, and it changed like 4 times or so. It was so incredibly stupid, as if the marketrrhoids took over programming.

  60. alegr1 says:

    >Dos prompt, dir/x from enclosing folder to get the short name, then delete by short name.

    Use ?? prefix, Luke.

  61. alegr1 says:

    >Use ?? prefix, Luke.

    That'd be \?

  62. alegr1 says:

    > You don't like fuzzy letters? Hahahahahahahaha! Jobs did

    This reminds me of the stupidity of enabling ClearType in the Windows 7 installer. Which ran with 600×800 resolution. Rainbow text! Did anybody ever test that and filed a bug (which could have been fixed by a single registry value in the installer)?

  63. Escaper says:

    "@amd64fan: That assumption would be wrong."

    Ha-ha, 640, you are not spaces-in-names enabled — you just removed a space from the guy's nickname. :)

  64. Glen says:

    This feels a bit like revisionist history to me.  What *I* remember, and I think most sys-admin or programmers would remember similar conversations with their peers at the time, was "They had to go put a frickin space in the name *just* to prove they supported spaces.  To heck with the fact that it was going to break millions of scripts, and a huge percentage of existing software.  Screwed by Microsoft again."  Otherwise why not just "ProgramFiles." (no space).  

  65. Francis Gagné says:

    > Well, I was sorta sarcastic. Of course, now that the whole Win32 API seems to be superceeded by WinRT, the joke "Just wait until MS make even the most kernel stuff exposed as COM interfaces" is hard to tell jokingly.

    @Joker_vD: Looks like you haven't heard of UMDF (1.x): <msdn.microsoft.com/…/dn384105%28v=vs.85%29.aspx> (Reference: <msdn.microsoft.com/…/dn265594%28v=vs.85%29.aspx>)

  66. Joker_vD says:

    @Evan: The 2013 is ending, and I still see *newly developed* applications that can't cope with spaces in paths. They also tend to misunderstand Greek letters in paths when Russian system code page is turned on.

  67. Brenton Fletcher says:

    @asdbsd

    Don't you remember Windows ME? It had a special presentation for dangerous folders: If you tried to open, for example, the Windows directory, it would show a nice big blank page and a notice that you were playing with things you shouldn't.

  68. Keith Nicholas says:

    I think everyones just called "Bullshit" on the reasoning :)

    We all know some programmer/s wanted to name a directory.

    Programmer: "where we going to stick all the files related to various programs?  need to keep them organized somewhere"

    Lead Developer thinks: hmmmmm …. a directory for program files…. hmmmmm….

    Lead Developer: "I know, Program Files!".

    Random Intern:  "Hey, is that the most usable name …"

    Lead Developer: "Someone smack that kid! Our users will use whatever WE give them."

    Programmer: "Hmmmm, its going to introduce spaces into the directory path name…."

    Lead Developer: I said "PROGRAM FILES!!".  Make it happen!

  69. Gabe says:

    The problem with MacOS storing its programs in their own folders is that it makes them darn near impossible to find. It might have made sense in a system that only used floppies, but not on a hard disk. In order to find a program you had to search the whole folder tree, with windows popping up all over the place, where you had to scroll around to see what was hiding there. Of course you might be able to find things on your own computer, but anybody else's was a crapshoot.

    What lots of people did was drag programs to the desktop (or worse, elsewhere) to make them easier to find, but then they were no longer with their related files. Maybe it made the program unable to find its help file, or maybe it just meant that Word was in one place and Excel somewhere else. It sucked to go to the Office folder, only to find everything BUT the actual Office apps!

    So then they created aliases, which are the Mac version of shortcuts. At least that way you could have an app on your desktop that would work properly, and you couldn't lose an app because the original would always be in its main folder.

    You could also make the apps show up as items on the Apple menu, and now I guess you can "dock" them to make them availble without searching. But as far as I know, to this very day there's nothing like Program Manager or the Start Menu that just shows you a catalog of installed apps.

  70. Joker_vD says:

    @Joshua: "Platform triplet"? As a Windows programmer, I don't care what weird name those GNU guys or whoever they were came up with for their OS/toolchain.

    @Evan: "Maybe because if I install a "program" (like VS) that has both 32-bit and 64-bit components, I'd rather have them co-located"

    Colocated *where*? In "Program Files"? In "Program Files (x86)"? In "ProgramData"? Gee, VS by default puts different platform binaries into different output folders by default, and it doesn't mess things up

  71. Nick says:

    Ahh, paths with spaces: the zombie argument from 1992 that simply refuses to stay dead.

    I hate to break this to you guys, but it's 2013.  The argument we *should* be having is over MAX_PATH, and how dealing with the associated problems is STILL a common thing.

    > What about the ubiquitous 'My' prefix? Why oh why not just 'Computer', 'Documents', 'Pictures' or 'Music'

    I think I remember reading that (part of) the rationale for these names were to help make it clear to users that this is where *their* personal files should go.  "My Computer" and "My Documents" make sense to me, but having a separate "My Pictures" instead of just making a "Pictures" directory under "My Documents" never did.  And then you get third party programs creating "My Fancy Doodads 2013"…

    > To be fair, "Users" is a much newer directory in Windows-land

    Not really newer — I always saw it as a (sensible) return to the Windows NT approach of storing profiles in C:WINNTProfiles.

  72. Joker_vD says:

    @Nick: "The argument we *should* be having is over MAX_PATH, and how dealing with the associated problems is STILL a common thing."

    I am sure introducing IPath, IPathElement, and IFileSystemItem interfaces would solve this problem once and for all! Oh wait, I think something like this had already happened, hadn't it?

    [Sure has. IShellFolder::BindToStorage. -Raymond]
  73. Evan says:

    @640K: "That's not how Office, SQLServer, and all other components of VS are installed. Other components are installed in a the correct folders, i.e. 64-bit binaries are installed in C:Program Files on 64-bit windows. That way you can assume binaries in C:Program Files are using the native bitness of the OS."

    Then I dunno. Personally I think that's obnoxious, as I explain in the following.

    Though… really? I thought that even the 64-bit compilers still went under "program files (x86)microsoft visual studio" somewhere. I can't check right now though.

    @Joker_vD: "Colocated *where*? In "Program Files"? In "Program Files (x86)"? In "ProgramData"?"

    I don't really care. Pick one. But one of the things I like about the Windows way of doing program installation is that everything's together, instead of vomiting files in 17 different places like happens on some other OSs I could name.

    Not that VS follows that anyway (it installs several hundred MB to your system drive even if you install it primarily elsewhere), but that's still not an excuse for making it even worse.

    @Nick: "The argument we *should* be having is over MAX_PATH, and how dealing with the associated problems is STILL a common thing."

    Hah. I went to use the Steam backup utility a couple days ago to make things "easier" to move from one computer to another, which if you back up Game A, Game B, and Game C will create a folder named "Game A and Game B and Game C".

    I tried to select my entire library. (Well, everything I have installed anyway.) I now have a folder that I can't delete because the name is too long and I've been too lazy to get a utility I can use to remove it.

    @Nick: "I always saw it as a (sensible) return to the Windows NT approach of storing profiles in C:WINNTProfiles."

    Storing the profiles under the Windows directory was a terrible setup, way more annoying than "Documents and Settings".

  74. db dude says:

    Then we have SQL server which saves *data* files to C:Program FilesMicrosoft SQL ServerMSSQL[version].MSSQLSERVERMSSQLDATA instead of C:ProgramData.

  75. Start→Programs Start→Documents... etc says:

    Worked like a charm. But can't wait to hear the story of why we get a big 'Bong – Access Denied' when we first click on C:Documents and Settings in Vista+ explorer.

  76. Voo says:

    @Even Don't forget that \? only works with absolute, not relative paths.

  77. Neil says:

    @Start etc: Raymond wrote a Windows Confidential article about it, which I'm sure he linked from this blog, otherwise I wouldn't have known about it.

  78. Evan says:

    I don't want to hijack the thread much more than I have so: * there's no short name, * if I try to delete it manually (either by "typing" the whole name or with a wildcard) it just says "The file name is too long." * If I try to 'ren' or 'move' it, it just says the same thing as if I try to delete it. (Actually that's technically a lie… then it says "The file name *or extension* is too long.") * The same is true if I try 'del /s /q "\?<directory name>"' or 'del /s /q "\?d:blah<directory name>"'. It's possible that 'dir' isn't showing me the whole name though; it seems to be cut off. * The backup thing isn't really so much "special" as just "the backup feature within Steam itself." The nice thing about it is it'll compress the stuff for you, and I was shuffling stuff across on a cheapish flash drive, so reducing the amount of data that needed to be written would have helped. But yeah, next time I do this I'm just copying the thing over. :-)

    @Brenton Fletcher: "Don't you remember Windows ME? It had a special presentation for dangerous folders"

    Not just ME. This was true in XP as well, and 98 if memory holds.

  79. Allgaeuer says:

    ["Documents and Settings" was also localized. In German, for example, it was called "Dokumente", as I recall. -Raymond]

    -It's even more worse than that. It's called "Dokumente und Einstellungen" with "A possibly unbeatable record" of 27 characters. ;-D

  80. Adam Rosenfield says:

    @Start: technet.microsoft.com/…/ee851567.aspx .  You can also use your favorite search engine to find numerous articles about "Documents and Settings access denied".

  81. dave says:

    But "Program Files" doesn't contain program files, it contains directories that contain program files.

    (yeah, depends on your preferred terminology: I actually think directories are files, which contradicts my own smartarse remark)

  82. kinokijuf says:

    In the Polish version, “Program Files” is translated as… “Program Files”. Which is pronounced “program feel-ess” and means nothing. Oddly, “Program Files (x86)” is translated as “Pliki programów (x86)”.

  83. Nick says:

    Sorry Raymond,

    But on this article I don't see the logic in your reasoning.

    I found this article on Wikipedia which contains the various translations: en.wikipedia.org/…/Program_Files

    –> Why isn't it then translated in all languages also???

    And like the German version which means 'Programs' instead of 'Program Files'; there the translation went bad?

    I agree with others on this. A badly chosen name. Could have easily been calles: 'Applications' or 'Programs' or 'Apps' or …

    [But this isn't where you go to find your Applications or Programs or Apps. This is the "no user serviceable parts inside" section of the file system. -Raymond]
  84. Olivier says:

    On French Windows versions, the directory used to be called "Program files" but the name was changed to "Programmes" (Programs) when Microsoft started translating names (in Vista, IIRC).

  85. Kwpolska says:

    @Olivier

    At least you do it sanely.  But can you guess what Polish Windows does?  "Program Files" and "Pliki programów (x86)".  Makes perfect sense.

  86. Bob says:

    What I find interesting is that, as of this writing, WLCM2DOS has four hits on Google.  Two from different ways of accessing this blog post. And two already scraped copies I'm scared to click on.  I'm simply amazed at how fast content is stolen/liberated nowadays.

  87. Bob says:

    For completeness, Bing has more hits, but only the two from this blog are really hits on WLCM2DOS.  The other ten are hits on :   wlcm2 dos

  88. Joshua says:

    [This is the "no user serviceable parts inside" section of the file system. -Raymond]

    I highly doubt anybody believes this anymore.

  89. Anon says:

    There's a lot of misuse of localization resources here. The DISPLAY NAMES of special directories are localized in modern versions of Windows (i.e. versions of Windows which are not a decade old.)

    This has NO EFFECT on the actual, physical location of them on the disk, nor does it have any effect on the method(s) you're supposed to be using to access them.

  90. Start etc says:

    Ah yeah, sorry. That comment was rather flippant. I was making fun of the fact that "Documents and Settings" was shortened to resolve the MAX_PATH thing but the 3 character less "Program Files (x86)" was retained (or maybe introduced). Having the "Access Denied" thing pop up was disconcerting when moving to Windows 7, but I guess that would count as rummaging around the pantry to many users, and an application's internal program files can be forced by developers to use shorter paths, I guess. Like a nice descriptive name with space(s) in the path leading to an app's location, but then HLOWLD32.dll located inside the actual location.

    From the technet article "Blocking List contents also has the pleasant side effect of removing an attractive nuisance for new programmers, who may be tempted to continue the tradition of those older applications." Heh, "Program Files" definitely had a similar benefit.

  91. 640k says:

    MAX_PATH ought to be enough for anybody. Or at least for hello world, which only needs a 160 character path.

    C:Documents and Settingsfirstname.lastname.DOMAINDocumentsVisual Studio 2013ProjectsMyCompany.MySolutionMyCompany.MyProjectPropertiesAssemblyInfo.cs

  92. morlamweb says:

    I'm not sure what everyone's problem is with the name Program Files.  Is it because of the space in the name which require one to enclose paths in quotes?  Or is it the strictly literal reasoning behind the name, as discussed in Raymond's post?  While I don't agree that there are "no user servicable parts" in Program Files, and the reasoning makes little sense to this technically-minded audience in 2013, I try to put myself into the position of the people who named the folder 20-ish years ago.  As a technically-minded manager circa 1993 (or whenever the name Program Files was decided upon), making decisions about making the OS usuable to non-technical people, I can understand how someone would arrive at that name.

  93. Silverbacknet says:

    @morlamweb: Because a lot of the readers of this blogs are programmers who've been around about as long as the name change, and have an exceedingly difficult time letting go of anything. Others are just trolls.

    @Adam Rosenfield: Trouble is, you'll find _lots_ of forum and comment posts offering advice on how to "fix" the permissions, instead of pointing out the new locations. It's even more common with the old "Application Data" and "Start Menu" folders.

  94. Anonymous says:

    > C:Program Files (x86)MSBuild12.0binamd64

    > @Raymond: Why do a path contain both "x86" and "amd64"?

    I know some folks who worked on this.  The reason it's in "Program Files (x86)" is that the installer itself is a 32-bit binary.  They did that so it would work everywhere.  (Unless one day ia-32 binaries won't run everywhere.  Cf. 16-bit apps.)  And it happens to installs tools for multiple arichtectures.

    Also the authors are not nitpicky people and aren't bothered by the irony.  (A prerequisite for staying happy working at Microsoft, it would seem.)

  95. baltasarq says:

    When Microsoft came with "Program files" as the name for that directory, was obviously trying to do the right thing. However, it was just a poor decision as it was "documents and settings". It is unnecessary long (even in English!), and it has an space in it, leading to incompatibility problems and strange internal algorithms, such as "try first "programfiles", then "program files", etc. Talking about translations, in Spanish this folder is "Archivos de Programa"… uff… 20 characters is lengthy, just for the folder name.

    If you want a scary name, then use "_app_files" or something. It is also important to note that the name the directory has in disk and the name the directory is shown to users does not necessarily has to be the same thing. You can always do a logical mapping. I don't get why translations, for example, need to affect the actual folder.

  96. Anon says:

    @640k

    I could write a page on the idiocy of workspaces in %UserProfile%.

    Or the idiocy of that 'Enterprise' naming convention.

    Or the idiocy of FName.LName.DOMAIN account naming, and how you should only have .DOMAIN profiles if your system is misconfigured or you had severe OS issues.

    Instead, I'm going to point out that VS2013 can't be installed on Windows XP, the last OS to use Documents and Settings.

  97. Anon says:

    @baltasarq

    You're never supposed to refer directly to ANY system directory. You're supposed to ask the OS for them. That's why nothing that works with "Documents and Settingsusername" that is written properly will break on "Usersusername", because %UserProfile% is always going to point to the right place.

    And translation DOESN'T affect them.

Comments are closed.