Comment by alpaca128
4 years ago
Seems like MS had the same idea according to an answer in the link:
> Microsoft intentionally made programs install to C:\Program Files on Windows 95+ to force programmers to deal with spaces in filenames.
4 years ago
Seems like MS had the same idea according to an answer in the link:
> Microsoft intentionally made programs install to C:\Program Files on Windows 95+ to force programmers to deal with spaces in filenames.
I wish they did "User Files" instead of "Users" too, because so much software breaks on the home area having a space in it.
Not least, it makes writing scripts for various shells and getting the quoting rules right an absolute pain as well...
They used to. The folder was called `Documents and Settings` until Win7.
"Documents and Settings" still exists on Windows 10, as a soft link to "Users".
96 replies →
In the Win95 era, it was "C:\My Documents".
Huh, spaces. There's way too much software, especially on Windows, that breaks when there are Cyrillic characters in a path. I'll let you guess how I found out.
I had a really odd one last year where a Grave I ( well known brand name) got converted by office/excell into a Double Grave I.
The double grave I is used by some obscure orthodox religionious texts
A friend had the username "Rubén" and jfc it broke everything other than windows itself xD
8 replies →
If you have a username with your full name (plus point if you have special characters in your name), you will get the whole deal with shitty programs. I’m not sure if it’s me, but there were cases I simply could not use a program installed in such a location, to the point where at my previous (admittedly shitty) workplace, we often installed software in a root location…
Laughs in C:\PROGRA~1\ (try it, still works in Windows 10)
Apart from what others mentioned, that can only work if the file system automatically creates 8.3 names. NTFS does not necessarily do that (https://docs.microsoft.com/en-us/windows-server/administrati...)
There is no guarantee that the short name has that. In fact on a lot of German Windows installations it was PROGRA~2.
Well, on my disk PROGRA~1 is "Program Files" and PROGRA~2 is "Program Files (x86)", so still works :)
11 replies →
Truly lifesaving for when she'll quoting gets in the way.
You've got a stray single quote in your shell. :)
2 replies →
And yet they introduced C:\ProgramData in later versions.
Imagine if they made programmers put 64 bit DLLs in a "System32" directory and 32 bit DLLs in a "SysWoW64" directory. That would really keep 'em on their toes!
You should look into the behavior of the /windows/sysnative link. It appears and disappears depending on whether your process is running as 32 bit or 64 bit.
Programmers should never put DLLs in those folders... Or even ever touch them.
7 replies →
They already hamstrung themselves with LONG because DWORD just wasn't good enough and now long can't be 64-bit either.
why "yet"?
one occurrence is enough to make devs care about it
It not only keeps people on their toes due to the whitespace. The folder name is even localized. E.g. with german settings there is C:\Programme and c:\Programme (x86).
You can still use the English names, though.
I wonder how much global work could have been saved if Microsoft also provided a covered interface for all paths in the system. Not sure if there is any, but one good implementation might save thousands of poor implementations required to handle it.
You mean like the Environment.SpecialFolders enum?
https://docs.microsoft.com/en-us/dotnet/api/system.environme...
There are several other classes that take care of getting folders, least of which checking system variables.
You have %Appdata% and friends.
On the other hand their case sensitivity behaviour means that “cross-platform” Java applications can break if they are run on a non-windows platform where opening files is case sensitive (unlike on windows)
It's actually a feature.
Easier to add a flag to ignore case rather than fix bugs where files only differ by case and are therefore overwritten on a case-insensitive filesystem.
Then they made poor APIs so that you have to do this to get it correct:
https://docs.microsoft.com/en-gb/archive/blogs/twistylittlep...
In nix at least you can call execve or other APIs that take a char argv[] and the whole problem is largely solved and you don't need to quote things.
I just wish they had a decent way to execute programs with arguments that might include spaces. But no, every program can do argument delineation differently.
And Microsoft even provides three different slightly incompatible ways to parse arguemnts: CommandLineToArgvW, the CRT and cmd.exe.
I know that at least like, idk like 3-5 years ago, when I had gotten a new windows laptop (windows 7 or 8 I think), setting the main account to have the name "" (without the quotes), caused some problems with the basic functioning, including, I think, with some pre-installed programs,
So, some things were still being handled not quite right (whether that's because it shouldn't be allowed to be the username, or because programs should handle it being in the path, I'm not sure, but probably one of those.)
And then to really mess you up and ensure you handle parens properly, threw “(x86)” into the mix. (A real pain on some REPLs as well as dealing with environment variables).
Except for programs that were too old / obscure to fix I guess. I think at least the Symbian Development Kit was such that builds would fail with strange errors unless you installed it in any other path than the default immediate subdirectory of C:\, let alone under "Program Files".
Plenty of new stuff does this. As long as youre not .net or javascript nobody scrutinizes the trash work developers charge money for.
Funny, in the Italian Win9x it is C:\Programmi, which I always thought was more convenient because of the lack of spaces :)
Sure. Microsoft only ever ships features
At one time there was no number 0. Half of binary was missing.
Shame it wasn't
> C:\P̷̧̽r̸̬͘ŏ̵̮g̷̜͘r̸̦̋a̴͎̒m̶̲̈́ ̷̠̉F̵͇̈ĩ̴̫l̶̨͗ë̵̦s̸͚͆\
There was a short path name IIRC like prog~1
Could you please link the reference?
C:\PROGRA~1
Easy fix!