TONT 33423 GlobalWire 的名字是怎么来的?

原文链接:https://devblogs.microsoft.com/oldnewthing/20051108-05/?p=33423

John Elliott wondered why the GlobalWire function was called GlobalWire.

John Elliott 想知道为什么 GlobalWire 函数起了这么个名字。

First, some background for those who never had to write 16-bit Windows programs. The GlobalWire function was similar to the 16-bit GlobalLock function, except that it had the bonus feature of relocating the memory to the lowest available linear address. You used this function as a courtesy if you intended to leave the memory locked for a long time. Moving it to the edge of the address space means that it is unlikely to become an obstacle in the middle of the address space which would otherwise prevent future large memory allocations from succeeding.

首先,给从来都不需要撰写 16 位 Windows 应用程序的人一点背景资料。GlobalWire 函数与 16 位函数 GlobalLock 类似,不过还有将内存块移动到可用的最低线性地址的附加作用。调用这个函数意味着你想让某部分内存锁定较长的一段时间。将内存块移动到地址空间的边缘,使得这块内存不会成为不上不下地横亘在地址空间的一部分,以期未来的大块内存分配不会失败。

But why “wire”?

不过『wire』这个写法又是怎么回事呢?

This employs a colloquial sense of the word “wire” as a verb which has lost its currency in the intervening years. To wire means to fasten securely in a very strong sense. It probably derives from the phrase “hard-wired”, which means “permanently attached in circuitry”. Therefore, “wiring” memory into place ensures that it doesn’t move around.

这里是借用了 wire 这个词作为动词的口语说法,而这种用法这些年大概逐渐式微了。『To wire』意味着将某物『紧紧绑住』的一种强烈语气,可能是来自短语『hard-wired』,含义是『在电路中永久固定』。由此,将内存『捆绑』在某处就是期望其不会到处乱跑。

TONT 33473 要做领导者,必须知道何时应当跟从

原文链接:https://devblogs.microsoft.com/oldnewthing/20051103-43/?p=33473

Many people misinterpreted my use of the term “reluctant” to describe the attitude of the designers in changing the way the Date/Time control panel functions. It was a reluctance of shame, not a reluctance of defiance.

很多人错误地理解了我对修改日期/时间控制面板功能中设计人员的『不情愿』的含义。这里的『不情愿』指的是羞愧心,而不是抗拒心。

Your software is there for the users, not vice versa. If you find that your users are using the software in a manner contrary to its intended purpose, your first reaction may be to try to educate users not to do whatever it is they’re doing. But eventually you reach a point where the efforts in convincing people not to do something dangerous outweighs the cost of just making it less dangerous. (Even though this may annoy those who genuinely want to perform that dangerous activity.)

你的软件是为了用户而生的,但并不是说反之亦然。如果你发现用户在使用你的软件时,总是与你的设计初衷相悖,你的第一反应可能是去指导用户不要这么做。但是,迟早你会发现教给用户不要做什么的成本大大高于让你的设计更加合理。(虽然这会让刻意做这些操作的人感到恼火就是。)

You may not do it with a smile on your face (hence the reluctance), but you know deep in your heart that it’s the right thing to do.

可能做出这些修改的时候,你的脸上不会带着笑容(也就是所谓的『不情愿』),但在内心深处你也明白这才是正道。

Side note: Why did the Date/Time control panel apply changes immediately anyway? Historical artifact. That’s the way the Date/Time control panel has worked since Windows 1.0. In fact, originally, the Date/Time control panel didn’t even have a Cancel button. Any changes you made to the time took effect immediately and irrevocably. (Mind you, MS-DOS and the original Macintosh did the same thing.) It wasn’t until after Windows 95 shipped that this behavior started being a problem.

再说个小故事:为什么日期/时间控制面板会立刻应用修改呢?这是历史上一以贯之的设计,也是日期/时间控制面板从 Windows 1.0 起的设计。实际上,原本日期/时间控制面板连『取消』按钮都没有,任何对时间的修改都立刻生效、无法撤销。(小提示:MS-DOS 和原始的 Macintosh 都是这么设计的。)但是直到 Windows 95 发布后,这样的设计才成为了一个问题。

TONT 33503 为什么行内自动完成功能默认是关闭的?

原文链接:https://devblogs.microsoft.com/oldnewthing/20051102-48/?p=33503

Earlier versions of Internet Explorer used inline autocomplete, but newer versions use drop-down autocomplete that requires you to press the down-arrow key to select an item from the drop-down. Why the change?

早期版本的 Internet Explorer 启用了行内自动完成,但新版本改成了下拉列表式的自动完成,需要用户按下箭头键来在列表中选择一项。为什么会有这种变动呢?

Because it interferes with normal keyboard operation.

因为先前的设计影响了正常的键盘操作。

Suppose http://www.microsoft.com/windows/ is in your history, but you want to go to http://www.microsoft.com/. As you type the desired destination, inline autocomplete kicks in and fills in the remainder of the URL for you, http://www.microsoft.com/windows/. If you aren’t watching the screen and just hit Enter, you end up going to the autocompleted URL instead of the URL you typed. Oops.

假设 http://www.microsoft.com/windows/ 在你的浏览记录中,但你想浏览的是 http://www.microsoft.com/。当你在地址栏中输入要访问的网址时,行内自动完成发挥了作用,帮你补全了余下的部分,(使网址变成了)http://www.microsoft.com/windows/。如果你(低头敲键盘)没看屏幕就直接按下了回车键,结果就是访问了自动完成给出的 URL 而不是你录入的网址。哎呀。

To me, this is a fatal flaw, namely that one has to be watching the screen to perform an operation that one would think consisted purely of typing. In particular, this creates problems for people with limited visual capability who necessarily “type blind” most of the time.

对我来说,这是个难以接受的缺陷,使得一项让只管录入就能完成的工作,变成了需要盯着屏幕才能完成的情况。尤其是针对事实上总是在『盲打』的视弱用户而言,便是一个大问题。

Even using Tab as the autocomplete character suffers from the same flaw. Consider the Run dialog or IE’s address bar. In those places, the Tab key moves you around the window. (To the OK, Cancel, and Browse buttons on the Run dialog, or into the web page itself for IE.) If the Tab key were the autocomplete completion key, it wouldn’t be possible to Tab around the dialog/window any more. For example, suppose you want to browse around your C drive, so you type C:\ into the Run dialog and hit Tab three times to get to the Browse button. But, oops, the Tab key autocompletes, so instead of browsing C:\, you’re browsing whatever directory in your C: drive the autocomplete engine decided to show you.

就算将自动完成功能改成用 Tab 键,也会产生同样的问题。考虑在『运行』对话框或 IE 的地址栏里,在这些地方,Tab 键会将你的焦点移动到其它控件上。(例如在『运行』对话框中移动到『确定』、『取消』或『浏览』按钮上,或者在 IE 中移动到网页上去。)如果让 Tab 键作为自动完成的案件,那么就无法再用其在对话框或窗口中的控件之间进行切换了。举个例子,假设你想浏览C盘的内容,于是你就在『运行』对话框中输入了 C:\,然后按了 3 下 Tab 键想移动到『浏览』按钮上,然而这时 Tab 键是自动完成键了,于是你输入的路径就变成了自动完成引擎帮你决定的、你的 C 盘中随便哪个目录的内容,而不是浏览 C:\ 的内容了。

TONT 33593 为什么 OEM 代码页经常被称作 ANSI?

原文链接:https://devblogs.microsoft.com/oldnewthing/20051027-37/?p=33593

It has been pointed out that the documentation for the cmd.exe program says

Cmd.exe 的文档中曾指出,

/A Causes the output of internal commands to a pipe or file to be ANSI

/A 选项使内部命令输出至管道或文件时使用 ANSI

even though the output is actually in the OEM code page. Why do errors such as this persist?

——不过实际上是用 OEM 代码页输出的,为什么这种错误会不断出现呢?

Because ANSI sometimes means OEM.

因为 ANSI 有时候指的就是 OEM。

The “A” versions of the console functions accept characters in the OEM code page despite the “A” suffix that would suggest ANSI. What’s more, if you call the SetFileAPIsToOEM function, then “A” functions that accept file names will also interpret the filenames in the OEM code page rather than the ANSI code page.

『A』版本的控制台函数接受在 OEM 代码页中的字符,即便『A』这个前缀指的是 ANSI 也一样。此外,如果你调用 SetFileAPIsToOEM 这个函数,那么接受传入文件名的『A』系的函数同样会使用 OEM 代码页、而不是 ANSI 代码页来解析文件名。

“There are two types of people in the world: Those who believe that the world can be divided into two types of people, and those who do not.”

『这世上有两种人:相信人们可以被分成两种人的,和不相信的。』

There are those who mentally divide the world of characters into two groups: Unicode and 8-bit. And as you can see, many of them were involved in the original design of Win32. There are “W” functions (Unicode) and “A” functions (ANSI). There are no “O” functions (OEM). Instead, the OEM folks got lumped in with the ANSI folks.

这世上也有在精神上将字符世界一分为二的人:不是 Unicode 就是 8 位字符集。并且与此同时,这类人中的许多也与 Win32 的原始设计相关联。有『W』系函数(Unicode)(译注:W 指 Wide),也有『A』系函数(ANSI),就是没有『O』系函数(OEM),OEM 字符集的认同者们被与 ANSI 字符集的拥趸们撮成了一堆。

There are also those who realize the distinction, but out of laziness or convenience often use “ANSI” as an abbreviation for “an appropriate 8-bit character set, determined from context”. In the context of console programming, the appropriate 8-bit character set is the OEM character set.

这世上也有人能分清(这三种字符集)的区别,但出于懒惰或便利,经常使用『ANSI』来指代『某种8位字符集(依据上下文来确定)』。在控制台应用程序的上下文中,对应的8位字符集指的就是 OEM 字符集。

The person who wrote the online help for cmd.exe clearly meant ANSI to mean “That thing that isn’t Unicode.”

给 cmd.exe 撰写线上帮助信息的人,实际上想让 ANSI 指代的是『不是 Unicode 的那种字符集』。

/A Causes the output of internal commands to a pipe or file to be ANSI

/A 选项使内部命令输出至管道或文件时使用 ANSI

/U Causes the output of internal commands to a pipe or file to be Unicode

/U 选项使内部命令输出至管道或文件时使用 Unicode

I’ll leave you to decide whether this author belongs to the “Everything is either Unicode or ANSI” camp or the “just being casual” camp.

至于写这个帮助信息的人是属于『这世上的字符不是 Unicode 就是 ANSI』还是『俺就素懒』阵营的,就留待您自行评说了。

TONT 33613 当应用程序认为系统永远都不会变的时候:第1章

原文链接:https://devblogs.microsoft.com/oldnewthing/20051026-44/?p=33613

An example, all too frequent, of ways programs assume that the user interface will never change is reaching into system binaries and sucking out undocumented resources. In the shell, we have fallen into the reluctant position of carrying “dead” icons around for the benefit of programs that assumed that they would always be available. However, we often make these “orphaned” icons blank so that these programs don’t crash, but they don’t necessarily look all that wonderful either.

有些程序认为用户界面永远不会改变的、非常常见的一种表现,便是深入到系统文件中随便扒拉没有在文档中描述的资源。在 Shell 设计中,我们陷入了一种不情愿的境地,即保留某些已经『死掉』的图标,来让这类认为某些资源会一直存在的程序高兴。不过,我们通常都会将这些『遗孤』图标变成空白,使得这些程序虽然不会崩溃,但也不会让它们看上去再那么完美。

Recently, I learned of a new type of resource stealing: Stealing animations. For Windows Vista, there have been many changes to the way the system internally organizes its resources in order to support the Multilingual User Interface feature. One of the things we found was a handful of programs that reach directly into Shell32.dll in order to obtain the file copy animation. Too bad (1) the animation isn’t kept there any more, and even if we moved the animation back to its original location, (2) the animation uses a new compression scheme that older programs can’t handle.

最近,我又了解了一种窃取资源的新方法:盗用动画。在 Windows Vista 中,为了支持多语言用户界面(MUI)功能,在系统内部对资源的排序整理方式发生了很大的变化。(在此过程中,)我们发现了一件事,有不少应用程序直接跑进 SHELL32.DLL 中直接将复制文件的动画拿来用。可惜的是,(1)这个动画已经不在原先的位置了,并且就算我们将这个动画放回原来的位置,(2)这个动画所使用的新的压缩方式,这些老版本的程序也不支持。

Remember, resources in system DLLs should be treated as implementation details, unless explicitly documented otherwise.

请记住,除非在文档中明示,否则系统 DLL 中的资源应当被视为实施细节。

I’m not sure what we’re going to do about the animation resource problem. Suggestions anyone? Should we declare these programs broken and make the people who bought them go back to their vendors for upgrades? (What if there is no vendor?) Should we develop a shim and hope that those four are the only programs that need it? Should we carry the original animation in shell32.dll as junk? If I told you that one of the programs that did this won “Game of the Year” recently, would that change your answer? What if another turned out to be a top-rated anti-spyware program?

我不是很确定应该怎么解决这个盗用系统动画的问题,有人能给个建议吗?是不是应该让这些程序无法运行,让购买了这些软件的人们回去找发行商进行升级呢(要是没有发行商该怎么办)?还是应该针对这些程序打个补丁,然后寄希望于只有这些程序需要这个补丁吗?或者让旧版本的动画继续存在于 SHELL32.DLL 中作为残留呢?如果我告诉你有这个问题的软件最近还拿了『年度最佳游戏』的奖项,你会选择修改你的回答吗?要是我告诉你还有一款存在这个问题的软件,是某个名列前茅的反间谍软件呢?

TONT 33663 发现新设备:波音747

Once again, airplane manufacturers have been giving serious consideration to offering Internet access in the skies. Back in 1994, Boeing considered equipping each seat with a serial modem. Laptop users could hook up to the modem and dial out. (Dial-up was the primary means of connecting to the Internet back in those days.)

再一次,飞机制造商们认真考虑了在空中提供 Internet 连接的可能性。1994 年的时候,波音公司曾考虑给每个座位提供一台串口调制解调器,乘客可以把自己的笔记本连上去拨号(访问互联网)。(那时候拨号是主要的访问 Internet 的方式。)

We chuckled at the though of attaching the serial cable and getting a Plug-and-Play pop-up message:

听说这件事的时候,我们都笑了起来,设想着把调制解调器连上电脑时,右下角弹出的即插即用弹出消息:

New device detected: Boeing 747(发现新设备:波音747)

TONT 33673 为什么禁用桌面这件事是被允许的?

原文链接:https://devblogs.microsoft.com/oldnewthing/20051021-11/?p=33673

Some time ago, I mentioned the dangers of disabling the desktop window. But why is it even possible to disable the desktop anyway?

之前我曾讨论过禁用桌面窗体的危险性(译注:原文链接已失效)。不过,为什么禁用桌面这件事本身是允许的呢?

This is simply an artifact of the history of philosophy of Windows operating system design.

这不过是 Windows 操作系统设计哲学中的一个人为设计罢了。

Back in the old days, memory was tight, hard drives were luxuries, the most popular CPU for the IBM PC didn’t have memory protection, and software development was reserved for the rarefied elite who could afford to drop a few thousand dollars on an SDK. This had several consequences:

过去的时候,内存是紧缺物资,硬盘是只有有钱人才用得起的东西,IBM PC 最受欢迎的 CPU 没有内存保护机制,软件开发也只是面向那些能在 SDK 上砸下几千美元的高等精英人士的事情。以上这些现实情况造成了下述影响:

  • Tight memory means that anything optional had to be left behind.(内存紧缺意味着可做可不做的功能都要舍弃掉)
  • Software developers were trusted not to be stupid.(人们相信软件开发者不会做傻事)
  • Software developers were trusted not to be malicious.(人们相信软件开发者不会做坏事)
  • Software developers were trusted to do the right thing.(人们相信软件开发者会去做正确的事)

Certainly there could have been a check in all the places where windows can be disabled to reject attempts to disable the desktop window, but that would have made one window “more special” than others, undermining the “simplicity” of the window manager. Anything optional had to be left behind.

当然了,在所有禁用窗体的流程中做检查,然后拒绝所有尝试禁用桌面窗体的尝试也不是不可以,不过那样就让(桌面)这一个窗体显得比其它窗体『更加特别』,由此便削弱了窗体管理器的『简洁性』(就像刚刚所说的那样,)可做可不做的功能都要舍弃掉。

Software developers were trusted not to make the sort of stupid mistakes that led to the desktop being disabled, the heap being corrupted, or any of the other “don’t do that” types of mistakes lurking in the shadows Windows programming. If such a serious mistake were to creep in, certainly their testing department would have caught it before the program was released. Software development was hard because nobody said this was going to be easy.

软件开发者们被给予了信任,不会做出让桌面被禁用、让堆数据损坏、或者任何『不能这样做』这类潜伏在 Windows 编程中的失误行为。如果这类严重的疏忽不小心发生了,开发团队的测试部门理当在程序正式发布前将其检查出来。软件开发是件困难的事,毕竟从没有人说过这件事很容易

Software developers were trusted to treat their customers with respect. Because, after all, software developers who abuse their customers won’t have customers for very long. If a program put itself in the Startup group, then it was doing so not for selfish reasons but rather because the customer actually wanted it.

人们相信软件开发者会尊重他们的客户,毕竟说到底,折腾自己客户的软件开发商是活不长的。如果某个应用将自己放到启动群组里,那么它这么做就应当是由于客户的真实需求,而不是出于自私的目的。

The window manager was left fairly exposed, granting software developers the power to do things like install hooks, subclass windows that were owned by other processes, and manipulate the contents of the Startup group, with the assumption that software developers would use the power for good, not for evil. Don’t bother stopping a program from disabling the desktop window, because maybe that program is doing it for a good reason that we hadn’t thought of.

窗体管理器是开放的,给予了软件开发者们进行例如安装钩子、在其它进程的窗体中创建子类、修改启动群组的内容之类事情的权力,这也是出于对软件开发者的信任,相信他们会合理运用这些权力,而不是去做坏事。不要去管某个程序禁用了桌面窗体,毕竟可能开发者这么做,会有我们没想到的合理理由。

The world of software has changed much since those simpler days. I had a nice chat with my colleague Zeke where we discussed how philosophy has changed over the years. Maybe he’ll write a few words on the subject…

不过,软件开发早已不是早年那样简简单单的世界了。我和我的同事 Zeke 对这些年软件开发的哲学发生了哪些变化进行了一次愉快的交流,可能他会针对这个话题写几篇博文来谈谈吧。

TONT 33733 给产品团队起名时要当心

原文链接:https://devblogs.microsoft.com/oldnewthing/20051018-09/?p=33733

They thought they were so clever when they named the Desktop Applications Division. “And the abbreviation is ‘DAD’, isn’t that cute? Complements the Microsoft Office Manager toolbar (MOM).”

某个团队给自己起名叫『桌面应用小组』(Desktop Applications Division),感觉自己实在是太聪明了,顺便还说:『缩写是DAD(英文里的“父亲”),可爱吧?正好跟“Microsoft Office Manager” 工具栏(缩写MOM,英文里的“母亲”)凑一对。』

And then the troubles started.

然后他们的麻烦就来了。

Shortly after the new product group was formed, everybody in the product group started getting email talking about strange non-business things. How’s the garden doing? Did you get my letter? When will the twins be coming home from college?

产品团队成立还没多久,团队里的成员就开始收到讨论奇怪的、与业务无关的内容的邮件:花园整理得怎么样了?收到我的信了吗?双胞胎什么时候从学校回来?

The reason is that the email address for sending mail to the entire division was—naturally—”DAD”. But it so happens that many people have a nickname for their father in their address book, named—of course—”dad”. People thought they were sending email to their dad, when in fact it was going to DAD.

原因是给整个团队发邮件的地址——很“自然”地——是『DAD』,然而很多人给自己的父亲在地址簿里存的名字也正好是『DAD』。人们以为邮件是发给了自己的父亲,结果却发给了DAD这个团队。

The email address for sending mail to the entire division was quickly changed to something like “deskapps” or “dappdiv”.

后来给整个团队发邮件的地址很快改成了类似『deskapps』或者『dappdiv』这样的写法。

TONT 33753 有关日文版和韩文版 Windows 里路径分隔符的故事

原文链接:https://devblogs.microsoft.com/oldnewthing/20051014-20/?p=33753

Why is the path separator on Japanese Windows the ¥ character? And why is it the ₩ character on Korean Windows? I’ve been prodding Michael Kaplan to delve into the history of this quirk, and he finally gave in to my repeated badgering. (Additional discussion on the Korean Won sign, the Japanese Yen sign, and currency symbols in general.)

为什么日文版 Windows 中的路径分隔符是 ¥ 呢?而为什么韩文版 Windows 中的路径分隔符又是 ₩ 呢?我已经催促 Michael Kaplan 解释一下这个历史小奇观很久了,在我的不断烦扰下他终于把这则故事写了出来。(这里还有一些关于韩元符号、日元符号,以及货币符号的概括性的讨论。)

(译注:以上文内链接已全部失效,以下是文中的重点内容『he finally gave me to my repeated badgering』在 Web Archive 上的存档译文)

原文链接:http://blogs.msdn.com/b/michkap/archive/2005/09/17/469941.aspx

When is a backslash not a backslash?

在什么情况下,反斜线不是反斜线?

The character in question is U+005c, the REVERSE SOLIDUS, also known as the backslash or ‘\’. It is the path separator for Windows, which is encoded at 0x5c across all of the ANSI code pages.

问题中的字符是 U+005C,REVERSE SOLIDUS(反转的斜线),也以『反斜线』或『\』的形式为人所知,它是 Windows 的路径分隔符,在所有 ANSI 代码页中都被编码为 0x5C。

Since path separators are a pretty important requirement, the title of this post may seem a little scary — how could it not be a backslash, a reverse solidus?

鉴于路径分隔符是一项重点需求,这篇博文的标题似乎显得有些吓人——反斜线怎么会不是反斜线(反转的斜线)呢?

Well, on Japanese code page 932, 0x5c is the YEN SIGN, and on Korean code page 949, 0x5c is the WON SIGN.

那是因为,在日文代码页932里,0x5C是日元符号(¥),而在韩文代码页949里,0x5C是韩元符号(₩)。

Which is not to say that 0x5c does not act as a path separator — it still does. And which is also not to say that the Unicode code points for the Yen and the Won (U+00a5 and U+20a9) do act as path separators — because they do not.

不过这并不意味着0x5C(在显示为日元/韩元符号时)不能作为路径分隔符使用——它仍然有效。同样,这也不意味着 Unicode 中日元和韩元的代码点(code point)(U+00A5 和 U+20A9)可以作为路径分隔符使用——因为它们并不是路径分隔符。

Of course the natual round trip mapping between U+005c and 0x5c happens on all code pages, and both U+00a5 and U+20a9 have one-way ‘best fit’ mappings to 0x5c on their respective code pages. This requirement technically went away with Unicode, when the characters were encoded separately.

当然了,像这种在 U+005C和0x5C之间的循环映射在所有的代码页上都会发生,而 U+00A5(日元符号)和U+20A9(韩元符号)则在其对应的代码页上都有到0x5C的『最佳』映射。像这样的需求在技术上都随着 Unicode 的部署使用、使得每个字符都相互独立进行编码后一去不复返了。

However, the issue is not a simple one of there not being space in the old code page and lots of space in Unicode, where customers will instantly move away from the not backslash path separators.

不过,这件事并不是像旧的字符集里没地方、Unicode 字符集里地方多那样简单的事,如果是这样的话,客户们早就立刻从不是以反斜线作为路径分隔符的环境里离开了。

In practice, after many years of code page based systems in Japan and Korea using their respective currency symbols as the path separators, it is believed customers were simply used to this appearance. And there was therefore little interest in changing that appearance (when the system settings were Japanese or Korean) to anything but those symbols.

实际上,在日本和韩国用过多年基于代码页、以其相应的货币符号作为路径分隔符的系统之后,据信客户们早已经习惯于此了,因而也就对将路径分隔符的外观(当其系统设置为日语或韩语时)修改为除此之外的符号这件事不再有什么兴趣。

To support this expectation, Japanese and Korean fonts, whenever the default system locale is set to Japanese or Korean, respectively, will display the currency symbol rather than the backslash when U+005c is shown.

为了响应这种习惯,日语和韩语的字体在系统的默认语言设置为日语或韩语时,也会相应地在显示 U+005C 字符时显示其货币符号,而不是反斜线。

But whether or not this is really what customers want is still an open question. Andrew Tuck of PSS here at Microsoft noted:

不过这是否是客户的真实诉求,仍然有待讨论。微软 PSS 的 Andrew Tuck 提到:

When one of my customer’s from Korea was visiting here, I asked him if it bothered him that the backslash doesn’t appear as a backslash. It did bother him, and he believes it bothers most of his countrymen. However, he was fatalistic about it, “What can we do to change it. It’s been this way for a long time. We are used to it.”

有位韩国客户来访问的时候,我问他是不是对(路径里)反斜线不显示成反斜线这件事感觉烦恼。客户回答说是,并且表示大概他们国家的人都这么认为。不过,他对此已经听天由命了,他说;『反正也做不了来改变这件事了,都这样这么久了,早就习惯了。』

Hardly a glowing recommendation, is it?

这可不算是什么热情的提议,对吧?

And as Norman Diamond noted in his comments on this very blog (in this post), there are plenty of people in Japan who may not care for the convention, either.

同样,就像 Norman Diamond 在这篇文章(译注:请自行前往阅读)下的评论中提及的那样,在日本也有很多人并不在乎这种惯例。

Of course there is no ‘right’ answer here, and I would imagine that you would find plenty of people who would be unhappy with such a change, just as there are those who would be unhappy with the status quo. Which perhaps explains why the status quo seems to be as it is — those people who would like a change are resigned to the idea that it may never happen. And so they are now used to it….

当然了,关于这个问题,其实并没有什么『正确』答案,我也可以想象得到你能找出一大堆对这种修改不满的人,大约会跟对现状不满的人一样多。这大概也解释了为什么至今为止情况一直都能维持现状——抱怨要做出改变的人,大概已经勉为其难地接受了这件事大概永远不会发生这个事实,干脆就接受了。

TONT 33983 可我的 Visual Basic 是专业版!

原文链接:https://devblogs.microsoft.com/oldnewthing/20050930-10/?p=33983

Back in 1995, I was participating in a chat room on MSN on the subject of device driver development. One of the people in the chat room asked, “Can I write a device driver in Visual Basic?”

1995 年的某一天,我正在 MSN 的聊天室中参与关于设备驱动程序的开发。聊天室里有个人问道,『我能不能用 Visual Basic 来写设备驱动?』

I replied, “Windows 95 device drivers are typically written in low-level languages such as C or even assembly language.”

我回复他,『Windows 95 设备驱动通常是用底层语言来编写的,例如 C 语言,甚至是汇编。』

Undaunted, the person clarified: “But I have Visual Basic Professional.”

此人则毫无畏惧地澄清道:『可是我的 Visual Basic 是专业版。』