原文链接：https://devblogs.microsoft.com/oldnewthing/20051206-10/?p=33083

The project leader for the initial version of Internet Explorer was well-known for wearing Hawaiian shirts. I’m told that the team managers decided to take one of those shirts and use it as an award to the team member who fixed the most bugs or some similar thing. What the team managers failed to take into account that nobody actually liked having a Hawaiian shirt hanging in their office, especially not one that was worn by somebody else. If you happened to be the person who fixed the most bugs, you sort of reluctantly accepted the shirt even though you really didn’t want it.

Internet Explorer 早期版本的项目领导人的夏威夷衫装束在公司内人尽皆知。团队管理者告诉我，他们决定拿其中一件衬衫当奖励，奖给修复了最多bug或者做了类似贡献的团队成员。但是团队管理者没有考虑到的是，并没有人喜欢在办公室里挂一件夏威夷衬衫，尤其是被别人穿过的那种。如果你碰巧修复了最多的bug，就得不怎么情愿地接受一件衬衫，即便是你并不怎么想要它。

And then a wonderful thing happened: The meaning of the shirt flipped.

然后就发生了一件奇妙的事情：衬衫的含义来了个180度的转变。

I don’t know the details. I suspect at one point, somebody who “won” the shirt just left it in somebody else’s office as a way of getting rid of it. This simple gesture was the turning point. The shirt became a symbol of disapproval. I believe the unofficial rule was that in order to get rid of the shirt, you had to find somebody who messed up at least as bad as whatever you did to earn the shirt in the first place.

我不知道事情的详细经过，估计是在某个时候，某个『赢得』了这件衬衫的人干脆把它留在了别人的办公室里，权当一种丢弃的方式。如此简单的一道行为成为了转折点，衬衫变成了不赞成的标志。我觉得这条不成文的规定是，要想把衬衫推给别人，你得找一个像自己一样因为把事情搞糟（至少跟自己的程度差不多）、因而被塞给了这件衬衫的人。

It took a while before the team managers even realized what happened to their “award”.

团队管理者过了好一阵子才发现自己的『奖励』变成了什么样子。

原文链接：https://devblogs.microsoft.com/oldnewthing/20051205-09/?p=33103

In the very early days of Windows 95, the distribution servers were not particularly powerful. The load of having the entire team installing the most recent build when it came out put undue strain on the server. The solution (until better hardware could be obtained) was to have a stack of floppy disks in the office of the “build shepherd”. (The job of “Build Shepherd” was to perform the initial diagnosis of problems with the build itself or with verification testing and make sure the right developer is called in to address the problem.)

在 Windows 95 研发的初期，用来发版的服务器性能并不算强大。当新版本发布后，整个团队都去上拉取最新构建版本进行安装这件事对服务器造成了可观的压力。解决方法（在换用更强力的硬件之前）是在『构建牧羊人』的办公室里放置一摞软盘。（『构建牧羊人』的工作是对构建版本、或者验证测试进行初步的问题筛查，并确保对应的开发者能被及时叫来处理问题。）

If you wanted to install the latest build, you had to go to the Build Shepherd’s office and take one of the specially-marked floppy disks. When you finished installing, you returned the disk.

假如你想安装最新的构建版，你就需要去构建牧羊人的办公室里去取一张做了特殊标记的软盘，等安装完之后，再把软盘送回去。

In other words, the floppy disk acted as a real-world semaphore token.

换句话说，这些软盘变成了现实世界中的信号量标记。

原文链接：https://devblogs.microsoft.com/oldnewthing/20051122-15/?p=33243

A little-known quirk is that the file system accepts and ignores a drive letter in front of a UNC path. For example, if you have a directory called \\server\share\directory, you can say

有个鲜为人知的奇怪设计是，文件系统接受（并会忽略）UNC 路径的开头包含盘符。例如，如果你有个目录（的共享路径）是\\server\share\directory，你可以输入

dir P:\\server\share\directory

and the directory will be listed to the screen. The leading P: is ignored.

目录内容会成功列出，开头的 P: 被忽略了。

Why is that?

这是为什么呢？

Rewind to 1984 and the upcoming release of MS-DOS 3.1, which added networking support. Up to this point, all fully-qualified file specifications consisted of three components: A drive letter, a path, and a file name. Many programs relied on this breakdown and did things like “helpfully” prepend a drive letter if it looks like you “forgot” one. For example, if you told it to save the results to \\server\share\file.txt it would say, “Oh dear, that’s not good, the user forgot the drive letter! I’ll put the current drive in front to make things better,” resulting in C:\\server\share\file.txt. Other programs would prompt you with “Please enter a drive letter”, and you couldn’t say “No, there’s no drive letter, just take the path and use it.” They insisted on a drive letter, and you darn sure better give them one.

回到 1984 年，MS-DOS 3.1 即将发布，该版本新增了网络支持。到这时为止，所有完全限定的文件规范包含三个组成部分：盘符、路径和文件名。很多应用程序都依赖这种组合方式，并且如果路径看上去是用户『忘了』录入盘符的话，还会在最前面『帮忙』加上一个。例如，如果用户指定将数据保存到 \\server\share\file.txt，程序就会认为：『哎呀，这怎么行，用户忘了写盘符了！让我在最前面加上当前驱动器的盘符，这样就好了』，路径就变成了 C:\\server\share\file.txt。另外也有程序会提示用户『请输入盘符』，而用户无法告诉程序『不不，这个路径里没有盘符，直接用这个路径就行了』。程序是一定要一个盘符的，而用户不给是不行的。

(Compare the Unix programs that “helpfully” rewrite //server/volume/file as /server/volume/file because they “know” that consecutive slashes collapse, unaware of the special exception for two leading slashes.)

（相较之下，UNIX 程序则会『帮忙』将 //server/volume/file 重写为 /server/volume/file，因为他们『知道』连续斜线应当进行合并，但却不知道两道斜线开头是个例外。）

In order to retain compatibility with programs that provided this sort of “unwanted help”, the designers of the networking support in MS-DOS decided to allow the strange syntax C:\\server\share\directory and treat it as if the drive letter simply weren’t there. Some (but not all) of this quirk of path parsing persists today.

为了保持与提供这种『毫无必要的帮助』的程序的兼容性，MS-DOS 网路支持功能的设计者们决定允许 C:\\server\share\directory 这种奇怪语法的存在，并将其视为开头的盘符

原文标题：Force-feeding the dogfood

原文链接：https://devblogs.microsoft.com/oldnewthing/20051117-11/?p=33303

Windows 95 contained some new networking features, and since I was one of those crazy people who sampled every flavor of dogfood in the store, I actually tried out all of them. One of the features, a network protocol, I thought was interesting enough that I decided to help them out by forcing everybody else on the team to dogfood it.

Windows 95 包含了一些新的网络功能。鉴于我是会遍尝店里每种口味狗粮的那种人（译注：见上一篇），我是真的都试了一个遍。对于其中一个功能（某个网络协议），我觉得它很有趣，最终使我决定通过让团队里的每个人都尝一尝这份狗粮的味道的方式，来帮助对应团队的人将它做好。

Here’s how I did it.

以下是我的做法。

I had a bunch of debugging documents and other materials that people generally found useful. I put them on my machine, which acted as a file server. Anybody who wanted these files had to install the network protocol in order to get them. And the files were valuable enough that people were willing to take a chance on a new network driver just to get them. Not only did the client side of the driver get a lot of dogfood test coverage, so too did the server side, since my computer would be servicing a lot of simultaneous connections from people reading my documents. I remember finding a variety of interesting bugs this way. (And of course I ran stress over this protocol.)

我手里有一套调试用的文档、以及其它一些资料，对开发人员来说都很有用。我将这些资料放在我的机器上，并让我的机器作为一台文件服务器。任何想要获取这些资料的人，都得安装这个网络协议才能访问它。这些资料的价值，已经高到人们宁可安装一套新的网络驱动也要拿到它的程度了。如此，这个驱动不光在客户端一侧被尝了个遍，在服务端一侧也一样，因为我的机器对前来阅读这些资料的人们同时建立了大量的连接。我记得通过这种方式，得以发现了几个有趣的bug。（当然了，我也有对这个协议进行压力测试。）

I later became friends with the lead tester for the protocol, and he told me that my simple act of force-feeding the dogfood to every other member of the Windows 95 team was a key element of making their feature a success.

后来我跟这个协议的领头开发者成了朋友，他告诉我，我这种让 Windows 95 开发团队的每个人都被强塞一遍狗粮（译注：咳咳）的做法是令他们研发的功能成功的关键元素之一。

原文标题：Sampling every flavor of dogfood in the store

原文链接：https://devblogs.microsoft.com/oldnewthing/20051116-12/?p=33323

During the development of Windows 95, everybody was, of course, self-hosted and upgraded the operating system on a regular basis as new builds came out. I took it upon myself never to install the operating system twice the same way. Each time I ran setup, I would give different answers to the questions. Maybe this time, I’ll leave out Wordpad and bind NetBIOS over TCP/IP to my Xircom parallel-port network adapter. Or maybe I wouldn’t choose any networking drivers at all during setup and try to add them later. Towards the beginning of the project, nearly every run of setup would run into some strange problem, and some developer from whatever component I decided to configure randomly would be in my office at the debugger trying to figure out what happened. (Fortunately, as the project matured, the problems were rarer and rarer.)

在 Windows 95 的研发过程中，伴随着新编译版本的发布，每个人都时常对手里的版本自行托管、自行升级。我的做法则是从来不用同一种方法运行安装程序两次。每次我运行安装程序的时候，我都会对安装程序给出的提问做出不同的回答。可能这次，我会选择不安装写字板，然后把 NetBIOS over TCP/IP 协议配置在 Xircom 并口网卡上，下次则可能在安装时什么网络驱动程序也不装，等装完系统后再进行配置。在整个开发流程最开始的时候，几乎每次运行安装程序都会遇到一些奇怪的问题，然后负责我随机挑选进行配置的某个组件对应的开发者就会来到我的办公室，打开调试器，试着搞清楚到底发生了什么事。（幸而随着整个工程逐渐成熟之后，类似的问题也变得越来越罕见了。）

I was, you might say, sampling every flavor of dogfood in the store.

也可以说，我这是在遍尝商店里每种口味的狗粮。（译注：Eat your own dogfood 字面意思是『吃自家的狗粮』，在软件开发中，则指『自己开发的产品，自己得先用』，即进行内部测试。）

I would also do crazy things for nightly stress runs. My favorite was to run stress over a parallel port direct cable connection. I don’t think it ever occurred to anyone to test DCC quite this way.

有时在进行连夜的压力测试时，我也会搞一些疯狂的事情。我最喜欢的一个案例是在并口的直接电缆连接上运行压力测试，我个人认为不会有人把测试直接电缆连接功能这件事搞得那么绝。