Humor: Interview with an Ex-Microsoftie Who Used to Name OS Folders(secretgeek.net)
secretgeek.net
Humor: Interview with an Ex-Microsoftie Who Used to Name OS Folders
http://secretgeek.net/ex_ms.asp
133 comments
Maybe we should formulate a Microsoft equivalent of Godwin's Law: "As an online discussion about Microsoft grows longer, the probability of an ex-Microsoftie bringing up stack ranking approaches 1."
("Ballmer's Law" has a nice ring to it..)
("Ballmer's Law" has a nice ring to it..)
Stack ranking wasn't around when any of this was done. This is early 90's stuff when stack ranking didn't even start until the late 90's.
SysWOW64 is from the 90s?
The Windows on Windows name was also used for the 16-bit compatibility layer, so the WOW part is from the early 90s.
How true. I remember .NET Servers were everywhere circa 2002, e.g. BizTalk Server.NET. Things never change in M$ land, now it's all Azure.
Haha, amazing. I literally laughed out loud at:
Why is there a 'WOW' in the middle of the name?
—I was typing System64 and half way through I just thought: "WOW, nature is beautiful!"
Why is there a 'WOW' in the middle of the name?
—I was typing System64 and half way through I just thought: "WOW, nature is beautiful!"
Amusing, but the standard Unix file system is nothing to be too proud of. I'd very much like to see a file system layout re-imagined for the 2010s.
Binaries? Libraries? Let's stick 'em in `/usr`! Oh, but where do user files go? I know, `/home`! What about all this other stuff? Eh, `/etc` will do. Unless it won't, in which case `/var` is the obvious solution. Or maybe even `/opt`, if we're feeling especially hip today.
usr doesnt mean user, it meant Unix System Resources, and a user of the system usually puts his stuff at home, what would you like it to be otherwise /users ? That would be describing the users of the system and not where their stuff is, and users are described in /etc/passwd together with their passwords, sort of.
/etc isnt called /conf or configuration because it contains examples, scripts and other small stuff as well, which is etcetera.
/var is for variable data like logs and pid files, not meant to be changed by the user directly
/opt sucks and is for losers who dont know about /usr/local or how to install stuff in ~
The Linux way makes much more sense than Windows or MacOSX way. binaries are in bin libraries are in lib, whats not to like?
/etc isnt called /conf or configuration because it contains examples, scripts and other small stuff as well, which is etcetera.
/var is for variable data like logs and pid files, not meant to be changed by the user directly
/opt sucks and is for losers who dont know about /usr/local or how to install stuff in ~
The Linux way makes much more sense than Windows or MacOSX way. binaries are in bin libraries are in lib, whats not to like?
> usr doesnt mean user, it meant Unix System Resources
It did mean "user" originally. Home directories were usually put there.
However, the root filesystem was typically very small. So very early on in UNIXs evolution things that were large and not needed during system boot ended up finding homes in /usr, simply because it was where the bulk of the disk space was. So you got /usr/bin, /usr/dict, ...
Eventually /usr got so full of non-user content, UNIX-based OSes started putting home directories somewhere else entirely (i.e. /home on linux for example) Because the user to home directory mapping was just held in /etc/passwd, it was much easier to move the users than everything else. Later, the "Unix System Resources" backronym was coined.
So mintplant is right: /usr is very much a historic wart on the UNIX filesystem layout.
It did mean "user" originally. Home directories were usually put there.
However, the root filesystem was typically very small. So very early on in UNIXs evolution things that were large and not needed during system boot ended up finding homes in /usr, simply because it was where the bulk of the disk space was. So you got /usr/bin, /usr/dict, ...
Eventually /usr got so full of non-user content, UNIX-based OSes started putting home directories somewhere else entirely (i.e. /home on linux for example) Because the user to home directory mapping was just held in /etc/passwd, it was much easier to move the users than everything else. Later, the "Unix System Resources" backronym was coined.
So mintplant is right: /usr is very much a historic wart on the UNIX filesystem layout.
> /opt sucks and is for losers who dont know about /usr/local or how to install stuff in ~
I disagree. /opt is for systemwide installations of monolithic software by dumb companies that can't fit their software into the standard layout. In the Linux FHS /usr/local/ is supposed to be for non distribution installed software that nonetheless uses the standard layout with /usr/local/{lib,bin,doc} etc. In /opt you usually have something like /opt/somesoftware/ and some non-standard hierarchy underneath.
I disagree. /opt is for systemwide installations of monolithic software by dumb companies that can't fit their software into the standard layout. In the Linux FHS /usr/local/ is supposed to be for non distribution installed software that nonetheless uses the standard layout with /usr/local/{lib,bin,doc} etc. In /opt you usually have something like /opt/somesoftware/ and some non-standard hierarchy underneath.
> I disagree. /opt is for systemwide installations of monolithic software by dumb companies that can't fit their software into the standard layout.
You are actually fully agreeing with what was said !
You are actually fully agreeing with what was said !
+1 for /opt. We bundled our runtimes and data, and our stuff still works 10 years later (although, yeah, security vulnerabilities, although technically none of it was remote).
Um, good luck with your packages where you relied on the OS. Let's not talk about stdlibc++.
Hint: if you really want your stuff to work for a long time, depend on the kernel and nothing else.
/opt is really where: /opt/importantstuff goes. The stuff where they bundled the libc because Debian changes too fast. Freaky stuff. Telco stuff...
Um, good luck with your packages where you relied on the OS. Let's not talk about stdlibc++.
Hint: if you really want your stuff to work for a long time, depend on the kernel and nothing else.
/opt is really where: /opt/importantstuff goes. The stuff where they bundled the libc because Debian changes too fast. Freaky stuff. Telco stuff...
> /var is for variable data like logs and pid files, not meant to be changed by the user directly
One would certainly never dream of keeping entire web sites in there!
One would certainly never dream of keeping entire web sites in there!
Well thats just wrong, thats what /srv/http is for, to serve http, but historically websites were served from your home, as then they where known as home (personal) sites, and they're still known as "home sites" in many non-english languages.
Now when you have web applications they can be in /srv as well and the database is usually wrongly put in /var (looking at you mysql) but what you gonna do when you need a system user, just like a users stuff is supposed to be in home so put your database there /home/postgresql/its_datas here, as anyway you need to run the db as its own user.
Makes sense no?
Now when you have web applications they can be in /srv as well and the database is usually wrongly put in /var (looking at you mysql) but what you gonna do when you need a system user, just like a users stuff is supposed to be in home so put your database there /home/postgresql/its_datas here, as anyway you need to run the db as its own user.
Makes sense no?
My point was about Apache's default document root.
The default for apache is/was /var/www/html.
usr originally contained user files (http://cm.bell-labs.com/cm/cs/who/dmr/notes.html). I'm not really sure why or when that changed, but supposedly "Unix System Resources" is a backronym.
/etc stands for Editable Text Configuration
etc isnt called /conf or configuration because it contains examples, scripts and other small stuff as well, which is etcetera.
Doesn't it stand for 'Extended ToolChest' ?
Doesn't it stand for 'Extended ToolChest' ?
Probably a backronym like unix system resources.
It could be called misc as well in my opinion.
It could be called misc as well in my opinion.
Ummm... the Linux way is better than the Mac OSX way?
They both use UNIX architecture...
They both use UNIX architecture...
Historical heritage unfortuantely. /sbin and /usr/sbin are other examples...
http://lists.busybox.net/pipermail/busybox/2010-December/074...
https://news.ycombinator.com/item?id=3519952
http://lists.busybox.net/pipermail/busybox/2010-December/074...
https://news.ycombinator.com/item?id=3519952
[deleted]
Check out GoboLinux's file system structure:
http://www.gobolinux.org/index.php?page=at_a_glance
http://www.gobolinux.org/index.php?page=at_a_glance
I like it! I suppose I am a tad disappointed that it's a distribution in its own right. But they deserve credit for taking a decent first step.
Ick, capitalization in a case-sensititive file-system? Of course, as far as I'm concerned case-sensitivity is generally a misfeature in anything user-facing.
If I remember correctly, their scripts automatically convert lower case letters to uppercase when you are trying to autocomplete typing with TAB. It only does it for the gobolinux-specific uppercase directories
Agreed! I feel retaining case-sensitivity in file systems in 2013 is basically trolling users. I can think of no practical upside; only the opportunity for annoying jokes and tricks.
But what of users (as they often do) descriptively naming files?
I've seen plenty of "Accounts for Proctors' Attention.xlsx" style files. Case insensitivity would lose the case there. :/
I've seen plenty of "Accounts for Proctors' Attention.xlsx" style files. Case insensitivity would lose the case there. :/
There's a difference between case sensitivity and case preservation. FAT32 and HFS+ are examples of case-insensitive, case-preserving file systems.
That there is, but I'm inclined to suggest this behaviour to be more confusing than simply maintaining name identically to input. :/
Not least this can sometimes result in some odd corner cases.
shrug
Not least this can sometimes result in some odd corner cases.
shrug
It seems like the ideal case to me; generous on input, strict on output. In most cases, users won't even know that the insensitivity is there, in which case it will almost never affect them (since users very rarely want two files with the same name, differentiated by case). For users who do know about it, it's not confusing.
What corner cases does it lead to?
What corner cases does it lead to?
Other languages have capitalization rules that are far, far more complicated than English, involving additional characters that either denote capitalization or a semantically different word depending on context.
Personally, I'd aggressively pursue case-insensitivity and treat the problem of "oops the user can't create two files that have nearly the same name" as a much smaller bug than "oops the user can create two files have semantically the exact same name".
Personally, I'd aggressively pursue case-insensitivity and treat the problem of "oops the user can't create two files that have nearly the same name" as a much smaller bug than "oops the user can create two files have semantically the exact same name".
Retain the case, but don't use it when testing for uniqueness. That way, I can type "accounts for proctors' attention.xlsx" and the filesystem will know what I mean. But when I list the contents of a directory, it would show up with its original casing.
Case insensitivity is locale-dependent, so you have to either pick a single locale and confuse users with other locales, or deal with the possibility that you could have two files in your filesystem that have the same name in your locale.
It's not as big of a deal when you're using ZSH autocomplete... but I agree, I like my filesystem lowercase and devoid of spaces.
I am agreed. Although the last time I heard about a major attempt for a modern file system was in Longhorn and all we know how that ended.
I guess there are still some fears to try it again, considering that current file systems in mainstream OS' are "good enough".
I guess there are still some fears to try it again, considering that current file systems in mainstream OS' are "good enough".
Indeed. I think people worked out that metadata indexing over the top is probably better.
I found not just the naming aspect funny, but the whole munging of 32/64 bit files good, too. That's beyond naming atrocities.
Agreed.
To me, it's even more funny when you realize "WOW" actually means "Windows on Windows." Say what??
To me, it's even more funny when you realize "WOW" actually means "Windows on Windows." Say what??
Makes sense to me, then again I know NT inside out...
It's NT's syscall translation layer, CPU mode switching backend and entry point front end. It was originally used to run 16-bit apps on 32-bit platforms but is now WOW64 so is to run 32-bit apps on 64-bit machines.
Basically it's a very light weight virtualisation layer.
And it works well. My circa 1996 RPN calculator I wrote in VC++ works perfectly on 2013 x64 machine.
It's NT's syscall translation layer, CPU mode switching backend and entry point front end. It was originally used to run 16-bit apps on 32-bit platforms but is now WOW64 so is to run 32-bit apps on 64-bit machines.
Basically it's a very light weight virtualisation layer.
And it works well. My circa 1996 RPN calculator I wrote in VC++ works perfectly on 2013 x64 machine.
Don't get me wrong. I know it makes sense once you know what it is. And the result in terms of compatibility and stability is impressive.
Still, when I first heard the phrase "Windows on Windows" I had a chuckle.
It reminds me that I enjoyed the way x86 apps ran on my old Alpha NT machine. If I recall correctly, the process list included "fx32" beside each.
Still, when I first heard the phrase "Windows on Windows" I had a chuckle.
It reminds me that I enjoyed the way x86 apps ran on my old Alpha NT machine. If I recall correctly, the process list included "fx32" beside each.
>Still, when I first heard the phrase "Windows on Windows" I had a chuckle.
The Windows 2000 loading screen had the tagline "Built on Windows NT Technology." They left it there through multiple SP rollouts IIRC.
The Windows 2000 loading screen had the tagline "Built on Windows NT Technology." They left it there through multiple SP rollouts IIRC.
I always assumed that was to placate business customers who might have (justifiably) worried that Windows 2000 was related to Windows 98, rather than descending from NT 4.
NT stands for "New Technology".
For everyone worried about Win98 relation simple "Built on Windows NT" would work.
For everyone worried about Win98 relation simple "Built on Windows NT" would work.
WOW doesn't stand for Windows On Windows. WOW64 stands for Windows On Windows 64 [bit].
Oh, that I didn't fully appreciate. That actually makes it more reasonable. (Not being sarcastic!)
What are you trying to do? Make me feel bad for having a good laugh at the name when I first looked it up? :)
What are you trying to do? Make me feel bad for having a good laugh at the name when I first looked it up? :)
[deleted]
That's really what it is. 32-bit Windows applications on 64-bit Windows are running in what is essentially an emulation layer. It's a fairly thin layer now, but remember that the original 64-bit Windows ran on Itanium. The original Itanium had an embedded (slow) x86 chip for compatibility. I'm not sure if WoW ever used it, but certainly the WoW for Itanium 2 didn't, since it was dropped for that processor.
It's an API compatibility layer to allow 16-bit Windows programs to run on 32-bit Windows -- or, more recently, 32-bit Windows programs on 64-bit Windows.
Recently Microsoft went full Keanu with Windows on ARM or WOA -- but eventually they changed that to Windows RT (which might be actually worse).
Recently Microsoft went full Keanu with Windows on ARM or WOA -- but eventually they changed that to Windows RT (which might be actually worse).
A Linux equivalent acronym would be childish.
Actually it stood the test of time quite well. System directory names are lowercase, short and mostly-standard. Granted, there is the /bin/, /sbin/, /usr/bin/, /usr/local/bin/... stuff, but at least /home/ directory is standard and applications really use it since forever, as opposed to Windows (apps saving user settings to registry, IE6 saving bookmarks to its "Program Files" dir - not sure how it is done now).
One could argue that someone who knew Unix 30 years ago could still use command line in today's Linux without much problems.
One could argue that someone who knew Unix 30 years ago could still use command line in today's Linux without much problems.
At least there are no spaces in the directory names.
Yes and UNIX is really better!
$ mkdir ".. "
$ ls -a
. .. ..
I once accidentally did:
$ touch ./~
# Much later I noticed the "~" file in the directory
# so I mindlessly decided to cleanup:
$ rm -rf ~
Ha that's a classic.
A friend of mine did a "rm -rf ~ /tmp" rather than "rm -rf ~/tmp" on a fast SCSI local disk on his Sun workstation.
His backup strategy of tarring up everything into ~/backup went with that one too. I lectured his ass on that one.
However...
The same guy, no less than 8 years later carried around a DVD-RAM with his single copy of his life's work on it (I assume this was only 8 years of his life) and jammed it in one of those dodgy Pioneer slot loader drives and proceeded to mount it.
bzzzt ... wheee ... clunk ... BANG! DVD span to full speed and promptly shattered taking the drive fascia off and spraying everyone with bits of "I told you so".
He now puts up scaffolding which worries me even more...
A friend of mine did a "rm -rf ~ /tmp" rather than "rm -rf ~/tmp" on a fast SCSI local disk on his Sun workstation.
His backup strategy of tarring up everything into ~/backup went with that one too. I lectured his ass on that one.
However...
The same guy, no less than 8 years later carried around a DVD-RAM with his single copy of his life's work on it (I assume this was only 8 years of his life) and jammed it in one of those dodgy Pioneer slot loader drives and proceeded to mount it.
bzzzt ... wheee ... clunk ... BANG! DVD span to full speed and promptly shattered taking the drive fascia off and spraying everyone with bits of "I told you so".
He now puts up scaffolding which worries me even more...
Luckily I was on an IT maintained machine that takes nightly snapshots of home partitions so I was safe in the worst case. Had I done that on one of my personal machines I wouldn't have been so lucky.
You can't plan for user stupidity. The system paths do not have spaces in them.
No but allowing leading and trailing spaces is not user stupidity. That is design stupidity.
You know like recording numbers as string in the format: "0000000000000000000000000123.23210000000000000"
You know like recording numbers as string in the format: "0000000000000000000000000123.23210000000000000"
The shell by default ignores spaces, you have to specifically force it to acknowledge them by enclosing the name in quotation marks or escaping with a backslash. In that situation, a command line tool should do what it's told, not disobey a direct command. Leave the rubber padded tools for the GUI land.
Rubber padded I do not expect. Retarded I also do not expect.
Explain the validity of:
It at least violates the principle of least surprise
Explain the validity of:
mkdir " "
mkdir " "
mkdir " "
It at least violates the principle of least surprise
Validity? It's a string like any other. It's not mkdir's job to second-guess what I tell it to do.
And I don't see how it violated such principle. You tell it to create a file with spaces - you even emphasized them with quotes -, and you're surprise it did so?
And I don't see how it violated such principle. You tell it to create a file with spaces - you even emphasized them with quotes -, and you're surprise it did so?
It is merely an illustration. The reality is stuff like that occasionally does happen when you use variables and parse results from other commands.
No it's not. If you type
Oh, and it's my computer. I don't want my shell telling me what I'm "allowed" to do. If I explicitly tell it to do something, it should damn well do it!
mkdir ..<space>
Oh, and it's my computer. I don't want my shell telling me what I'm "allowed" to do. If I explicitly tell it to do something, it should damn well do it!
What if you do the following?
VARX=".. " # by accident as the result of a command
mkdir $VARXSure, but a non-ambiguous external representation should be mandatory when a semantic value conflates with a presentation one.
Here ' ' is part of both worlds: . .. ..
A first idea: . .. ..\
ls may also take inspiration from bash completion, where dirsep serves as a better delimiter than ' '
Here ' ' is part of both worlds: . .. ..
A first idea: . .. ..\
ls may also take inspiration from bash completion, where dirsep serves as a better delimiter than ' '
noob ~ $ mkdir -pv lsb/wat
noob ~ $ cd lsb/wat
noob ~/lsb/wat $ mkdir ".. "
noob ~/lsb/wat $ ls -lah
total 12K
drwxr-xr-x 3 noob noob 4,0K august 28 16:52 .
drwxr-xr-x 3 noob noob 4,0K august 28 16:52 ..
drwxr-xr-x 2 noob noob 4,0K august 28 16:52 ..
noob ~/lsb/wat $ cd ..<TAB-COMPLETION>
../ .. /- Where do I put my binaries ?
in /usr/bin of course
- But it's kinda personal stuff...
so put it in /usr/local/bin
- Oh right, but now I have more stuff that's not really important but still useful
that's what we have /opt for
- but... what if it's optional and only on my machine
oh hell, just create /opt/local/bin and be done with it already!
in /usr/bin of course
- But it's kinda personal stuff...
so put it in /usr/local/bin
- Oh right, but now I have more stuff that's not really important but still useful
that's what we have /opt for
- but... what if it's optional and only on my machine
oh hell, just create /opt/local/bin and be done with it already!
You missed `/bin/`, `/sbin/`, `/usr/bin/`, `/usr/sbin/` and the same in `/usr/local`. Luckily there are some efforts to clean this up: https://fedoraproject.org/wiki/Features/UsrMove
As opposed to windows where the user binaries are not located in a central location, I'd take this any day of the week.
You can't blame *nix for having too much choice. Especially when it's coherent.
You can't blame *nix for having too much choice. Especially when it's coherent.
I actually find unix worse here, as I rarely care about where the binary is (and `which` will happily tell me on the rare occasions that I do), but I often need to find various supporting files. Are they in /usr/share? /usr/local/share? /opt/fooprog? (in the olden days /usr/X11R6/share, or many other variants).
There are efforts to fix this. In Arch Linux, all binaries are now in /usr/bin, and /bin is just a symlink to /usr/bin.
That's not my problem. My problem is: Where is the template file for xyz, or the doc, or the example config, or ...
What are the equivalent locations for windows ? Also almost all programs installed via the package manager will use the same paths. If you are installing a package manually, then things get more.. interesting.
Practically universally: C:/Program Files/FooProg
In fairness, program files, templates, docs, settings, and examples on Windows are often in some mix of
C:/Program Files (x86)/VendorName/FooProg
C:/Users/Me/AppData/Local/FooProg
C:/Users/Me/My Documents/FooProg/
C:/VendorName/FooProg (I'm looking at you, AMD)
The registry (which is sorta like /etc, and often abused to store stuff like recent searches, etc)
Is it coherent? I think the whole point of that post was that it's not obvious where things should go and different people have different opinions on that. For a newcomer, learning the Linux filesystem takes years and can never truly be perfected for the above reasons.
It takes a few days. Even less if you read the specifications. Years seems unreasonably high.
It would take days to learn where things are supposed to go, in the opinion of the person writing the documentation. Where things actually go in the real world varies from distro to distro and application to application. And just when you think you have it down, you try to find where that new app just installed to, and you begin the process again.
And when you finally figure it out, Fedora moves everything to /usr.
And when you finally figure it out, Fedora moves everything to /usr.
But even /opt/local/bin (a construct I’ve never seen…) is just one letter longer than ‘Program Files’ – so at least they got the "not too long" bit right.
`Program Files` would actually be `C:\Program Files` (or the equivalent) if you're going for an absolute path. So `/opt/local/bin` comes out to two letters shorter.
Hence ‘even’, saying that even the full path is only one letter longer than the single directory name. :)
Though, really, I have never seen /opt/local/bin – /usr/bin for package-manager owned stuff, /usr/local/bin for stuff not owned by the package manager and /opt/<Vendor> for weird things…
Though, really, I have never seen /opt/local/bin – /usr/bin for package-manager owned stuff, /usr/local/bin for stuff not owned by the package manager and /opt/<Vendor> for weird things…
/opt/local/bin contains no spaces and thus doesn't require quoting or escaping and is thus more than two shorter in actual use.
ahhhhh, so /usr/bin isn't the recycle bin...
I was buying it up until "WOW, nature is beautiful".
Amusing, but after looking up on the actual reasons why they came up with this scheme, I'm very impressed by the amount of work that goes into backwards compatibility:
> Batch files ran programs from C:\Windows\System32 with the expectation that the resulting program would match the native OS. These expectations were not explicit, but they were implied by the nature of the activity. If the System32 directory were filled with 32-bit programs, then a batch file that ran the C:\Windows\System32\REG.EXE program to upset a system registry setting would be running the 32-bit version of REG.EXE, which means that it would be updating the 32-bit simulated version of the registry instead of the real 64-bit version. Other types of scripting files (such as REG files) have the same problem.
http://technet.microsoft.com/en-us/magazine/ff955767.aspx
How did Linux handle this problem?
> Batch files ran programs from C:\Windows\System32 with the expectation that the resulting program would match the native OS. These expectations were not explicit, but they were implied by the nature of the activity. If the System32 directory were filled with 32-bit programs, then a batch file that ran the C:\Windows\System32\REG.EXE program to upset a system registry setting would be running the 32-bit version of REG.EXE, which means that it would be updating the 32-bit simulated version of the registry instead of the real 64-bit version. Other types of scripting files (such as REG files) have the same problem.
http://technet.microsoft.com/en-us/magazine/ff955767.aspx
How did Linux handle this problem?
the problem is not in the 32/64 reg.exe executable. It's that "32-bit simulated version of the registry".
Why do I need something like that? (I expect some binary compatibility, but we're just opening a can of worms...)
By comparison, most of the configuration files / registry equivalent info in linux are saved in plain text, and AFAIK all of them did not care about the 32/64 bit version of the executables.
Why do I need something like that? (I expect some binary compatibility, but we're just opening a can of worms...)
By comparison, most of the configuration files / registry equivalent info in linux are saved in plain text, and AFAIK all of them did not care about the 32/64 bit version of the executables.
AFAIK it just don't have the problem. 32bits binaries executed on a 64bits system are not isolated in any way.
All of the names it makes fun of have perfectly sensible explanations.
"Program Files" and "Documents and Settings" have spaces to force software to support spaces in paths.
system32 for the Win32 version of system makes perfect sense. 64-bit Windows continues to use the Win32 API, and renaming system32 would have broken compatibility with dumb programs that hardcoded the name. SysWOW64 is the system32 directory for Windows 32-bit on Windows 64-bit. WOW64 is perhaps an overly cutesy name, but it's actually fairly descriptive.
"Program Files" and "Documents and Settings" have spaces to force software to support spaces in paths.
system32 for the Win32 version of system makes perfect sense. 64-bit Windows continues to use the Win32 API, and renaming system32 would have broken compatibility with dumb programs that hardcoded the name. SysWOW64 is the system32 directory for Windows 32-bit on Windows 64-bit. WOW64 is perhaps an overly cutesy name, but it's actually fairly descriptive.
> to force software to support spaces in paths
And yet the platform where it's hardest to support spaces in paths is... windows!
On UNIX the process-creation API (execve) explicitly takes an array of arguments. There really aren't any special characters as far as the API is concerned (except \0): what you pass to execve will be the same as what the new process sees in main()
In windows, CreateProcessW() just is given a command line with space-separated argument names. Then the CRT in the new process will split that back up before main() is called. To be sure to get the arguments you want in main() you need to carefully quote the parameter you pass to CreateProcess using the exact rules that the CRT will use to unquote them -- in my experience this wasn't well documented, either.
Worse, since that splitting is the responsibility of the new process, programs can skip the CRT and do it themselves. If they don't follow exactly the same rules the CRT does things break if you try to send an argument with an escaped metacharacter.
And yet the platform where it's hardest to support spaces in paths is... windows!
On UNIX the process-creation API (execve) explicitly takes an array of arguments. There really aren't any special characters as far as the API is concerned (except \0): what you pass to execve will be the same as what the new process sees in main()
In windows, CreateProcessW() just is given a command line with space-separated argument names. Then the CRT in the new process will split that back up before main() is called. To be sure to get the arguments you want in main() you need to carefully quote the parameter you pass to CreateProcess using the exact rules that the CRT will use to unquote them -- in my experience this wasn't well documented, either.
Worse, since that splitting is the responsibility of the new process, programs can skip the CRT and do it themselves. If they don't follow exactly the same rules the CRT does things break if you try to send an argument with an escaped metacharacter.
They should have called it "Prögräm Files", to force developers to support unicode.
pff, more like "͉̮̽̌̾ͨ̅ͪ̔͟P̫̣̟̩͓ͬ̀̇ͦ̍̾r̢̟͚̭͍̰̈́͂̀͌͌ͅö̬̩̩̼͔͡g̻͈̜̘̥̣̯ͣ̆̊́͑̈̑r̜̅ͪ͂ͩ̈̽̆̕ä͙̯̹̼̭̽ͮ̄ͨ̋͞m̸̥̝͓̥͉̣̎̊ͬͩ̄̌ͨͅ ̷̣ͬ̎̔F̰͍̠̾̅i̪͖̞͓̝̬ͥͅle̞̘͇̲̳͍̐̎̾̾̉͑̚s̲͍̓̂͞.
HN should too, :p. Put it in http://eeemo.net/ to see what I mean.
HN should too, :p. Put it in http://eeemo.net/ to see what I mean.
Sadly Windows 95 did not support Unicode until unicows came out many years later. It sure would have been nice if it had as then perhaps the Win32 API could have been Unicode-only.
Or 𐍀𐍂𐍉𐌲𐍂𐌰𐌼 𐍆𐌹𐌻𐌴𐍃 if you want to go full gothic.
WoW isn't meant to be cutesy (which I think you hinted at, but to be explicit for others), it stands for Windows on Windows, which is the compatibility layer between different architectures (first 16 on 32, and now 32 on 64).
http://en.wikipedia.org/wiki/Windows_on_Windows
http://en.wikipedia.org/wiki/Windows_on_Windows
The problem with WoW isn't the name, it's the concept itself. Some folders are shared between the two subsystems, some folders aren't. Some registry keys are shared, some aren't. If you thought the COM registration hell was fun, wait till you have a component that's misregistered twice, subtly different in each subsystem.
[deleted]
Ah acryonyms, the death of us all.
> All of the names it makes fun of have perfectly sensible explanations.
Yes - OP just posted them. :) (for the record: your explanations, while they may be true, are not much better than the OP's)
Yes - OP just posted them. :) (for the record: your explanations, while they may be true, are not much better than the OP's)
Most of the time someone does something really stupid they think they had good reasons for it. It's only the truly dense that continue to believe they have good reasons after the fact.
If the directory content isn't clear from its name, it doesn't really matter whether there is sensible (and obscure) explanation. In fact, "the developer was on meth" is also a sensible explanation.
Anyway, Unix naming scheme is also pretty unintuitive so I guess it's a hard problem.
Anyway, Unix naming scheme is also pretty unintuitive so I guess it's a hard problem.
> renaming system32 would have broken compatibility with dumb
"compatible with dumb" makes short-term business sense, but I'm not sure I'd call it /perfectly/ sensible...
"compatible with dumb" makes short-term business sense, but I'm not sure I'd call it /perfectly/ sensible...
Note that it works hand in hand with `Excel can't save to paths over 218 characters (microsoft.com)` (https://news.ycombinator.com/item?id=6281462)
bad name => earlier limit reach
</synergy>
bad name => earlier limit reach
</synergy>
That's not the best part yet. Remember links? Apparently they survived the big Longhorn and made their way into Vista! They really only exist as the "mklink" command line tool, support for creating them is nonexistent in Explorer, and iirc they have some other underlying architectural failures that makes them generally unpleasant to use on Windows.
But hey, they exist, so someone had the glorious idea to translate these already terrible names into whatever is appropiate for your localized Windows, and create links for stuff like Documents and Settings. Confusion complete.
But hey, they exist, so someone had the glorious idea to translate these already terrible names into whatever is appropiate for your localized Windows, and create links for stuff like Documents and Settings. Confusion complete.
Of course we remember! Here's how it happened:
https://gist.github.com/dchest/800407/raw/48fd662716b7d446e7...
https://gist.github.com/dchest/800407/raw/48fd662716b7d446e7...
I always thought it was funny that the hosts file is still in etc/ but under the windows system folder!
My recent favorite is WinSxS - it's the folder that makes total sense on WinRT/Pro devices... not!
Okay, it's sounds like a fine idea - having multiple DLL versions, allowing applications to link to them. But look, the idea of DLL was to save memory, where two or more applications accessing them would reuse the same hw memory (if they are not relocated). Now maybe on modern PC's that doesn't matter much (although it's still problematic if two MSVCRT libs are used from two different DLLs).
Anyway, but on mobile devices - memory and storage space are important - so make sure all your apps use the same DLL, so you don't lose to storage space, and it's loaded only once (virtually for every process, but due to COW only once in memory).
Have fun, go to Best Buy/Costco/anywhere where they sell the Windows RT/Pro tablets. Go to the command prompt (cmd.exe), c:\windows\winsxs, and type "dir /s" - you can see how much space is wasted there. And this would get even more and more with more updates coming.
Okay, it's sounds like a fine idea - having multiple DLL versions, allowing applications to link to them. But look, the idea of DLL was to save memory, where two or more applications accessing them would reuse the same hw memory (if they are not relocated). Now maybe on modern PC's that doesn't matter much (although it's still problematic if two MSVCRT libs are used from two different DLLs).
Anyway, but on mobile devices - memory and storage space are important - so make sure all your apps use the same DLL, so you don't lose to storage space, and it's loaded only once (virtually for every process, but due to COW only once in memory).
Have fun, go to Best Buy/Costco/anywhere where they sell the Windows RT/Pro tablets. Go to the command prompt (cmd.exe), c:\windows\winsxs, and type "dir /s" - you can see how much space is wasted there. And this would get even more and more with more updates coming.
To be fair, dir /s vastly overerstimates the storage use of WinSxS. That directory contains multiple hardlinks to every physical file, and dir /s doesn't handle those properly.
The way Microsoft Windows parses "Program Files" in the path seems incredible at first:
https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vuln...
http://xato.net/hardening/the-programexe-problem/
https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vuln...
http://xato.net/hardening/the-programexe-problem/
"The problem is that it doesn't know. It just starts
at the beginning and tries finding an executable until
it finds a match. So in this case, it will try these
files every time you run the command:
C:\Program.exe
C:\Program Files\Internet.exe
C:\Program Files\Internet Explorer\iexplore.exe
"You might see where I'm going with this: if you
place an executable named program.exe in the root
directory, it will probably end up running quite
a bit. In fact, it will run anytime Windows
launches a Program Files executable that does not
have quotes around the path." [1]
You basically get ranked on how visible your stuff is to management, so you:
1) name your project as patriotically as possible. It's gotta include one of "Windows", "Microsoft", "XML", "COM", ".NET", "Modern" -- preferably all of them multiple times, especially if it has nothing to do with any of them.
2) make sure to stick the name in as many places as possible. A great place is the default filesystem structure, where everyone is bound to come across it.
3) earn bonus points if you can massage it into a de-facto standard (hello, XHR)
With any luck, Microsoft Modern framework for Windows Azure .NET connectivity with Windows Azure 8.1 will show up on your reviewer's radar and you can enjoy your juicy bonus until the same time next year.
Source: used to work there
P.S. I'm not a Microsoft cynic -- just having a bit of fun :).