Timeline for Why does 64-bit Windows need a separate "Program Files (x86)" folder?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 28, 2012 at 15:29 | comment | added | Jason Locke | Just re-read this.. he said it better in his replies - superuser.com/a/442253/142951. If you're not a developer you might not see the purpose. | |
| Jun 28, 2012 at 15:25 | comment | added | Synetech | Huh? | |
| Jun 28, 2012 at 15:20 | comment | added | Jason Locke | I thought you wanted an explanation. Few apps use CommonFiles? I have 35 different applications that have entries there. It's a safer place to store shared components than the System32 directory. Your statement that few apps use this is debatable. Quoting you: "They didn't have to jump through these hoops to allow for 32-bit and 16-bit programs on the same system. I don't recall ever seeing a ProgramFiles (16) or some such [...] The part about it being done as a convenience for programmers reasonable though." Well, yeah.. programmers do. We write the applications after all. | |
| Jun 28, 2012 at 14:58 | comment | added | Synetech | Oh, and as for 95/98, who said anything about that? Even XP had a 16-bit subsystem (the NTVDM). | |
| Jun 28, 2012 at 14:58 | comment | added | Synetech |
How does ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in \32\blah` or \blah\32; either way, they are separated. If anything, the current way separates the app's components (and also duplicates them unnecessarily since few apps use CommonFiles for resources and such. Besides, you make it sound as though apps are dumping their DLLs in a common bucket. It's easy enough to keep an app's 32-bit DLLs with its 32-bit exes and it's 64-bit DLLs with it's 64-bit exes.
|
|
| Jun 28, 2012 at 14:43 | history | answered | Jason Locke | CC BY-SA 3.0 |