Humor: Interview with an Ex-Microsoftie Who Used to Name OS Folders

http://secretgeek.net/ex_ms.asp

by taude • 13 years ago

183 125 13 years ago

secretgeek.net

niuzeta• 13 years ago

Is this a joke, or a real deal? It seems too true to not to be a genuine joke.

talles• 13 years ago

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!"

bhauer6• 13 years ago

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.

voidiac• 13 years ago

At least there are no spaces in the directory names.

harrytuttle9• 13 years ago

Yes and UNIX is really better!

   $ mkdir ".. "
   $ ls -a
   .  ..  ..

Fun eh?

taude• 13 years ago

I found not just the naming aspect funny, but the whole munging of 32/64 bit files good, too. That's beyond naming atrocities.

bhauer6• 13 years ago

Agreed.

To me, it's even more funny when you realize "WOW" actually means "Windows on Windows." Say what??

pmelendez• 13 years ago

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

harrytuttle9• 13 years ago

Indeed. I think people worked out that metadata indexing over the top is probably better.

fiatpandas2• 13 years ago

Check out GoboLinux's file system structure:

http://www.gobolinux.org/index.php?page=at_a_glance

bhauer6• 13 years ago

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.

Pxtl2• 13 years ago

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.

jorgem• 13 years ago

Even that has some warts: For example, Why not "MountS", since other folders are plural: FileS, ProgramS, UserS

mintplant2• 13 years ago

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.

Bjoern• 13 years ago

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

antocv3• 13 years ago

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?

amenod2• 13 years ago

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.

jvehent• 13 years ago

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

jjindev• 13 years ago

wasn't /usr the original /home? as I understand it, it grew and became a system directory. with /bin as the original bin.

yebyen• 13 years ago

On FreeBSD, /home is actually a symlink to /usr/home

claudius2• 13 years ago

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.

mintplant2• 13 years ago

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

ch0wn• 13 years ago

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

masklinn• 13 years ago

And ~/bin as well.

pavanky4• 13 years ago

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.

TylerE3• 13 years ago

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

freehunter2• 13 years ago

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.

junto• 13 years ago

ahhhhh, so /usr/bin isn't the recycle bin...

maga• 13 years ago

I was buying it up until "WOW, nature is beautiful".

felixr• 13 years ago

I wonder why the interviewee is an Ex-Microsoftie. Did Microsoft realize that they had to replace him, or did he retire? Probably the latter...

magic_haze• 13 years ago

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?

byroot• 13 years ago

AFAIK it just don't have the problem. 32bits binaries executed on a 64bits system are not isolated in any way.

_ZeD_2• 13 years ago

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.

plorkyeran4• 13 years ago

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.

amenod2• 13 years 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• 13 years 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

echohack• 13 years ago

Ah acryonyms, the death of us all.

codeflo3• 13 years 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• 13 years ago

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

Cthulhu_• 13 years ago

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.

plorkyeran4• 13 years 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• 13 years ago

Or 𐍀𐍂𐍉𐌲𐍂𐌰𐌼 𐍆𐌹𐌻𐌴𐍃 if you want to go full gothic.

ebbv• 13 years 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• 13 years 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.

bodyfour3• 13 years 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.

jfb2• 13 years ago

The problem with paths with spaces on Unix is not the API, it's the shell.

Shish2k• 13 years 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...

aegiso• 13 years ago

What you see here is the result of Microsoft's ridiculous infighting and internal politics, constructed by the stack-ranking culture of doom.

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

theg2• 13 years ago

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.

icebraining3• 13 years ago

SysWOW64 is from the 90s?

shrikant• 13 years ago

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

amaks• 13 years ago

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.

terrymah• 13 years ago

FWIW, "WOW" stands for "Windows on Windows"

_ZeD_2• 13 years ago

FWIW... it's "WOW64" (windows on windows 64)

agumonkey3• 13 years ago

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>

revelation• 13 years ago

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.

dchest• 13 years ago

Of course we remember! Here's how it happened:

https://gist.github.com/dchest/800407/raw/48fd662716b7d446e7...

disposablename2• 13 years ago

http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext...

th0ma5• 13 years ago

I always thought it was funny that the hosts file is still in etc/ but under the windows system folder!

malkia• 13 years ago

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.

codeflo3• 13 years ago

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.

disposablename2• 13 years ago

http://blogs.technet.com/b/askcore/archive/2008/09/17/what-i...

jloughry• 13 years ago

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/

  "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]

[1] http://www.securityfocus.com/columnists/301

Humor: Interview with an Ex-Microsoftie Who Used to Name OS Folders

Related Stories