# May, 2010

• #### It rather involved being on the other side of this airtight hatchway: Consequences of enabling the kernel debugger

In the category of dubious security vulnerability, I submit for consideration the following report:

A machine with the kernel debugger enabled is vulnerable to a denial of service attack from an unprivileged user. The unprivileged user need only deference a null pointer. Once this occurs, the computer becomes completely unusable to all users.

Um, yeah. That's sort of the whole point of the kernel debugger, to halt system execution as soon as a problem has been detected. Enabling the kernel debugger requires administrative privileges, so it's not like unprivileged users can force a system halt on their own; they need the help of an administrator to turn on kernel debugging first. At that point, you've already made it to the other side of the airtight hatchway. If you have an accomplice who is already an administrator, then you may as well just cut to the chase and tell your accomplice to add you to the administrators group, too. Then you can do much more than simply halting the system.

Clarification: As Bob noted, and which I apparently didn't make clear enough from the title of the article, this message arrived as a security vulnerability report. It's not a security vulnerability if it requires assistance from an administrator to pull off.

• #### On nearly getting pickpocketed in both Lisbon and Madrid

My trip to Lisbon introduced me to another tourist phenomenon: pickpockets.

It was around 10:30 in the morning, and I got on the train to head into town, planning to climb the steps through the Alfama district to visit the castle which looms over the city. The morning rush was over, and the Metro car was nearly empty.

Just before the doors closed, a group of about four twentysomething guys stumbled onto the train, walking unsteadily and talking quite loudly among themselves. I found this immediately suspicious. They are acting drunk, but who is drunk at 10:30 in the morning? At 10:30, you're hung over, not drunk. And even if you are drunk, you are drunk in the comfort of your home, not stumbling around the subways.

Even though the subway car had only about three people, and there was plenty of room to spread out, this group of pretend-drunks hung around close to me. I went on high alert.

A few seconds later, one of the guys "stumbled" into me and thrust his hand into my pants pocket. I immediately grabbed his hand and yanked it back out, making sure he didn't get anything, adding a shout of "Hey!" (I don't speak Portuguese, so I couldn't say anything more eloquent.)

Still keeping up the ruse of just being a bunch of loud-mouthed drunks, the group of would-be pickpockets stumbled off the train just as the doors closed. Well, three of them did. One of them didn't quite get off in time and stood with his face against the wall until the train reached its next stop, at which point he ran off.

After Lisbon, I headed over to Madrid, and on the Metro I was on one of the long escalators connecting between two train lines, and I caught the person behind me surreptitously trying to unzip an outside pocket on my shoulder bag. He hadn't made much progress, but just to make sure he didn't get anything, I said hello and shook his hand.

Bonus chatter: Getting targeted by thieves in Europe seems to be a tradition for me. During the Berlin phase of a previous visit to the continent, a thief tried unsuccessfully to steal the camera out of my hand. Sweden treats me well, though. I don't get targeted by pickpockets; just people trying to recruit me into some sort of organization.

[Raymond is currently away, possibly being pickpocketed this very moment.]

• #### Why can programs empty the clipboard when they start up?

Via the Suggestion Box, Johan Almén asks, "What was the rationale behind the decision to let Excel empty the clipboard when launched?"

Why can an application empty the clipboard? Because it's there.

After all, the point of the clipboard is to hold information temporarily. Programs are permitted to empty the clipboard, add data to the clipboard, or retrieve data from the clipboard. That's why it's there.

(I'm assuming that the naming of the program Excel was just an example of a program, and that the question wasn't "Why doesn't Windows have a specific check for the program EXCEL.EXE and block its clipboard access while still allowing clipboard access to everybody else.")

Okay, maybe the question wasn't so much "Why are programs allowed to empty the clipboard" as it was "Why are programs allowed to empty the clipboard when they launch?" Well, because that might have been the whole point of the program! Somebody might write a program called empty­clip whose sole purpose in life is to empty the clipboard. You run the program, it empties the clipboard, and then it exits. Short and sweet. If Windows didn't allow programs to empty the clipboard when they started up, then this program would not be able to get its work done.

You might not consider that particularly useful, but there are actually quite a few programs which empty the clipboard when they start up. For example, the clip program that comes with Windows takes its standard input and places it on the clipboard. Implied in that functional description is that it erases what used to be on the clipboard. Everything the program does is in its startup.

echo I'm on the clipboard! And I erased what use to be there.| clip


Many scripting languages provide access to the clipboard, if not natively, then through an extension. Since these are typically not GUI programs, as far as the window manager can tell, these programs as perpetually stuck in their startup code: They never go input idle because they never pump messages. Prohibiting programs from accessing the clipboard during startup means that console programs are effectively banned from modifying the clipboard at all.

Okay, maybe the question wasn't "Why are programs allowed to empty the clipboard when they launch?" so much as it was "Why are programs allowed to empty the clipboard outside of an explicit user action (like a click or a hotkey)?" Well, we still have the problem of programs whose design is to empty the clipboard without any user interaction, like all those console scripts. But you also remove many GUI usage patterns, such as pushing work to a background thread so that the program can remain responsive. And it would also prevent you from writing a program that modified the clipboard in response to a drop operation. I can imagine a program called file­contents­to­clip which just sits there and waits for you to drag/drop a file onto its window. When you do that, it opens the file and places the file's contents onto the clipboard. Since the drag/drop operation is handled by the drag source, the drop target receives no input and (according to the rule of "no clipboard access without user input") is denied permission to erase the old clipboard contents.

In order for these sorts of interaction models to work, there would have to be some sort of Allow­Clipboard­Access function (akin to Allow­Set­Foreground­Window) so that one process can temporarily transfer clipboard access permission to another process. It could be done, but it would make writing applications more complicated, because you would have to anticipate what operations might result in another application wanting to access the clipboard and scattering calls to Allow­Clipboard­Access in various places in your program. If you miss a spot, you'll get some bug filed against your program that says, "When I click the Preview button, and I've set my custom previewer to program X and configure program X to say 'always copy image to clipboard when previewing', the feature doesn't work."

The clipboard was part of Windows 1.0, and back in those days, you didn't have a lot of memory available. You had to get a lot done with very little. Programmers were trusted to use their great power with great responsibility. And besides, as we saw with programs like clip (and hypothetical programs like empty­clip and file­contents­to­clip), allowing programs to empty the clipboard at startup made it possible to write some interesting and useful tools. Windows historically didn't stop programmers from doing stupid things because that would also prevent them from doing clever things.

As a child, my mother would always call out "banzai" when she wanted me to raise my arms above my head so she could put on or take off a pullover shirt. I assumed that banzai was the word for "stick your hands in the air!"

It wasn't until well into my adult life that my mother explained to me that, no, banzai does not mean "stick your hands in the air." It's a Japanese word meaning "ten thousand years", shouted as a term of approbation and accompanied by (you guessed it) throwing one's hands into the air. My mother was using it as a play term; in the United States, when you get your child to throw his hands into the air, you might accompany it with a shout of "Touchdown!"

What words have you gotten wrong your entire life?

Related: I Used to Believe.

Reminder: This upcoming Sunday is Mother's Day in the United States, and it honors all mothers, not just your own.

Bonus niece chatter: For a time, one of my nieces called a sneeze a bleshoo.

• #### The many ways of converting a string from one language to another

A customer asked, "I'm looking for a way to convert English characters to another language. For example, if the target language is Arabic and the string is the word Hello, I want it to convert to H(Arabic)e(Arabic)l(Arabic)l(Arabic)o(Arabic)."

The question is still vague, even with the assistance of the example, since it's not clear what "H(Arabic)" means.

There are a variety of ways of converting a string from one language to another. Here are a few I was able to think of.

• Translation. For example, converting cat to German would result in Katze. Of course, there are many words with no good direct translation and others which are ambiguous. Good-bye is normally Auf Wiedersehen, but if you're saying good-bye to someone on the telephone, then it's Auf Wiederhören. But at least in that case, even if you get it wrong, the reader has some idea of what you meant. Whereas sort could be translated as Art (as in What sort of apple is this?) or as ordnen (as in Sort these alphabetically), and if you get the wrong one, the reader is completely baffled. (Now, translation is clearly not what was intended here, but I included it for completeness.)
• Transliteration. This is an operation most commonly performed between scripts, such as how the name of the capital of China 北京 becomes Beijing in English. The great thing about transliteration systems is that you usually have many to choose from. For example, if you prefer Wade-Giles over Pinyin, then the capital city would be spelled Pei-Ching. Transliterating to non-alphabetic scripts can be quite a challenge as well: Everyone is familiar with the story of Coca-Cola in Chinese. (Learn more about Extended Linguistic Services from Kieran Snyder, the long-distance linguist. I considered linking to specific articles until I realized that I was basically linking to everything, so here's the main page. Go nuts.)
• Phoneticization. This is similar to transliteration, but spells out the sounds when you cannot assume that the reader is familiar with any particular transliteration system. The capital of China would be phoneticized as bay-jing.

As it turns out, the customer wasn't interested in any of these!

What the customer wanted was, "Take the word Hello and imagine how you would type it on a US-English keyboard. Now change the keyboard layout to Arabic and then press exactly the same keys. That's what I want." In other words, the customer wanted to see what the result would have been if you had told a blindfolded touch-typist to type Hello, but secretly replace the US-English keyboard with an Arabic one.

Wow, that's something that hadn't even occurred to me as a possibility.

Fortunately, Michael Kaplan was able to come to the rescue by pointing the customer to the Keyboard Convert Service.

• #### On the Portuguese custom of the couvert, and other restaurant customs

In restaurants in the United States, the custom is that anything brought to the table that you didn't order is complimentary. For example, after you place your order, the waiter returns to your table with a basket of bread. The bread is provided at no extra charge. These complimentary items are usually small, like some bread or a one-bite appetizer. (If anything bigger is brought to the table that you didn't request, it is customary to ask the waiter, "Is this ours?" just to make sure it wasn't delivered to the wrong table by mistake.)

In Portugal, the custom is that these items (known as couvert) are brought to your table as a convenience so you don't have to order them, but you still have to pay for them if you eat them. Again, they are typically small items like bread or a small plate of olives. It took me a while to adjust to the Portuguese custom, and I would absently start eating them before realizing that they weren't complimentary. Fortunately, the mistake is not costly; these couvert items usually cost only about one Euro, two tops, and they are things you usually wouldn't have minded ordering anyway.

There was one restaurant in the touristy restaurant part of Lisbon which was clearly trying to exploit the inattentive foreigners. Before my main course was ready, the waiter brought a not insubstantial cheese plate to the table. The cheese appeared quite old. (Yes, I know cheese is supposed to be old, but this one had dried out at the edges.) I may even have detected a layer of dust on it. This was the last meal of my visit, so by then I had figured out this couvert thing and knew to stay away. Which was a good move, because I checked the menu on the way out, and the cheese plate costs a whopping €7.50.

Another restaurant custom different between the United States and Portugal is the doggie bag, In the United States, it is customary for restaurants to offer to pack your uneaten food for you to take home. This is common because portion sizes in the United States have grown to ridiculous levels. The term doggie bag appears to have fallen out of favor, though. Now it's just called a box, as in "Would you like a box for that?" or "Would you like me to box this up?" The doggie bag is not part of Portuguese custom; when asked for a box to take home uneaten food, the waiter reacted as if this were a completely unheared-of situation. To his credit, he did find a solution: He went to the Chinese restaurant next door and took one of their take-out containers.

Nice to know that Chinese restaurants are the same all over the world.

Bonus restaurant tip: In my experience, in Portugal, you have to ask for the check. In the United States, whether you have to ask for the check or whether it will be brought to you varies regionally. In the Northeast, you have to ask for it; in the Seattle area, it will typically be brought to you, usually with a remark from the waiter like "Take your time," which means "I'm not trying to rush you out of here; I'm just saving you the trouble of asking for the check. Pay when you're ready." (Unless you're in a Vietnamese restaurant, in which case you have to ask for the check, per custom.)

• #### What are these strange =C: environment variables?

You won't see them when you execute a SET command, but if you write a program that manually enumerates all the environment variables and prints them out, and if you launch it from a command prompt, then you'll see weird variables with names like =C: and whose values correspond to directories on that drive. What are these things?

These variables are part of the private bookkeeping of the command processor cmd.exe. That's why I added if you launch it from a command prompt to the steps above, because if you run the program from Explorer's Run dialog, you won't see them. If a cmd.exe is not in the chain of custody of your environment block, then you won't see the weird cmd.exe bookkeeping variables.

Okay, so the command processor sets these things, but what are they? They are a leftover from the command processor's attempt to mimic the old MS-DOS way that drives and directories were handled. Whereas in Win32, there is only one current directory, in MS-DOS, there was one current directory for each drive. Consider the following sequence of commands:

A> CD \SUBDIR
// current directory for drive A is A:\SUBDIR
A> B:
B> CD \TWO
// current directory for drive B is B:\TWO
B> A:
A> DIR
// shows a directory listing for A:\SUBDIR


During this sequence of commands, we start with A: as the current drive and set its current directory to A:\SUBDIR. Next, we set the current drive to B: and set B:\TWO as its current directory. Finally, we set the current drive back to A:, and when we ask for a listing, we get the contents of A:\SUBDIR because that is the current directory on the current drive.

Win32 does not have the concept of a separate current directory for each drive, but the command processor wanted to preserve the old MS-DOS behavior because people were accustomed to it (and batch files relied upon it). The solution was to store this "per-drive current directory" in the environment, using a weird-o environment variable name so it wouldn't conflict with normal environment variables.

If you repeated the above commands in cmd.exe, the output is the same, but it is accomplished in a very different way.

A> CD \SUBDIR
// Environment variable =A: set to A:\SUBDIR
// Current Win32 directory set to A:\SUBDIR
A> B:
B> CD \TWO
// Environment variable =B: set to B:\TWO
// current Win32 directory set to B:\TWO
B> A:
// Current Win32 directory set to A:\SUBDIR
A> DIR
// shows a directory listing for A:\SUBDIR


When we switch back to drive A:, the command processor says, "Hey, what was the current directory on drive A: the last time I was there?" It looks into its environment and finds the =A: variable, which tells it, "Oh, it was A:\SUBDIR". And that's the Win32 directory that it sets as current.

But why put these internal variables in the environment? Can't they just be regular variables inside the cmd.exe process?

The variables are exported into the environment because you want these "fake per-drive current directories" to be inherited by child processes. For example, consider that you are sitting at your command prompt, you run emacs, then from emacs, you shell out to another command prompt. You would expect that the nested command prompt will have the same "per-drive current directories" that you set back in the outer command prompt.

C:\SUBDIR> D:
D:\> emacs
M-x shell
D:\> C:
C:\SUBDIR>
// the "current directory on drive C" was inherited as expected


What should you do about these variables, then?

Nothing. Just let them be and do their jobs. I'm just mentioning them here so you won't freak out when you see them.

• #### Eating where the teenagers are: Pão Pão, Queijo Queijo

In Belém, directly to the east of the Mosteiro dos Jerónimos is a block of small shops, the most famous one of which being the Pastéis de Belém which sells the, um, Pastel de Belém, the Belém version of the unofficial dessert of Portugal. (This photo of a group of people eating was taken in front of the Pastéis de Belém shop. You can see the blue awnings in the background.) The place is always packed shoulder-to-shoulder with tourists. So turn around, leave the store, and walk back toward the Mosteiro dos Jerónimos. At about where the pink building is in the photo referenced above is a tiny shop called Pão Pão, Queijo Quejo, which means Bread Bread Cheese Cheese. If the photo doesn't help, here's how you find it: It's the one packed to the gills with teenagers.

Now, following the teenagers to decide where to eat is a hit-or-miss affair. You might find an awesome little shop, or you might end up at McDonalds. I lucked out and scored a major win.

Here's how you enjoy lunch at Pão Pão, Queijo Queijo:

• Read the menu board posted outside to decide what you want. Have your dictionary handy since it's only in Portuguese.
• Join the mob-like approximation of a line that snakes out the door.
• When you reach the register near the door, place your order and pay for it. You will receive an order slip.
• Join the mob inside the store and try to work your way to the counter where all the food is.
• Get the attention of somebody behind the counter. You are competing with two dozen other people at this point, so it may take some effort.
• Hand the person your order slip and do your best to answer questions like "Do you want sauce?" and "For here or to go?" The correct answers are "Only a little" and "To go", by the way.
• Receive your sandwiches, grab some extra napkins, and walk across the street to the park.
• Enjoy your sandwich in the park while taking in the view of the Ponte 25 de Abril (the April 25 Bridge), then take a nap in the warm sunshine.

Second only to salt in the Portuguese diet appears to be ranch dressing/mayonnaise/whatever that white sauce is. (Hence the need for extra napkins and the correct answer of "Only a little.") If you're not careful, you'll find your sandwich drowning in approximately ten cubic meters of the stuff. But once you get past that, you have a tasty sandwich with warm meat and crunchy slaw on a crisp baguette. It's sort of a Portuguese version of a Vietnamese sandwich.

• #### How the shell converts an icon location into an icon

A customer had trouble getting an icon to display for a registered file type.

In my resource file, I specify the icon like this:

101 ICON awesome.ico


And when I register my file type, I set it like this:

[HKEY_CLASSES_ROOT\.xyz\DefaultIcon]
@="C:\path\to\awesome.exe,101"


However, when I view an .xyz file, my awesome icon doesn't appear. On the other hand, if I change the 101 to a 0, then it works. Why? Isn't the number in the resource file the resource ID?

Why yes, in fact, the number in the resource file is indeed the resource ID. But the number after the comma in the Default­Icon isn't.

The format of shell icon locations (used most visibly by Default­Icon, but also used in other places) is «file»,«index», where the index is a zero-based index of the icon in your resources. In other words, an index of zero means "Give me the first icon in the file." The resource compiler sorts icons numerically by resource ID, so the first icon in the file is the icon with the numerically lowest resource ID. In the above example, apparently there are no icons with resource IDs less than 101; that would explain why asking for icon index zero results in the awesome icon.

The function behind all this icon hunting is Extract­Icon. The icon location string is split up at the comma into a path and an integer, and that path and integer are passed to the Extract­Icon function. Since the Extract­Icon function interprets the integer as the icon index, that's what the integer in your icon location string means.

In Windows 95, the Extract­Icon function was enhanced so that you could also specify an icon by its resource ID by passing its negative as the icon index. In other words, if you place a negative number after the comma, then its absolute value is interpreted as the resource ID.

We learned some time ago that there's a hole in this model: It doesn't work if you want a resource ID of 1, because the value −1 has a special meaning to Extract­Icon: Instead of extracting an icon, it tells you how many icons there are.

The workaround for this is actually straightforward, and you should be able to figure it out on your own based on information provided in this article. How do you specify that you want the icon whose resource ID is 1?