The Old New Thing

The world reaction to the unexpected death of Michael Jackson extends to young children

I had occasion to meet up with the same family whose two-year-old was learning to lie in an earlier story. It was only a day or two after the death of Michael Jackson, and the older sister (five years old) told me, "Did you know? Michael Jackson, he went to sleep and he is never going to wake up."

Her younger sister (now three), corrected her.

"No, he's dead!"

If dynamic DLL dependencies were tracked, they'd be all backwards

Whenever the issue of DLL dependencies arises, I can count on somebody arguing that these dynamic dependencies should be tracked, even if doing so cannot be proven to be reliable. Even if one could walk the call stack reliably, you would still get it wrong.

The example I gave originally was the common helper library, where A.DLL loads B.DLL via an intermediate function in MIDDLE.DLL. You want the dependency to be that A.DLL depends on B.DLL, but instead the dependency gets assigned to MIDDLE.DLL.

"But so what? Instead of a direct dependency from A.DLL to B.DLL, we just have two dependencies, one from A.DLL to MIDDLE.DLL, and another from MIDDLE.DLL to B.DLL. It all comes out to the same thing in the end."

Actually, it doesn't. It comes out much worse.

After all, MIDDLE.DLL is your common helper library. All of the DLLs in your project depend on it. Therefore, the dependency diagram in reality looks like this:

A.DLL depends on B.DLL, and both DLLs depend on MIDDLE.DLL. That common DLL really should be called BOTTOM.DLL since everybody depends on it.

Now you can see why the dependency chain A.DLL → MIDDLE.DLL → B.DLL is horribly wrong. Under the incorrect dependency chain, the DLLs would be uninitialized in the order A.DLL, MIDDLE.DLL, B.DLL, even though B.DLL depends on MIDDLE.DLL. That's because your "invented" dependency introduces a cycle in the dependency chain, and a bogus one at that. Once you have cycles in the dependency chain, everything falls apart. You took something that might have worked into something that explodes upon impact.

This situation appears much more often than you think. In fact it happens all the time. Because in real life, the loader is implemented in the internal library NTDLL.DLL, and KERNEL32.DLL is just a wrapper function around the real DLL loader. In other words, if your A.DLL calls LoadLibrary("B.DLL"), you are already using a middle DLL; its name is KERNEL32.DLL. If this "dynamic dependency generation" were followed, then KERNEL32.DLL would be listed as dependent on everything. When it came time to uninitialize, KERNEL32.DLL would uninitialized before all dynamically-loaded DLLs, because it was the one who loaded them, and then all the dynamically-loaded DLLs would find themselves in an interesting world where KERNEL32.DLL no longer existed.

Besides, the original problem arises when A.DLL calls a function in B.DLL during its DLL_PROCESS_DETACH handler, going against the rule that you shouldn't call anything outside your DLL from your DllMain function (except perhaps a little bit of KERNEL32 but even then, it's still not the best idea). It's one thing to make accommodations so that existing bad programs continue to run, but it's another to build an entire infrastructure built on unreliable heuristics in order to encourage people to do something they shouldn't be doing in the first place, and whose guesses end up taking a working situation and breaking it.

You can't even write programs to take advantage of this new behavior because walking the stack is itself unreliable. You recompile your program with different optimizations, and all of a sudden the stack walking stops working because you enabled tail call elimination. If somebody told you, "Hey, we added this feature that isn't reliable," I suspect your reaction would not be "Awesome, let me start depending on it!"

Film students and The Bicycle Thief

The current generation of young people grew up in a very different world from us older folks. There has always been an Internet. Everybody is accessible by mobile phone. Cars have always had power windows. (Which reminds me of a story of a friend of mine who has an older-model car and was giving a ride to an eight-year-old relative. The youngster pointed at the window crank and asked, "What's this?" Upon learning its purpose, the young passenger spent the remainder of the trip opening and closing the window, giggling with glee. "You know, most people pay extra so they don't have to do that.")

But it's not just elementary school children whose views of the world are different.

Some time ago, I was at a dinner where another guest was a film professor at the local university. In one class, they were discussing the classic movie Ladri di Biciclette (The Bicycle Thief in the United States), the story of a poor man in post-war Italy searching for his stolen bicycle, the bicycle he needs for his job. One student asked, "Why doesn't he just buy another bicycle?"

MS-DOS also allowed spaces in file names, although vanishingly few programs knew how to access them

A little-known fact about MS-DOS is that it allowed spaces in file names. Sure, you were limited to 8.3, but a file called "LOOK AT.ME" was legal in MS-DOS, and you could indeed create such a file. Good luck finding programs that didn't treat you as insane when you asked for that file, though.

Although the file system supported files with spaces, practically no programs supported them. Command line tools saw the space as the end of the file name. You couldn't quote the file name because no command line tool supported quotation marks to protect spaces. After all, if you believed that spaces were illegal characters in file names, you wouldn't write extra code to allow people to specify a file name with spaces in them!

The only program in common use that I remember supporting spaces in file names was GW-BASIC. If you were naive enough to create a file in GW-BASIC with a space in its name, you found yourself in a pretty nasty world of hurt once you escaped GW-BASIC back to the real world. The easiest way to delete such a file was to go back into GW-BASIC and delete it from there.

Up and down often substitute for compass directions, but you have to know when you've taken it too far

The official curriculum for seventh grade students in the state of Washington includes Washington history and geography. My friend the seventh grade teacher typically includes as part of this curriculum an assignment wherein each student is assigned one of the state's counties on which to produce a brief report.

It is common to substitute up and down for north and south when speaking informally, but it is also important to know when you've taken the substitution too far. One student's report on Pierce County began with the following sentence:

Pierce County is at the bottom of Puget Sound.

Attack of the rogue feature: Oh no, where did my Explorer icon labels go?

A customer reported that on Windows Vista, if you hold down the shift key and repeatedly click the View button in the command bar of an Explorer window, you will eventually reach a state where all the labels under the icons have disappeared! Where did they go, and how do I get them back?

Congratulations, you stumbled across a rogue feature.

One of the developers who worked on Windows XP decided to add a cute shortcut: Holding down the shift key when switching to Thumbnail mode will cause the labels to disappear. (At least, that was the intent of the rogue feature, but it so happens that as a side effect, the hold the shift key to remove labels shortcut also takes effect during certain other operations, because the shift key test was made in a shared worker function.)

Great, now that they're gone, how do you get them back? The way to restore item labels in Windows XP was to repeat the operation and hold the shift key when switching into Thumbnail mode. But wait, Windows Vista doesn't have an explicit Thumbnail mode any more. Since the hold the shift key to hide the labels feature was a rogue feature, nobody knew that the Thumbnail menu item was secretly being overloaded as an escape hatch!

Okay, here's how you get the labels back: Right-click in the background of the folder and select Customize This folder. From the customization dialog, change the template to Pictures and Videos, then OK. Now go back to the Explorer folder window and right-click in the background of the folder a second time, then go to the View submenu. (Alternatively, type Alt+V.) There will be a new Hide File Names option: Uncheck it. (If it's already unchecked, then check it, and then uncheck it again.) If you want, you can go back and uncustomize the folder so it has the All files template again.

The customer support people are probably relieved to learn that this rogue feature no longer exists in Windows 7.

More musings on the peculiar linguistic status of languages acquired in childhood

As I noted yesterday, languages which I acquired as a child occupy a different part of my brain from languages I acquired as an adult. If you speak to me in a childhood-acquired language, the information goes directly into my brain via some sort of low-level connection, and I barely even recognize what language it is you're speaking. On the other hand, if you speak to me in a language I acquired as an adult, it requires a conscious effort to process the information. (I don't have to translate what you speak before I can understand it, but the act of understanding requires a bit more effort.)

I got to experience this phenomenon with my Chinese-speaking nieces. If you spent time in their home, you'll hear three languages spoken. The adults speak to each other in their local Chinese dialect, they speak with the children in the regional Chinese dialect, and of course there's English. (The adults also speak Mandarin Chinese but you don't hear it often in the house.)

Since none of the Chinese dialects I know overlap with the dialects spoken by the children, my conversations with the nieces are in English. Over time, I started learning the regional dialect, and whenever possible, I would use it when speaking with the children. (I.e., when what I wanted to say had nonzero intersection with what I knew how to say.)

But even when I spoke with the nieces in Chinese, they always responded in English.

One day, I asked one of the nieces a simple question in Chinese, something like "Do you want to drink some water?" She looked at me and said, "大姑丈講中文!" I give her sentence in the original Chinese because it is ambiguous. I interpreted it to mean, "Uncle, speak Chinese!" And I was confused, because, well, I was speaking Chinese.

It was later explained to me that my niece meant the other interpretation of the sentence, which is "Uncle is speaking Chinese!" In other words, she was expressing surprise that I was speaking Chinese. I'd been doing this for months, but this was the first time she noticed.

Command line parsers look at what you typed, not what what you typed looks like

Command line parsers are stricter than human beings. The computer cares about what you typed. If you type something else that superficially resembles what you want, but is not actually what you want, then you won't get what you want, even though it sure looks like what you want.

I covered a special case of this topic earlier when I described smart quotes as the hidden scourge of text meant for computer consumption. You think you typed a quotation mark, but the editor secretly "improves" it from U+0022 to U+201C. Then you paste the text into a command line and you get strange output because the command line parser uses U+0022 as the quotation mark, not characters like U+201C which physically resemble U+0022 but aren't. A human being would say, "Yeah, that's a quotation mark, we'll let it slide." A command line parser knows what it wants and accepts no substitutes.

Even though my original examples are for command line use, the principle applies elsewhere, and I'm going to use CSS selectors as my example, because the command line programs used in my original examples are internal Microsoft tools, and explaining their command line syntax would distract from the message. On the other hand, everybody can look up CSS selector syntax. (There is an opportunity for a snarky comment here, but I'm going to withhold the pre-emptive snarky comment in the hopes that my readers are mature enough to not go for the cheap drive-by insult. I am almost always disappointed by the result, but I try again every so often to see if the environment has changed.)

Here is an imaginary question/answer session inspired by actual events:

From: Xxxx Xxxxx

How do I make a CSS rule apply only to elements with a specific tag and a specific class? Specifically, I want a rule to apply only to elements of the form <SPAN CLASS="Name">.

From: Yyyyy Yyyyyy

You use SPAN.Name.

From: Xxxx Xxxxx

I tried that, but it doesn't work.

SPAN. Name { color: red; }

This person became one of those people who are not interested in why something works but are only interested in the magic phrase they need to type. Whether or not you believe that the "just tell me what to type" mindset is acceptable, you have to concede that if you choose to adopt that mindset, you need to actually type what people tell you to type.

In this case, the person decided that the punctuation rules for CSS are the same as the punctuation rules for English, and since English allows (and even encourages) a space after a period, then CSS should also allow it. "I mean, it looks so much better on the screen with a space after the period." (I bet these are the same people who move cities around on a map in order to produce a more visually-pleasing arrangement.)

Or maybe the person decided that the punctuation rules for CSS were the same as C++. C++ allows spaces on either side of the field selector operator. If C++ allows it, then so too should CSS.

Of course, neither case is true. CSS has its own rules for parsing, and in CSS, spaces are significant.

What I found even more mind-boggling was another question/answer session. I'm going to use the same question and answer for illustrative purposes, but in reality, the question was different.

From: Wwww Wwwww

How do I make a CSS rule apply only to elements with a specific tag and a specific class? Specifically, I want a rule to apply only to elements of the form <SPAN CLASS="Name">.

From: Yyyyy Yyyyyy

You use SPAN.Name.

From: Wwww Wwwww

I tried that, but it doesn't work.

.Name SPAN { color: red; }

I don't know what possessed this second person to take the instructions and then scramble the pieces on the assumption that, hey, the order of the pieces of the selector aren't important, as long as they're all there, right?

If somebody speaks a language I'm not expecting, sometimes I don't understand it, even though I should

During my visit to Göteborg, I booked a city tour on a tour bus. As I noted earlier, the tour is trilingual. Each point of interest is described by the tour guide three times, first in Swedish, then in English, and then in German. (Even the jokes are the same. You can tell which people on the bus speak which language by checking when they laugh at the jokes.)

I didn't know this when I got on the tour bus. I was simply expecting that the tour would be conducted in Swedish. After all, I'm in Sweden. They speak Swedish here.

The tour started, and the tour guide started by speaking in Swedish, which I sort of understood. Not great, but I got the basic idea.

And then she repeated herself in English. That was a pleasant surprise. Now I could fill in the parts that I missed from the Swedish narration.

Next, she spoke in German, but remember, I didn't know that the tour was trilingual. I just assumed she was returning to Swedish for the next part of the narration, so I thought to myself, "Wow, my Swedish suddenly sucks! I was doing so well and then boom, it's all gone!"

And then I realized, "Oh wait, that's not Swedish. That's German. I can understand this after all."

This is one of those weird language things I've noticed. The languages I learned as a child are kept in one part of my brain, and the languages I acquired as an adult go into another part. When people speak to me in a language I acquired as an adult, I don't even understand them until I first figure out what language they're using. On the other hand, the languages I acquired as a child I can understand immediately. (You can even switch languages in the middle of a sentence and I might not even notice.)

A 32-bit application can allocate more than 4GB of memory, and you don't need 64-bit Windows to do it

Commenter Herb wondered how a 32-bit program running on 64-bit Windows scan allocate more than 4GB of memory. Easy: The same way it allocates more than 4GB of memory on 32-bit Windows!

Over a year before Herb asked the question, I had already answered it in the tediously boring two-week series on the myths surrounding the /3GB switch. Here's a page that shows how you can allocate more than 2GB of memory by using shared memory (which Win32 confusingly calls file mappings). That code fragment allocated 4GB of memory at one go, and then accessed it in pieces (because a 32-bit program can't map an entire 4GB memory block at one go). To allocate more, either make the number bigger in the call to CreateFileMapping or just call CreateFileMapping multiple times.

The following week, I talked about how you can use AWE to allocate physical pages. Again, you can allocate as much memory as you like, but if you allocate enormous amounts of memory, you will probably not be able to map them all in at once.

The claims of the program are true, but 64-bit Windows wasn't necessary for the program to accomplish what it claims. It's like Dumbo and the magic feather. "Dumbo can fly with the magic feather in his trunk." Well, yeah, but he didn't actually need the feather.

(On the other hand, 64-bit Windows certainly makes it more convenient to use more than 4GB of memory, since you can map the memory into your address space all at once and use normal pointers to access it.)

The most unwanted song ever

A follow-up to why ABBA songs are so catchy: Vitaly Komar, Alex Melamid, and David Soldier developed a song scientifically engineered to be the most unwanted song ever: By their calculations, "fewer than 200 individuals of the world's total population would enjoy this piece."

Ah, opera rap.

Also check out The Most Wanted Paintings. America's Most Wanted Painting contains "an autumnal landscape with wild animals, a family enjoying the outdoors, the color blue, and George Washington."

Why does my screen go black when an emergency hibernation is in progress?

Sometime last year a customer wanted to know why the screen goes black when the system automatically hibernates due to critically low battery power. Shouldn't there be some sort of feedback to tell the user, "Hey, like, I'm hibernating, don't worry"?

The power management folks explained that they turn off the screen for a reason: They're trying to save your data while they still can. When the system gets the "Oh no, the battery is about to die!" notification from the hardware, there's no time to lose, and even less power to waste. Keeping the screen lit takes a lot of power, so turning it off might make the difference between a successful hibernation and loss of data.

Mind you, this doesn't all happen without fair warning. Before the battery goes critical, you will get a low battery warning balloon saying "Oh dear, things are getting pretty bad, you really should wrap things up before I'm forced to stop the car!"

It so happens that this particular customer had a system with a buggy BIOS that fails to notify the operating system of changes in power level with sufficient granularity. The power level went from "okay" straight to "critical" with no steps in between. As a result, Windows doesn't find out about the low battery level until it's already at critically low levels.

Note

Observe that I wrote "The power management folks explained". I am not the expert here; I'm repeating what I've heard in the interest of getting information out. Unfortunately, it looks like the the Windows Mobile PC Team Blog has gone dark, so it's not clear to me where you can ask your questions. (There is a more general site on Microsoft and the Environment, however.)

Foreign languages can be used to impede communication

One of the reasons people give for studying a foreign language is to increase the number of people one can communicate with. But what people don't mention is that foreign languages can also be used to impede communications, and that can be just as useful. (Be careful, though, because it can backfire.)

During my visit to Sweden some years ago, I was walking back to my hotel room from the Göteborg train station. I had spent the afternoon visiting the nearby city of Alingsås, whose claim to fame is that they are the birthplace of the man who introduced potatoes to Sweden, although he is probably more greatly celebrated for introducing a related process to Sweden: the technique of fermenting potatoes to make alcohol. Anyway, the reason I was there was not to learn the history of potatoes in Sweden, but rather to pay a visit to one of my Swedish readers.

Oh, wait, I was telling a story. I was walking back to my hotel from the train station, and as I crossed one of the plazas, a man approached me, speaking unaccented American English. He said, "Hey, you look Chinese. We have an organization for Chinese people, and the meetings are conducted in Swedish so you can understand!"

Okay, let's see if we can add up everything wrong with this situation.

1. We're in Sweden, and I "look Chinese", so he decides to speak to me in English?
2. He's speaking English in order to convince me to attend a meeting conducted in Swedish.
3. If I'm Chinese, wouldn't "the language I can understand" be, um, say, some variation of Chinese?

I didn't feel like pointing this out to the gentleman. I just wanted to get back to my hotel, but he kept following me, repeating his spiel. I stopped and mentally enumerated the languages I knew how to speak.

• English: Obviously he knows English. He's speaking it.
• Swedish: We're in Sweden. There's a chance he knows Swedish.
• German: Göteborg gets a lot of German tourists. The tourism signs and tour buses are trilingual: Swedish, English, and German. So there's a chance he knows German.
• Chinese: Seeing as he's assuming that I'm a native Chinese speaker, yet he's speaking to me in English, it's a pretty safe bet that he doesn't speak Chinese. Especially if I pick a minority dialect.

I turned to him and said in my parents' native dialect, "I'm sorry, I don't know what you're saying."

He was apparently not expecting this, because he paused for a moment before saying "Oh, Thai people are welcome, too." I guess he took what I said and tried to map the phonemes to English and somehow came to the conclusion that I said, "I'm not Chinese; I'm Thai."

I merely reiterated my claim not to understand what he was saying and continued onward. He decided not to follow me any further.

I use this technique whenever I don't want to talk to somebody. And the trick works both ways: In Taiwan, when people try to talk to me and I'd rather not deal with them, I speak Swedish.

You can use a Coke slogan as your password, but not a Pepsi one

When Larry Osterman mentioned News Flash: Spaces are legal characters in both filenames and passwords, I was reminded of my own little experiment with passwords and spaces.

Over a decade ago, I tried using spaces in my password, and they were accepted, but I ran into a different problem: Brand name bias.

The password system accepted "Coke adds life" as my password, but it rejected "Pepsi the choice of a new generation". Why did the password system accept a Coke slogan but not a Pepsi one? Hint.

The New York Times says I'm doing it all wrong, but maybe that's for the better

Some time ago, The New York Times ran a story titled In Web World of 24/7 Stress, Writers Blog Till They Drop, which mentions that "those on the lower rungs of the business can earn as little as $10 a post."

Dude, if that's what people on the lower rungs earn, then I'm below ground level! (Nevermind that just the previous month, an article in The New York Times wrote about the business of blogging: Don't expect to get rich.)

Then again, I probably shouldn't complain, seeing as what most people took away from the article was that blogging kills.

Slate's Timothy Noah noted in his article Death by Blogging that the New York Times article employs a magic phrase which, once it appears, is a signal to the reader that the subject matter of the story is completely made up:

Give Richtel credit for admitting high up in the story that what follows is purest fancy. Newspaper reporters call these caveat-rich passages "to-be-sure grafs."

The "to-be-sure" paragraph appears as paragraph number six:

To be sure, there is no official diagnosis of death by blogging, and the premature demise of two people obviously does not qualify as an epidemic. There is also no certainty that the stress of the work contributed to their deaths. But...

It opens with the magic phrase that says "What you are reading in the remainder of this article is complete fantasy," then adds a few more statements saying that "None of what this article says is true." And then, as if to say, "Let's not let facts get in the way of a good story," it immediately resumes the fabrication with a "But..."