Microsoft's Windows 95 put spaces into "c:\My Documents" and "c:\Program Files" so that developers targeting Windows were forced to support spaces in filenames.
Of course, in those days if an OS upgrade broke some third party software, the end user paid for an upgrade. So although Microsoft forced developers' hands, the developers all got paid for their trouble. And you'd only have your hand forced that way once or twice a decade.
Windows at the time was also all about the GUI file-pickers. Breaking the command line? Shell scripts? What are those?
Did they intentionally use only folder names with spaces that are at least 9 characters long and with the space after the first 6, so that the 8.3 version contains no spaces?
I was curious about a deep dive into this topic, and skimmed the MS doc pages after a Google search. They mentioned different Windows APIs and Long file names, but the only mention of the tilde compat layer I found was very superficial ("some file-systems" use the tilde as special character), so I abandoned my initial interest in getting up to speed on this during a 2min weeekend read.
I remember trying to install Visual Studio in the mid-late 2000s (when SSDs make hard drive space small again) to a directory other than C: and found that after following a rather convoluted process you could only actually move maybe 20% of the install files off C:.
That doesn't sound right. Microsoft is obsessed with backwards compatibility, going so far as to accommodate programs that were writing to Windows' private memory just to preserve it. Deliberately breaking programs isn't in their ethos at all.
The new filesystem APIs were introduced with Windows 95, so there was no backward compatibility to break. New programs using those new APIs were forced to support spaces in directories. Using spaces in the system directories forced application developers to consider that scenario and deal with it appropriately.
Meanwhile, DOS and Windows 3.1 applications that did run on Windows 95 could access files under a backward compatible 8.3 scheme, like C:\Progra~1\ instead of "C:\Program Files".
I'm thinking of the transitions from Windows 3.1 to Windows 95 (IIRC introducing 32-bit and filenames longer than 8 characters) and the transition from Windows 95 to Windows XP (IIRC introducing a proper permission system, thus breaking anything that relied on being able to write things outside of user-owned folders)
I agree they were famously accommodating in those days. But they also had enough market power that if they said users could only write to one folder and it had a space in the filename, developers who disliked it couldn't vote with their feet.
And yet... if you create user using a display name e.g. Peter Čenička in AAD and deploy a PC with intune you will get home folder called PeterČenička.[0] It breaks SO MANY things. And no, that beta UTF8 system wide setting does not work with 3rd party apps.
I just dont understand why they dont use part of the email address as the home folder name.
And just because of this stupidity, user display names have to be without any of these characters
Windows set up with Microsoft Account uses abbreviated e-mail for user names, because UTF-8 breaks apps, including many East Asian apps.
non-Western Windows users always knew never to use anything outside ASCII for usernames, passwords, or any programmatically used identifiers. It's English users that haven't learned it.
They changed from \Documents and Settings to \Users in Vista, alongside other profile rejiggering (e.g. introducing AppData folders). By that point software had either been fixed or would never be fixed, so keeping a space in the name wasn't particularly useful.
IIRC, they changed it to get more value out of the 260 character MAX_PATH. I know there was some sort of manifest to enable longer paths, but I'm not sure what the current status is.
The status quo is that officially, you still have to both set a registry key (or equivalently, set an option in the Group Policy Editor) and add an element to each application manifest.
The official workaround at runtime is to use the "\\?\" prefix with an absolute path to create an unrestricted verbatim pathname. For instance, the fs::canonicalize() function in Rust will always return such a pathname, to many programmers' dismay, since outside tools often choke on them.
The unofficial workaround is to set the undocumented IsLongPathAwareProcess bit in the process's PEB. The Go runtime does this, but silently falls back to "\\?\" prefixes if the Windows version is too old.
(Note that in general, canonicalizing paths is safer on Windows than on Unix-like systems, since open directories cannot be renamed.)
OneDrive breaks that convention. Last two companies I was at, the corporate location was something like "$HOME/OneDrive - $COMPANY". That the two companies had the same format tells me it is a default and/or suggested practice for some reason.
NPX on windows was broken for years when your username had a space in it. Never underestimate how long bugs can stay around when it doesn't affect any of the developers and for everyone else the workaround is quicker than fixing it
My last name has an apostrophe in it. This isn't super weird or anything, there have been "O'Haras" and "O'Neills" (with 2 Ls) forever.
And yet whenever I deal with a computer system I don't put the apostrophe in because even in 2024 it is completely jacked up. Sometimes it's just disallowed. Sometimes I get "\\'" showing up. Sometimes I get "'". I've seen "’". One time, one system accepted it, but another system that accessed the same data didn't allow apostrophes so the person using the second system couldn't access the record, and it took 2 phone calls and 3 people to come up with a workaround.
It doesn't work often enough that I don't even try anymore. There are just too many opportunities for it to get forgotten or handled improperly from all directions.
I had fun in the vmware-broadcom transition because the broadcom portal doesn't allow that, but the vmware portal did. Not even in my username, just in the surname field. The new portal ate it on that so hard, I wasn't even allowed to create a ticket to do anything about it.
Not as bad as when I was once issued a first.o'last@corp email address though ..
>Not as bad as when I was once issued a first.o'last@corp email address though
Oh, man, that happened to me too, way back in the late 90s. I had forgotten about that.
It broke things all over the place. Even now you run into the occasional validator that is convinced that the plus sign is not valid in email addresses.
> Even now you run into the occasional validator that is convinced that the plus sign is not valid in email addresses.
These are intentional IMHO - force people to use their actual email address so a potential breach can't be tied back to the service. That's the only reason why someone would use a + in the first place.
Some validators are silly regular expressions that someone wrote in a minute without thinking about it ("Mastering Regular Expressions" has a regex associated with it for better matching an address; that regex is quite the sight to behold). And disallowing + is a crummy solution to whatever "force people to use their actual email address" means given that someone with full control of a domain can invent the alias whatevertheywant@example.org instead of using something with a + in it, or they can spin up an alternate address on some alternate provider, etc.
Other reasons folks use + in their email is to do mail routing (except where crappy web services disallow the + because they relied on a crappy regex) but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.
> but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.
Easy. Say I subscribe as "username+servicename@gmail.com" everywhere, when I get spam at that email address that service must have been either breached or sold off my data.
I built the authentication system on our website and as a regular user of Gmail + aliasing I was very surprised when my brother pointed out our website didn’t allow them.
Turns out the default for Microsoft’s ASP.NET Identity Framework is to disallow special characters, but simply setting a flag in its configuration rectified this.
There may be a Unicode character that looks like apostrophe but has no quoting semantics. I use an arrow instead of greater-than symbol in my prompt for the same reason. To avoid copy/paste issues.
Non-ASCII characters in email addresses have even worse compatibility issues than punctuation characters. Punctuation fails because people don't know the standard. Non-ASCII fails because people don't know the latest standard.
> One time, one system accepted it, but another system that accessed the same data didn't allow apostrophes so the person using the second system couldn't access the record, and it took 2 phone calls and 3 people to come up with a workaround.
There's still a lot of organisations that somewhere in their e-mail processing chain cannnot deal with 4-letter TLD e-mail addresses*. Even worse is that the front-end is often a relatively new framework and will happily accept your e-mail, only to then have it silently fail forever. Mercifully a lot of those organisations have their customer service authorized to change your e-mail address manually, but if they don't.. good luck.
But sometimes I don't have control, e.g. another person is inputting the data and dutifully duplicates my name. That's how I ended up with the 2 phone calls/3 person situation, which happened about a month ago.
Hell, my driver's license is missing the apostrophe because the system doesn't accept it.
When somebody is trying to find me in a computer there's a whole litany of things they have to try, including assuming "First O'Lastame" got bashed into "First O. Lastname".
I think about this every time I read an article extolling the wonders of technology.
Generally, countries' systems only handle characters in names that are common in that country. Virtually no banking or ID system in Europe or the USA will handle Chinese names, for example. Even if they did at the technical level, it wouldn't actually help at a holistic level, because people who interact with these systems (bank tellers, policemen, etc) can't be expected to recognize any writing system in the world.
So, the reality is that you have to adapt to the country you're trying to live or do business in and the name systems that they can actually use. This can even mean you have to adopt a name that people can actually pronounce, as many Chinese people do when interacting with people outside East Asia
For example, Chinese is particularly sensitive to tone accent, which extremely few people outside that area can even distinguish, leading to hopeless mispronunciation. Consider that Ma2 and Ma4 are completely different words for a Chinese speaker, while a French speaker who hasn't studied this wouldn't even be able to tell that you are intentionally pronouncing things differently and not just your intonation.
And for a reverse example, if you want to move or do business in Japan, you should adopt a well-known Japanese pronunciation of your name, as otherwise Japanese speakers, who have an extremely limited syllable inventory compared to most other languages in the world, will just not be able to follow your name.
Problem is, the design of Unix shells is older, and they have some parts which automatically split on space if not handled carefully. This is really annoying.
