Timeline for Why does 64-bit Windows need a separate "Program Files (x86)" folder?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 28, 2016 at 21:59 | comment | added | itmuckel | I guess there is no company behind Linux forcing it to remain backwards compatible. Another reason might be that the Linux-OS-API doesn't change so much? | |
| Oct 11, 2014 at 3:04 | comment | added | shortstheory | Why don't Linux based OSes suffer from the same problem? | |
| Jun 30, 2012 at 15:25 | vote | accept | Stephen Jennings | ||
| Jun 29, 2012 at 17:12 | comment | added | BlueRaja - Danny Pflughoeft | (cont.) But, they don't, because they don't want existing code to have to change between versions, leading to HUGE bugs that EVERYONE encounters, which IMHO is far worse and more time-consuming for us developers than having to fix non-compiling code between versions. The same issue occurs with native programs running different versions of the same .dll's. | |
| Jun 29, 2012 at 17:11 | comment | added | BlueRaja - Danny Pflughoeft | @Andy: I think you are confusing backwards-compatibility of the API with backwards-compatibility of the compiled program. For example, in .Net, a program compiled for .Net 2 will only run in the .Net 2 runtime anyways, so upgrading Windows or .Net does not affect the user either way, because they must have both the older and newer version of the .Net runtime installed. What COULD be affected is the code itself - Microsoft could fix some serious bugs, at the cost of some programs not compiling anymore (which would then need to be fixed in order to compile under the newer runtime). (cont.) | |
| Jun 29, 2012 at 17:05 | comment | added | Andy | @BlueRaja I think MS gets backwards compatability exactly right; consumers, if they'd have to buy all their software over again (or find alternatives for stuff that is no longer produced) might as well just move to another platform. Compatability ensures that the investment in the software they already own maintains is value, as opposed to becoming worthless just because a new version of Windows is released. People want things to "just work" How would you do that if you keep breaking backward compatability? | |
| Jun 28, 2012 at 2:53 | comment | added | David Schwartz | @BlueRaja: I agree. | |
| Jun 28, 2012 at 2:38 | comment | added | BlueRaja - Danny Pflughoeft | @Jarrod: Actually, as every developer knows, Microsoft values backwards compatibility too highly. Literally every API they have has legacy methods they refuse to remove, and often serious bugs they refuse to fix, because they are afraid of breaking older programs that were written for that API. The same is true of most API's, but not to anywhere near the extant of Microsoft's. | |
| Jun 27, 2012 at 22:06 | comment | added | David Schwartz | @Tiberiu-IonuțStan: Special workarounds beyond the scope of this question are used for those applications -- more of Microsoft's insane devotion to backwards compatibility. | |
| Jun 27, 2012 at 22:01 | comment | added | oxygen | According to your explanation it does. According to backwards compatibility it also does, for applications which didn't resolve the Program Files folder correctly using the recommended APIs. | |
| Jun 27, 2012 at 21:37 | comment | added | David Schwartz | @Tiberiu-IonuțStan: It makes no difference which one is renamed. All that matters is that they differ. | |
| Jun 27, 2012 at 21:24 | comment | added | oxygen | @David Schwartz You got it the other way around. The 32 bit apps folder was the one that was renamed. This will still allow for accidental 64 bit loading from the Program Files folder, which now contains the 64 bit apps. Also, the question has nothing to do with SysWOW64 and other inside ./Windows/... folder renaming or remaping (or registry renaming/remaping). | |
| Jun 27, 2012 at 20:23 | comment | added | Andy | @JarrodRoberson David is correct; you're assuming that all third parties would also utilize the PE format. MS doesn't have any way to ensure that, and it'd only take one not playing by the rules to blow up the system. | |
| Jun 27, 2012 at 20:08 | comment | added | David Schwartz | @JarrodRoberson: Quite the reverse, it's because Microsoft values backwards compatibility extremely highly. | |
| Jun 27, 2012 at 20:06 | comment | added | user22908 | Windows has had Win32 Portable Executable File Format (PE) since 2002, which was designed just for the seamless transition to 64 bit executables. They could have spent the time to make a transparent system that just worked, they could have modified the exe loader, and all the .dll files are listed in the registry. Finding and using the correct ones isn't that big of a deal, it just takes wanting to do it. As usual this is primarily because of Microsofts culture of short sightedness. If they valued backward compatibility highly they would make things like this more elegant and seamless. | |
| Jun 27, 2012 at 19:57 | comment | added | Dan Is Fiddling By Firelight | @user973810 True. I meant that there wasn't anything equivalent. C:\CmpnyNme\AppName\AppName.exe was a common pattern for installs. | |
| Jun 27, 2012 at 19:29 | comment | added | Darth Egregious | Windows 3.1 didn't support long file names, so it wouldn't have been able to have a 'program files' folder. | |
| Jun 27, 2012 at 19:26 | comment | added | Dan Is Fiddling By Firelight | IIRC Win3.1 didn't have a program files directory (or most apps ignored it); as a result there wouldn't be any legacy win16 apps looking for stuff in program files to begin with. Instead IIRC shared libraries were often plonked somewhere in the windows folder itself. Win32 having windows\system and windows\system32 is an artifact of that. | |
| Jun 27, 2012 at 19:07 | comment | added | David Schwartz |
@Synetech: I'm talking about programs that pre-date (or don't use) WinSxS. As for "What programs go around hunting for random DLLs in %programfiles%", many do. If you don't believe me, go to a CMD prompt, do cd %programfiles%\common files and then dir /w/s *.dll.
|
|
| Jun 27, 2012 at 18:40 | comment | added | Synetech |
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. Besides, how exactly would a 32-bit program "find a 64-bit DLL and try to load it"? What programs go around hunting for random DLLs in %programfiles%? If it is a shared DLL, then it goes in WinSxS; if it is not shared, then it is up to the programmer to manage their own DLLs. The part about it being done as a convenience for programmers reasonable though.
|
|
| Jun 27, 2012 at 18:18 | history | answered | David Schwartz | CC BY-SA 3.0 |