4 ms·

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 sp

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.

amenod 13y ago
> 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)
ciniglio 13y ago
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
- echohack 13y ago
  Ah acryonyms, the death of us all.
- deleted 13y ago
  [deleted]
- codeflo 13y ago
  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.
gosub 13y ago
They should have called it "Prögräm Files", to force developers to support unicode.
- Cthulhu_ 13y ago
  pff, more like "͉̮̽̌̾ͨ̅ͪ̔͟P̫̣̟̩͓ͬ̀̇ͦ̍̾r̢̟͚̭͍̰̈́͂̀͌͌ͅö̬̩̩̼͔͡g̻͈̜̘̥̣̯ͣ̆̊́͑̈̑r̜̅ͪ͂ͩ̈̽̆̕ä͙̯̹̼̭̽ͮ̄ͨ̋͞m̸̥̝͓̥͉̣̎̊ͬͩ̄̌ͨͅ ̷̣ͬ̎̔F̰͍̠̾̅i̪͖̞͓̝̬ͥͅle̞̘͇̲̳͍̐̎̾̾̉͑̚s̲͍̓̂͞. HN should too, :p. Put it in http://eeemo.net/ http://eeemo.net/ to see what I mean.
- plorkyeran 13y ago
  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.
- JulianMorrison 13y ago
  Or 𐍀𐍂𐍉𐌲𐍂𐌰𐌼 𐍆𐌹𐌻𐌴𐍃 if you want to go full gothic.
ebbv 13y ago
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.
bnegreve 13y ago
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.
bodyfour 13y ago
> 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.
- jfb 13y ago
  The problem with paths with spaces on Unix is not the API, it's the shell.
  - bodyfour 13y ago
    True, but how is the windows shell better in that regard?
    - jfb 13y ago
      Probably isn't, but then, there isn't the cultural deadweight of gigaloc of shell scripts making up an essential stratum on Windows, right?
Shish2k 13y ago
> 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...

amenod 13y ago

> 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)

ciniglio 13y ago

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

echohack 13y ago
Ah acryonyms, the death of us all.
deleted 13y ago
[deleted]
codeflo 13y ago
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.

gosub 13y ago

They should have called it "Prögräm Files", to force developers to support unicode.

Cthulhu_ 13y ago
pff, more like "͉̮̽̌̾ͨ̅ͪ̔͟P̫̣̟̩͓ͬ̀̇ͦ̍̾r̢̟͚̭͍̰̈́͂̀͌͌ͅö̬̩̩̼͔͡g̻͈̜̘̥̣̯ͣ̆̊́͑̈̑r̜̅ͪ͂ͩ̈̽̆̕ä͙̯̹̼̭̽ͮ̄ͨ̋͞m̸̥̝͓̥͉̣̎̊ͬͩ̄̌ͨͅ ̷̣ͬ̎̔F̰͍̠̾̅i̪͖̞͓̝̬ͥͅle̞̘͇̲̳͍̐̎̾̾̉͑̚s̲͍̓̂͞. HN should too, :p. Put it in http://eeemo.net/ http://eeemo.net/ to see what I mean.
plorkyeran 13y ago
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.
JulianMorrison 13y ago
Or 𐍀𐍂𐍉𐌲𐍂𐌰𐌼 𐍆𐌹𐌻𐌴𐍃 if you want to go full gothic.

ebbv 13y ago

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.

bnegreve 13y ago

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.

bodyfour 13y ago

> 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.

jfb 13y ago
The problem with paths with spaces on Unix is not the API, it's the shell.
- bodyfour 13y ago
  True, but how is the windows shell better in that regard?
  - jfb 13y ago
    Probably isn't, but then, there isn't the cultural deadweight of gigaloc of shell scripts making up an essential stratum on Windows, right?

Shish2k 13y ago

> 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...