TONT 34923 有关『文件系统穿隧』功能的传闻

原文链接:https://devblogs.microsoft.com/oldnewthing/20050715-14/?p=34923

One of the file system features you may find yourself surprised by is tunneling, wherein the creation timestamp and short/long names of a file are taken from a file that existed in the directory previously. In other words, if you delete some file “File with long name.txt” and then create a new file with the same name, that new file will have the same short name and the same creation time as the original file. You can read this KB article for details on what operations are sensitive to tunnelling.

文件系统中有一个功能可能会让你感到惊讶,这个功能叫做『穿隧』,即某文件的创建时间戳和短、长文件名都来自于该目录中之前存在过的文件。换句话说,如果删掉一个类似『File with logn name.txt』(译注:意为『具有长文件名的文件.txt』)这样的文件,然后新建一个具有相同名称的文件,那么新建的文件会与原有的文件具有相同的短文件名(译注:8.3格式的文件名)和相同的创建时间。你可以阅读这篇知识库文章(译注:KB172190,链接已失效)来了解有哪些操作受这种穿隧功能的影响。

Why does tunneling exist at all?

那么,为什么会有这种功能存在呢?

When you use a program to edit an existing file, then save it, you expect the original creation timestamp to be preserved, since you’re editing a file, not creating a new one. But internally, many programs save a file by performing a combination of save, delete, and rename operations (such as the ones listed in the linked article), and without tunneling, the creation time of the file would seem to change even though from the end user’s point of view, no file got created.

当你用某个程序编辑某现存的文件,然后保存,你会下意识认为文件的创建时间保持不变,毕竟你是在编辑旧文件,而不是创建新文件。然而,在很多程序内部,保存文件的过程实际上是保存、删除和重命名操作的组合(译注:建立一个临时文件、将内容保存到临时文件中、删除旧文件、将临时文件的文件名修改为旧文件)(比如上文链接中列出的程序(译注:链接已失效,无法验证列出了哪些程序))。假使没有穿隧功能,文件的创建时间看上去就发生了改变,即使从用户的角度看来并没有创建任何新文件。

As another example of the importance of tunneling, consider that file “File with long name.txt”, whose short name is say “FILEWI~1.TXT”. You load this file into a program that is not long-filename-aware and save it. It deletes the old “FILEWI~1.TXT” and creates a new one with the same name. Without tunnelling, the associated long name of the file would be lost. Instead of a friendly long name, the file name got corrupted into this thing with squiggly marks. Not good.

有关穿隧功能的重要性,再来看另一个例子。假设有一个文件叫『File with long name.txt』,其对应的短文件名为『FILEWI~1.TXT』。现在在一个不支持长文件名的程序中加载它,然后保存,结果是程序删掉了旧的FILEWI~1.TXT,然后创建了一个具有相同文件名的新文件。没有穿隧功能的话,与文件相关联的长文件名就不见了(译注:如前所述,程序不支持长文件名,所以不可能处理与长文件名相关的事务)。现在文件原来漂亮的长文件名不见了,而是变成了一个带着波浪线的短文件名,这可不好。

But where did the name “tunneling” come from?

话说回来,『穿隧』这个名字是哪来的呢?(译注:File system tunneling 没有官方中文译名,此处译文仅供参考)

From quantum mechanics.

来自量子力学。

Consider the following analogy: You have two holes in the ground, and a particle is in the first hole (A) and doesn’t have enough energy to get out. It only has enough energy to get as high as the dotted line.

请看如下类比:地上有两个洞,一个粒子在A洞中,并且其没有足够的能量跃出洞外,其能量最多只够到达虚线的高度(译注:可能是指图中半高处的灰色线)。

You get distracted for a little while, maybe watch the Super Bowl halftime show, and when you come back, the particle somehow is now in hole B. This is impossible in classical mechanics, but thanks to the wacky world of quantum mechanics, it is not only possible, but actually happens. The phenomenon is known as tunneling, because it’s as if the particle “dug a tunnel” between the two holes, thereby allowing it to get from one hole to another without ever going above the dotted line.

你只是一会儿没看它,可能是去看了会超级碗半场秀,等你回来的时候,这个粒子已经不知怎么进到右边的洞里(译注:直译写法在中文中不雅……理解就行)去了。这在经典力学中是不可能发生的事情,但感谢量子力学的光怪陆离,这不光可能发生,也会实际发生。这种现象被叫做『穿隧』,就好像粒子在两个洞之间『打了一条通道』,使其而需要上升到虚线的高度,就能从一个洞跃进另一个洞。

In the case of file system tunneling, it is information that appears to violate the laws of classical mechanics. The information was destroyed (by deleting or renaming the file), yet somehow managed to reconstruct itself on the other side of a temporal barrier.

而在文件系统中,穿隧则表现为信息看似打破了经典力学的机制:信息已被销毁(通过删除或重命名文件),但却成功在屏障的另一面重建了其自身。

The developer who was responsible for implementing tunneling on Windows 95 got kind of carried away with the quantum mechanics analogy: The fragments of information about recently-deleted or recently-renamed files are kept in data structures called “quarks”.

负责为 Windows 95 开发穿隧功能的开发者捎带着将量子力学的概念带了过来:刚刚删除或重命名过的文件的信息碎片,保存在了被成为『夸克』的数据结构中。

TONT 35013 SYSTEM_FONT 和 DEFAULT_GUI_FONT 是什么?

原文链接:https://devblogs.microsoft.com/oldnewthing/20050707-00/?p=35013

Among the things you can get with the GetStockObject function are two fonts called SYSTEM_FONT and DEFAULT_GUI_FONT. What are they?

在使用 GetStockObject 获取到的对象中,有两个字体分别叫 SYSTEM_FONT 和 DEFAULT_GUI_FONT,它们是什么字体呢?

They are fonts nobody uses any more.

这两个是已经无人在用的字体。

Back in the old days of Windows 2.0, the font used for dialog boxes was a bitmap font called System. This is the font that SYSTEM_FONT retrieves, and it is still the default dialog box font for compatibility reasons. Of course, nobody nowadays would ever use such an ugly font for their dialog boxes. (Among other things, it’s a bitmap font and therefore does not look good at high resolutions, nor can it be anti-aliased.)

回到 Windows 2.0 那时候,用于对话框的字体是一个叫 System 的位图字体,它是 SYSTEM_FONT 所指向的字体,也仍然为了向下兼容而保留用作对话框默认字体。当然,现在已经没有人再去将这么丑陋的字体用在自己的对话框上了。(除此之外,这是个位图字体,所以在高分辨率下观感不佳,也无法被抗锯齿处理。)

DEFAULT_GUI_FONT has an even less illustrious history. It was created during Windows 95 development in the hopes of becoming the new default GUI font, but by July 1994, Windows itself stopped using it in favor of the various fonts returned by the SystemParametersInfo function. Its existence is now vestigial.

DEFAULT_GUI_FONT 则有个不那么出名的故事,它是在 Windows 95 开发过程中创造出来的,原本被寄希望于用作新的默认GUI字体,但到了1994年7月,Windows 已经不再去调用这个别名了,而是使用 SystemParametersInfo 返回的几个字体,而它就变成了(Windows)进化过程中的残余。

One major gotcha with SYSTEM_FONT and DEFAULT_GUI_FONT is that on a typical US-English machine, they map to bitmap fonts that do not support ClearType.

还有一条关于 SYSTEM_FONT 和 DEFAULT_GUI_FONT 的常见技巧用法是,在常见的美国英语语言机器上,它们通常都指向不支持 ClearType 的位图字体。

TONT 35193 为什么在Windows中有基于广播的消息机制?

原文链接:https://devblogs.microsoft.com/oldnewthing/20050627-00/?p=35193

Many Windows information mechanisms are based on message broadcasts, among them DDE, WM_FONTCHANGE, and changes in system settings. Why do these mechanisms use broadcasts, when we know that broadcasts can result in the system grinding to a halt due to windows that have stopped processing messages?

许多Windows中的信息机制都基于消息广播,其中包括DDE、WM_FONTCHANGE,以及系统设置的变更等。为什么这些机制在知晓可能会遇到已经停止处理消息的窗口,而将整个系统拖入挂起状态的前提下,还是要使用广播机制呢?

Because in 16-bit Windows, you didn’t have this problem.

因为在16位Windows环境下,这个问题是不存在的。

Recall that 16-bit Windows was co-operatively multi-tasking. When a program received control of the CPU, it could do anything it wanted, knowing that no other programs could run until it explicitly yielded control by calling a function such as GetMessage or PeekMessage. The downside of this, of course, was that a single hung program caused the entire system to hang, because it wasn’t releasing the CPU. The upside, however, was that if your program was running, then you knew, a priori, that there were no hung programs in the system. How do you know that? Because if there were a hung program, it would be running and not you. If there’s only one thing, and you have it, then you know that nobody else is hogging it. Therefore, broadcasting messages was completely safe in 16-bit Windows. You didn’t have to worry about non-responsive programs because you had proof that there weren’t any.

回忆一下,16位Windows是协作多任务机制。当某个程序获得了CPU的控制权后,它就可以想做什么做什么,因为它知道直到调用类似GetMessage或PeekMessage这样的方法来让渡(对CPU的)控制权之前,没有其它程序是可以同时运行的。这种设计的不足之处,在于一个程序挂起就会导致整个系统挂起,因为它没有释放对CPU的控制权。而这种设计的益处,则在于如果你的程序在正常运行,那么就可以先知先觉地知晓系统中没有其它挂起的程序。何以见得呢?因为如果如果有挂起的程序的话,那肯定是其它正在运行的程序、并且肯定不是你。如果某样东西只有独一份,而此时它在你的掌控下,你就知道肯定没有其它人在占有它。因此,广播机制在16位Windows环境下是绝对安全的,你不用担心有未响应的程序,因为你有证据证明没有这回事。

Of course, when the switch to pre-emptive multi-tasking occurred, this assumption no longer applied, but by then it was too late. The broadcast-based model was already in use, and consequently had to be preserved for compatibility reasons. (It would be bad if, for example, Lotus 1-2-3 stopped working on Windows NT because DDE broadcasts were no longer supported. If the Windows NT team had tried that gambit, nobody would have upgraded and Windows NT wouldn’t have survived to make a second version.)

自然,当抢占式多任务出现后,这样的猜测就再也无法成立了,但那时已经太晚了。基于广播的模型已经广泛应用,并且基于兼容性的原因还得予以保留。(举例来说,如果 Lotus 1-2-3(译注:1990年代流行的办公软件)由于 Windows NT 不再支持 DDE 广播而无法是用了,那将是一件很糟糕的事。如果 Windows NT 团队真这样下注的话,是不会有人为此而升级系统的,而 Windows NT 连活到第二个版本的机会都没有。)

On the other hand, given the risks involved in DDE broadcasts, you probably would be better off designing your program to not use dynamic data exchange as a data communication mechanism, thereby avoiding the pitfall of message broadcasts. No point contributing to the problem.

另一方面,由于DDE广播中存在的这些风险,你大概应当选择不要使用动态数据交换(DDE)作为你的应用的数据通讯机制,这样就可以避免由于消息广播(的缺点)而产生的坑了。为这种问题添砖加瓦是没有意义的。

Day 5273 在Debian 10上安装Dell OpenManage

环境为Debian 10默认安装。

1、为PATH变量增加/usr/sbin(永久修改位置为/etc/login.defs):

export PATH=$PATH:/usr/sbin

2、在root下运行以下指令安装OpenManage软件包(来自此Reddit帖子,感谢作者):

gpg –keyserver hkp://pool.sks-keyservers.net:80 –recv-key 1285491434D8786F
gpg -a –export 1285491434D8786F | apt-key add –
echo “deb http://linux.dell.com/repo/community/openmanage/930/bionic bionic main” > /etc/apt/sources.list.d/linux.dell.com.sources.list
wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman-curl-client-transport1_2.6.5-0ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman-client4_2.6.5-0ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman1_2.6.5-0ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman-server1_2.6.5-0ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/s/sblim-sfcc/libcimcclient0_2.2.8-0ubuntu2_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/openwsman_2.6.5-0ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/multiverse/c/cim-schema/cim-schema_2.48.0-0ubuntu1_all.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/s/sblim-sfc-common/libsfcutil0_1.0.1-0ubuntu4_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/multiverse/s/sblim-sfcb/sfcb_1.4.9-0ubuntu5_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/universe/s/sblim-cmpi-devel/libcmpicppimpl0_2.0.3-0ubuntu2_amd64.deb
dpkg -i libwsman-curl-client-transport1_2.6.5-0ubuntu3_amd64.deb
dpkg -i libwsman-client4_2.6.5-0ubuntu3_amd64.deb
dpkg -i libwsman1_2.6.5-0ubuntu3_amd64.deb
dpkg -i libwsman-server1_2.6.5-0ubuntu3_amd64.deb
dpkg -i libcimcclient0_2.2.8-0ubuntu2_amd64.deb
dpkg -i openwsman_2.6.5-0ubuntu3_amd64.deb
dpkg -i cim-schema_2.48.0-0ubuntu1_all.deb
dpkg -i libsfcutil0_1.0.1-0ubuntu4_amd64.deb
dpkg -i sfcb_1.4.9-0ubuntu5_amd64.deb
dpkg -i libcmpicppimpl0_2.0.3-0ubuntu2_amd64.deb

apt update
apt install srvadmin-all
touch /opt/dell/srvadmin/lib64/openmanage/IGNORE_GENERATION
srvadmin-services.sh enable && srvadmin-services.sh start

3、此时已可通过https://IP:1311/看到网页界面,但命令行omreport功能暂时不可用,会提示:

omconfig: error while loading shared libraries: libxslt.so.1: cannot open shared object file: No such file or directory

执行以下指令安装所缺失的libxslt1.1:

apt-get install libxslt1.1

此时执行omreport的查询命令(如omreport system summary),会提示(即使在root下执行也是如此):

Error! User has insufficient privileges to run command.

依据此处内容提示(帖子下方的回复),应为缺失libncurses5,运行如下指令安装之,并重启OpenManage相关服务:

apt install libncurses5

systemctl start dsm_sa_datamgrd
systemctl start dsm_sa_eventmgrd
systemctl start dsm_sa_snmpd
systemctl start dsm_om_connsvc
systemctl start dsm_om_shrsvc

现在终于可以使用omreport在CLI下查看系统概况了。

TONT 35213 为什么 CreateProcess 函数会做自动修正?

原文链接:https://devblogs.microsoft.com/oldnewthing/20050623-03/?p=35213

Programs that weren’t designed to handle long file names would make mistakes like taking the path to the executable and writing it into the registry, unaware that the path might contain a space that needs quoting. (Spaces—while technically legal—were extremely rare in SFN paths.) The CreateProcess function had to decide whether to “autocorrect” these invalid paths or to let those programs simply stop working.

在设计阶段没有考虑处理长文件名的应用程序,在实际运行时处理诸如获取可执行文件路径、并将其写入注册表时可能出现一些纰漏,因为其意识不到路径中可能包含空格,需要用(英文)引号包裹起来。(虽然在短文件名体系下的路径中包含空格是合法的,但这种情况极为罕见)。CreateProcess 函数不得不做出一些(额外的)努力,来判定是为这些无效路径做一些『自动修正』,还是放任其停止工作算了。

This is the battle between pragmatism and purity.

这是一场有关实用主义与纯粹主义的论战。

Purity says, “Let them suffer for their mistake. We’re not going to sully our beautiful architecture to accomodate such stupidity.” Of course, such an attitude comes with a cost: People aren’t going to use your “pure” system if it can’t run the programs that they require.

纯粹主义者说,『让那些程序去承担自己犯下的错误吧,我们不应该为了适应这种愚蠢的做法而玷污我们华丽的架构。』当然了,这种态度的代价就是:当人们无法运行所需的程序时,是不会去选用你那所谓『纯粹』的系统的。

Put another way, it doesn’t matter how great your 1.0 version is if you don’t survive long enough to make a 2.0.

换个角度来说,要是你活不到出2.0版本的时候的话,不管你的1.0版有多伟大都没什么意义。

Your choice is between “being pure and unpopular” or “being pragmatic and popular”. Look at all the wonderful technologies that died for lack of popularity despite technical superiority. Sony Betamax. Mattel Intellivision. (And, in the United States: The metric system.)

你需要在『纯粹但无人问津』和『活跃且广为接受』做出选择。回顾一下那些虽然技术上优越、但由于缺乏流行度最终悻悻而终的技术吧。Sony Betamax,Mattel Intellivison都是例子。(在美国,还有公制系统也一样。)

Electric cars are another example. As great as electric cars are, they never reached any significant market success. Only after conceding to popularity and “sullying” their “purity” by adding a gasoline hybrid engine did they finally gain acceptance.

电动汽车是另一个例子(译注:本文撰写时2005年)。虽然电动汽车这个概念很先进,但却从来没有取得任何商业上的成功,只有在面向大众时做出退让、通过增加油电混动引擎而『玷污』了其『纯粹性』之后,才最终被人们所接受。

I see this happening over and over again. A product team that, hypothetically, makes automated diagramming software, says, “I can’t believe we’re losing to Z. Sure, Z’s diagrams may be fast and snazzy, but ours gets <subtle detail> right, and when you go to <extreme case> their diagrams come out a little distorted, and they’re faster only because they don’t try to prevent X and Y from overlapping each other in <scenario Q>. We’re doing all those things; that’s why we’re slower, but that’s also why we’re better. Those people over at Z just don’t ‘get it’.”

我已经看到类似的事情发生了一次又一次:假设有某个研发了一款自动图表软件的产品团队声称:『简直难以置信我们会输给Z公司。是啊,Z的图表软件的确是快了一点、时髦了一点,但我们的产品在(某个细枝末节)上做了正确的事,而且在(某个极端条件下)时,Z公司的软件生成的图表会有点扭曲,何况他们的软件之所以快,是因为他们没有再(场景Q)下避免X和Y重叠。我们把这一切都考虑到了,所以我们的软件会慢了一点,但这也是我们的软件更优的原因。那些吹捧Z公司软件的人根本不懂“这些”。』

Guess what. People are voting with their wallets, and right now their wallets are saying that Z is better in spite of all those “horrible flaws”. Whatever part of “it” they don’t get, it’s certainly not the “make lots of people so happy that they send you money” part.

你猜怎么着,人们是用钱包来投票的,而当下他们的钱包正在呐喊『Z公司的软件更好』而无视了那些“可怕的缺点”。不管这些人不懂的“那些”是什么,肯定不是“让很多人用得开心所以送钱给你”这部分。

TONT 35253 日期/时间控制面板不是当日历用的

原文链接:https://devblogs.microsoft.com/oldnewthing/20050621-04/?p=35253

Although many people use the Date/Time control panel to flip through a calendar, that’s not what it is for. In fact, if you use it that way, you can create all sorts of havoc!

尽管有很多人都用『日期/时间设置』控制面板来翻看日历,但这并不是其设计初衷。实际上,如果那样操作的话,还会造成各种大破坏呢!

In its original incarnation in Windows 95, the Date/Time control panel changed your date and time. If you clicked through the calendar to see next month, you actually changed your system clock to next month. If you changed your mind and clicked “Cancel”, the Date/Time control panel undid its changes and restored the date to the original date.

在 Windows 95 的『日期/时间设置』控制面板里,其是用来修改系统的日期和时间设置的。如果在里面的日历上点击查看下个月的话,实际上已经立刻将系统日期修改为下个月了,此时如果你改变主意点击『取消』按钮的话,『日期/时间设置』控制面板会撤销你的设置,并将系统事件调回修改之前的值。

In other words, here’s what happened, step by step:

换句话说,以下是在你操作期间会一步一步发生的事情:

  • On April 1, you open the Date/Time control panel.
    4月1日,你打开了『日期/时间设置』控制面板。
  • You change the month to May. The Date/Time control panel changes your system date to May 1. If you are running an appointment calendar program, all appointments from the month of April will fire. (For example, your April 15th alarm to remind you to file your income taxes.) You are annoyed by all these alerts and you cancel them.
    你(为了查看日历而)将月份改到了5月,而『日期/时间设置』控制面板也将系统日期改到了5月1日。如果你的系统上安装了日程提醒软件,所有4月份的安排此时都会被激活。(例如,你设置了4月15日提醒自己报税。)你被这些提醒吵到了,于是将它们全部取消掉了。
  • You decide you didn’t want to change the month to May after all and click Cancel.
    你决定实际上并不是要将系统日期修改为5月,于是点击了『取消』。
  • The Date/Time control panel changes the date back to April 1.
    『日期/时间设置』控制面板将日期改回了4月1日。
  • On April 15th, your income tax alarm fails to fire because you cancelled it, remember?
    在4月15日,报税的提醒并没有被激活,因为你之前将它取消掉了,还记得吗?

In other words, the Date/Time control panel was not designed for letting you flip through a calendar. It was designed for changing the system date and time.

换句话说,『日期/时间设置』控制面板的设计并不是让你用来翻日历的,而是用来修改系统的日期和时间的。

Unaware of its design, people have been using the Date/Time control panel as if it were a calendar, not realizing that it was doing all sorts of scary things behind the scenes. It’s like using a cash register as an adding machine. Sure, it does a great job of adding numbers together, but you’re also messing up the accounting back at the main office!

然而,在没有意识到这个设计的前提下,人们一直把『日期/时间设置』控制面板当日历来用,而并没有意识到背后正在发生的、各种可怕的事情。这就像用收款机当加法计算器一样。没错,它的确能把将数字加到一起这件事做得很好,但公司的会计可就要炸锅了。

For Windows 2000, in reluctant recognition of the way people had been mis-using the Date/Time control panel, it was rewritten so that it doesn’t change the system time until you hit the Apply button.

直到 Windows 2000 以后,意识到人们对『日期/时间设置』控制面板的误用,虽然很不情愿,但开发人员还是对其进行了重新编写,使其变成只有在点击『应用』按钮后,新的日期、时间设置才会生效了。

Aaron Margosis shows you how to grant a user permission to change the system date and time without having to make them a full administrator.

Aaron Margosis 在他的文章中介绍了如何获得用户授权来修改系统的日期和时间,而不必将用户提升为具有完全权限的系统管理员

(译注:我怎么感觉用户的直觉好像没什么问题,反倒是微软原本的设计过于超前啊……)

TONT 35393 为什么控制面板里的程序和属性页不会出现在任务栏上?

原文链接:https://devblogs.microsoft.com/oldnewthing/20050608-36/?p=35393

Control panel programs and property sheets don’t show up in the taskbar. Why not?

控制面板中的程序,以及各种属性页(译注:如文件属性、文件夹属性等)不会在任务栏中显示,为什么呢?

As I recall, the explanation was that control panel programs and property sheets aren’t applications. They are auxiliary helper windows that assist you with a task, but they aren’t a program in their own right. Therefore, they don’t get a taskbar button.

根据我的记忆,这是由于控制面板里的程序和属性页并不是应用程序。它们是用来协助你完成一项任务的辅助窗口,但其自身并非独立的程序,因此它们就不会有任务栏按钮。

I’ve always been kind of suspicious of that explanation, but there it is, make of it what you will. (I don’t mind the behavior—putting them in the taskbar just creates clutter—but the explanation I found kind of wanting.)

我对这种解释也心存疑虑,不过话就放在这儿,你可以按自己的想法理解。(我对这样的设计并不在乎——将这些内容在任务栏上再开一个按钮显得很累赘——但还是觉得这样的解释有一定的必要性存在。)

(译注:Windows 10 的相关设计已经做出了大幅改变,这里看看就好)

TONT 35653 微软的企业网络:比『地狱』还要恐怖1.7倍

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

Today I’m going to tell a story from 1996. Why? Because I can.

这回我要讲一个1996年的故事。为什么呢?因为我想这么做。

One of the tests performed by Windows Hardware Quality Labs (WHQL) was the NCT packet stress test which had the nickname “Hell”. The purpose of the test was to flood a network card with an insane number of packets, in order to see how it handled extreme conditions. It uncovered packet-dropping bugs, timing problems, all sorts of great stuff. Network card vendors used it to determine what size internal hardware buffers should be in order to cover “all reasonable network traffic scenarios”.

Windows硬件设备质量实验室(WHQL)日常进行的其中一项测试是NCT数据包压力测试(译注:没有找到NCT具体指什么,哪位朋友了解请赐教),而这项测试被冠了个昵称叫『地狱』(Hell)。这项测试的目的是让一块网卡去处理数量多到疯狂的数据包,以验证其在极限条件下的表现,而这项测试可以揭露出这块网卡的掉包bug、时序问题等各种各样的毛病。网卡供应商通过这项测试的结果来判定他们的产品硬件缓冲区的大小,以便应对『所有合乎常理的网络流量场景』。

It so happened that at the time this test had currency (1996 era), the traffic on the Microsoft corporate network was approximately 1.7 times worse than the NCT packet stress test. A card could pass the Hell test with flying colors, yet drop 90% of its packets when installed on a computer at Microsoft because the card simply couldn’t keep up with the traffic.

巧合的是,当年这项测试还具备价值时(1996年那时候),运行在微软的企业网络上的流量实际上大约是NCT数据包压力测试的1.7倍之多。某块网卡可能能在『Hell』测试中获得漂亮的分数,但将其安装在微软内部的机器上的时候仍然会有90%的丢包率,仅仅是因为这块网卡实在承受不住那么大的流量。

The open secret among network card vendors was, “If you want your card to work with Windows, submit one card to WHQL and send another to a developer on the Windows team.”

网卡供应商之间的一个公开的秘密是:『如果你想让自己的产品能在 Windows 上运行,那就在向 WHQL 提交样品的同时也给 Windows 开发组的工程师也送一块。』

(This rule applied to hardware other than network cards. I was “gifted” a sound card from a major manufacturer and installed it on my main machine. It wasn’t long before I found and fixed a crashing bug in their driver.)

(这条规矩在网卡之外的硬件上也适用。我就曾经被『赠予』了一块某大厂的声卡,于是就将其装在了我的机器上。没过多久,我就发现并修复了这块声卡的驱动里一个会导致崩溃的bug。)

TONT 35713 当人们要将安全漏洞作为功能的时候:窃取密码

原文链接:https://devblogs.microsoft.com/oldnewthing/20050504-52/?p=35713

Sometimes people ask for features that are such blatant security holes I don’t know what they were thinking.

有些时候,有些人提出的功能需求完全就是安全漏洞,真不知道这些人脑子里都在想什么。

Is there a way to get the current user’s password? I have a program that does some stuff, then reboots the system, and I want to have the current user’s password so I can log that user back in when I’m done, then my program can resume its operation.

有没有办法获取当前用户的密码呢?我的程序会进行一些操作,然后重新启动系统,这时候我希望能获得用户的密码,这样重启完成后就能替用户进行登录,然后我的程序就能继续执行剩下的操作了。

(Sometimes they don’t bother explaining why they need the user’s password; they just ask for it.)

(有时候这些人连为什么需要用户的密码都懒得解释,就只是要而已。)

Imagine the fantastic security hole if this were possible. Anybody could write a program that steals your password without even having to trick you into typing it. They would just call the imaginary GetPasswordOfCurrentUser function and bingo! they have your password.

想象一下如果这件事成为可能的话,会产生一个多么美妙的安全漏洞。任何人都可以写一段程序来窃取你的密码,甚至不需要欺骗你把密码输进去,只需要调用那个虚构的 GetPasswordOfCurrentUser 方法就好了,一转眼,他们就拥有了你的密码。

For another angle on credential-stealing, read Larry Osterman‘s discussion of why delegation doesn’t work over the network.

或者也可以换个角度来观察凭据窃取这个问题,可以读一读  Larry Osterman 关于为什么代理认证在(内部)网络上行不通的文章。

Even if you didn’t want the password itself but merely some sort of “cookie” that could be used to log the user on later, you still have a security hole. Let’s call this imaginary function GetPasswordCookieOfCurrentUser; it returns a “cookie” that can be used to log the user on instead of using their password.

即便你不是想要密码本身,只是想要个某种形式的『Cookie』用于稍后替用户登录,这样操作同样也是一个安全漏洞。姑且将这个想象中的方法叫做 GetPasswordCookieOfCurrentUser,调用之会返回一个『Cookie』可以在稍后用于替用户登录,而不是直接返回用户的密码。

This is just a thinly-disguised GetPasswordOfCurrentUser because that “cookie” is equivalent to a password. Log on with the cookie and you are now that person.

这不过是前述的 GetPasswordOfCurrentUser 稍稍改头换面了一下而已,因为这个『Cookie』等同于密码,用这个『Cookie』登录之后你就是用户本人了。

(译注:Windows 10 看上去已经有了这篇15年前的文章描述的功能了——设置—账户—登录选项—『更新或重启后,使用我的登录信息自动完成设备设置并重新打开我的应用』,但仅限于系统更新或由系统发起的设备配置,而不是像这篇文章说的那样可以由第三方程序使用,且如果本机加入了域或应用了组策略,则该功能不可用。点击这里查看官方说明。)

Day 5205 关于『饭碗儿』的一些说明

由于饭否的页面及API设计,有关『饭碗儿』账号的一些说明写在个人简介中相当局促,在账号开设近5年后的今天,终于还是决定单列一个页面,对一些问题进行说明。

一、『饭碗儿』是什么

『饭碗儿』是一个对饭否『随便看看』栏目的统计账号。由于『随便看看』包含来自全站公开消息中的随机的20条左右的数据,在一定程度上可以作为饭否站内消息概况的一个缩影。

很多对『饭碗儿』的疑问都来源于对上述概念的不完整理解,如果您对『饭碗儿』的数据有疑问,请继续往下看。

二、『饭碗儿』的数据生成过程

『饭碗儿』的统计数据来源于对『随便看看』的数据采集。每个整秒分钟(如:8:00:00,或:13:45:00),『饭碗儿』的后台服务都会对『随便看看』进行一次数据采集,并将全量数据保存在本地备用。

每周一(理论上),『饭碗儿』的管理者(我)会用事先写好的工具将上周七天的数据进行统计,包含如下两类数据:

(一)客户端使用情况:在数据中查找名称『完全不同』的API名称(即『通过____发送』的中间部分,如:网页、御饭 iPhone 等等)进行计数统计。

(二)公共TL话痨50强:在数据中查找发送人、消息内容、发送时间完全不同的饭否消息,统计其所属的发送人出现的次数。

关于第(一)条,一个普通用户不容易注意到的细节是,API 返回中的 API 名称,除饭否官方 API 外(如『网页』,即饭否的PC端网页),原则上所有API都必填一个应用说明页面的URL,采集时,这类API名称会体现为:<a href=”http(s)://应用说明页面网址/”>API名称</a>。对于去掉<a>标签后名称相同的API,统计时会按照两条数据对待。

统计好之后,管理者还会对按要求提交排除申请用户和API名称进行处理,将这些数据进行剔除,最后制成图表,发送到账号上。

三、关于『饭碗儿』的一些疑问

倘若仔细读过了前述说明,仍未能解答您的疑问的话,这里有一些饭否用户对『饭碗儿』的一些问题,可供参考。

如您仍有其它下列未列出的问题,可在本文下方留言提问,确实未予回答的,本人会进行回复。

(〇)星期一了,怎么没发统计数据?

答:平日工作较忙,如未能准时发布,后面会尽量补上,请理解。未制作自动制图流程,因为我懒。此外,由于服务端托管环境的不稳定性(如系统崩溃、机房停电等),部分期数可能无法发布,如有时间,会登录饭碗儿账号进行说明,也可能没有解释。

(一)随便统计别人发过的消息次数,你是不是变态?

答:『随便看看』中的消息,均由饭否官方通过自动的形式公开向登录用户进行展示,『饭碗儿』无法控制饭否『随便看看』功能展示的信息,仅对这些公开数据进行采集,且仅作为统计原始数据使用,没有将这些消息的内容进行转载、修改或任何妨害消息原发布者隐私权的行为,如果您认为『饭碗儿』的行为侵犯了您的个人权益,请参考下述第(二)条的方式,向『饭碗儿』主动提交从统计数据中移除的请求,否则视为同意『饭碗儿』对您出现在『随便看看』中消息的采集行为,『饭碗儿』不对任何人的玻璃心行为负责。如您仍有疑问,请恰饭否官方或法律人士进行咨询,『饭碗儿』保留对不合理的请求进行无视、在『饭碗儿』账号上进行公开发布的权利。

(二)因为个人原因,我不想让我的账号或API名称出现在『饭碗儿』的统计数据中,应该怎么做?

答:请通过饭否的『私信』功能,向『饭碗儿』发送私信,说明您(或您的API名称,此处建议您提供带有对应API名称的示例公开消息,以便准确定位)不想在『饭碗儿』的统计数据中出现即可,无需提供理由,除此之外的方式均视为无效,不予受理。『饭碗儿』将从消息收到之日起(视乎『饭碗儿』所有人登录饭否网查看私信之时间为准,不以消息发出时间为准)永久性地将您或您的API名称从『饭碗儿』的后续统计数据中移除。此外,由于饭否的功能限制,已发送的消息无法进行修改,故若已发送的统计数据中包含您或您提供的API名称,则无法进行移除,望知悉。

(三)为什么我说了那么多的话(为什么我的应用明明那么多人用),却没有上『饭碗儿』的『公共TL话痨50强』(客户端使用情况)的榜单?

答:请注意『饭碗儿』只是对『随便看看』数据的统计,由于饭否的『随便看看』是对全站公开数据的随机抽取,以上两种状况发生的原因有:(1)在每分钟采集时,『随便看看』中没有抽到您(的API)的消息;(2)统计期间您打开了隐私保护(即所谓的『上锁』),使得您的消息不会出现在『随便看看』中。

(四)为什么我(的API)在统计期间明明发了10000条消息,却只给我算了1000条?『饭碗儿』是不是把我拉黑了?

答:请注意『饭碗儿』只是对『随便看看』数据的统计,由于饭否的『随便看看』是对全站公开数据的随机抽取,数据存在一定的随机性,且『饭碗儿』并非针对单个用户(或API)个体进行数据统计,故只能代表您(的API)在『随便看看』中每整分钟采集时的情况,仅供参考,不能代表精确的情况。此外,『饭碗儿』从未也不会主动拉黑任何人或任何API名称,除非用户或API名称的持有人通过上述第(二)条中描述的方式提起请求,此时『饭碗儿』会按要求对相应的数据条目进行移除。

(五)为什么我(的API)发了10000条消息,然后又全删掉了,统计的时候还是给我算了8000条消息?

答:请注意『饭碗儿』只是对『随便看看』数据的统计,数据来自每个整分钟对『随便看看』进行采集,但不会后期再次验证拉取消息的删除情况,故拉取数据时已发送的消息均会列入统计。

(六)我有几个API名称,能不能帮我合成一条统计记录?

答:维护API名称是开发者的责任,不提供此服务。

(七)为什么客户端列表中有两个『网页』?

答:数量较多者为饭否官方的“网页版”,较少者为某系列机器人的API名称(自2021年起,因对应服务停运,仅保留1个Bot运行,消息数量下降,基本已不会再产生混淆)。

四、一点点『饭碗儿』的历史

『饭碗儿』账号建立于2015年10月12日,起初是因对饭否全站的消息词频等数据感兴趣而设立的。

最开始时,『饭碗儿』曾对客户端统计情况、公共TL话痨50强、消息时段分布及词频进行统计。后来经过一段时间的运行,消息时段分布因每次都几乎没有差别,没有太大意义而取消掉了,词频云则由于未能找到物美价廉的分词API而作罢,而余下的两种类型,则一直运行到今天。

『饭碗儿』运行至今,除了一大堆娱乐性图表外,还积累了另一份数据:2015年11月至今的饭否『随便看看』每周1.08万次的采集。尽管该数据因硬件故障、API故障、被意外封停等问题并非全量,但在某种意义上也是见证了饭否多年来公开的欢声笑语。