4 ms·
I built a new PC in 2007, bought Vista Ultimate OEM, installed it and added all patches up to that point. Two things became immediately obvious: - As others ha
by T-A 9y ago
I built a new PC in 2007, bought Vista Ultimate OEM, installed it and added all patches up to that point. Two things became immediately obvious:
- As others have pointed out, UAC was way too active. Just about any application you cared to launch required permission dialogs to be clicked through - irritating to everybody, scary to most users, and quickly ineffective as everybody stopped reading and just reflexively went for the OK button.
- Lots of legacy applications broke for the most trivial of reasons: they were written to store configuration and other data in their installation directory, which defaulted to "C:\Program Files". This worked fine on Windows 9x, which by default allows user-owned processes to do just about anything, but not on NT, where writing to Program Files requires elevation.
So new Vista owners would click through a bunch of obnoxious UAC popups to install their favorite Windows applications, click through more UAC popups to launch them, and then watch them crash or mysteriously lose all their data.
You got extra loser points if you went for the shiny new 64 bit version, in which case your legacy 32 bit application installer was more than likely to try its luck with "Program Files" instead of "Program Files (x86)". Would it really have been so terrible to leave the old directory alone and call the new one "Program Files (x64)"?
None of this was terribly hard to fix if the application was still supported, but it did require the user to upgrade, often at a cost. Worse, if you were a small indie developer, releasing an upgrade now pretty much required buying an expensive certificate to sign it, lest UAC keep warning your users that they were launching an untrusted file from the scary internet. So lots of small free- and shareware apps which people loved were abandoned, undoing part of the Windows platform's greatest advantage: its large library of existing applications.
- CydeWeys 9y ago> Would it really have been so terrible to leave the old directory alone and call the new one "Program Files (x64)"? Or alternatively, why was breaking them out required in the first place? To this day I frequently end up having to look in two places to find something, because it's never obvious which of the two Program Files it should be in. Pre-64-bit Windows there was only ever the one place. This is a permanent usability regression. And of course, I wouldn't even need to be digging through there in the first place if the Start menu launcher just worked, but no, they had to junk it up with Cortana, which is so incompetent it can't even find installed applications by name. More details on my Cortana rant here: https://news.ycombinator.com/item?id=15758641 https://news.ycombinator.com/item?id=15758641
- njovin 9y agoI absolutely agree with this. There should have just been a 'Program Files' folder and if a conflicting program was already installed, the architecture could be appended to the name of the newer install's directory (C:\Program Files\Foo, C:\Program Files\Foo (x64)).
- pjc50 9y agoI tried to find an authoritative answer from Raymond Chen, and the closest I can find is https://blogs.msdn.microsoft.com/oldnewthing/20081222-00/?p=19763 https://blogs.msdn.microsoft.com/oldnewthing/20081222-00/?p=... and linked http://brandonlive.com/2008/12/22/why-does-windows-put-64-bit-binaries-in-system32/ http://brandonlive.com/2008/12/22/why-does-windows-put-64-bi...
- noisem4ker 9y ago>applications broke for … they were written to store configuration and other data in their installation directory, which defaulted to "C:\Program Files" Vista tried to take care of that by transparently redirecting to %LOCALAPPDATA%\VirtualStore, writable with user privileges. The feature is called Virtual File Store, and comes together with an analogous Virtual Registry Store. See https://msdn.microsoft.com/en-us/library/windows/desktop/bb756960.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... at Virtualization
- wvenable 9y ago> Would it really have been so terrible to leave the old directory alone and call the new one "Program Files (x64)"? "Program files" is localized so it's not even "Program files" in all languages. Installers that looked to that folder were doing it wrong anyway and wouldn't work on non-English machines.
- GuB-42 9y ago"Program Files" isn't localized, at least not on the French version of Windows. Only user content is ("My Documents", "Desktop", ...), and even then, some of them are just links to non-localized directories. You could, however, change the path of "Program Files" so your point still holds.
- wvenable 9y agoYou are correct now but Program Files was fully localized in XP and below. In Vista and beyond, it uses junction points to the non-localized names (something I just learned).
- colejohnson66 9y ago> Would it really have been so terrible to leave the old directory alone and call the new one "Program Files (x64)"? The same thing happened with the System32 folder. On 64-bit systems, System32 actually contains the 64-bit(!) versions, and the equally confusingly named SysWOW64 contains the 32-bit versions. https://stackoverflow.com/questions/949959/why-do-64-bit-dlls-go-to-system32-and-32-bit-dlls-to-syswow64-on-64-bit-windows https://stackoverflow.com/questions/949959/why-do-64-bit-dll...