When you think it couldn't get any harder, it gets easier

by Michael S. Kaplan, published on 2006/08/29 04:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/08/29/729476.aspx


From the prophet Douglas Adams:

Click, hum.

The huge grey Grebulon reconnaissance ship moved silently through the black void. It was travelling at fabulous, breath-taking speed, yet appeared, against the glimmering background of a billion distant stars to be moving not at all. It was just one dark speck frozen against an infinite granularity of brilliant night.

On board the ship, everything was as it had been for millennia, deeply dark and silent.

Click, hum.

At least, almost everything.

Click, click, hum.

Click, hum, click, hum, click, hum.

Click, click, click, click, click, hum.

Hmmm.

A low level supervising program woke up a slightly higher level supervising program deep in the ship's semi-somnolent cyberbrain and reported to it that whenever it went click all it got was a hum.

The higher level supervising program asked it what it was supposed to get, and the low level supervising program said that it couldn't remember exactly, but thought it was probably more of a sort of distant satisfied sigh, wasn't it? It didn't know what this hum was. Click, hum, click, hum. That was all it was getting.

The higher level supervising program considered this and didn't like it. It asked the low level supervising program what exactly it was supervising and the low level supervising program said it couldn't remember that either, just that it was something that was meant to go click, sigh every ten years or so, which usually happened without fail. It had tried to consult its error look-up table but couldn't find it, which was why it had alerted the higher level supervising program to the problem .

The higher level supervising program went to consult one of its own look-up tables to find out what the low level supervising
program was meant to be supervising.

It couldn't find the look-up table .

Odd.

It looked again. All it got was an error message. It tried to look up the error message in its error message look-up table and couldn't find that either. It allowed a couple of nanoseconds to go by while it went through all this again. Then it woke up its sector function supervisor.

The sector function supervisor hit immediate problems. It called its supervising agent which hit problems too. Within a few
millionths of a second virtual circuits that had lain dormant, some for years, some for centuries, were flaring into life throughout the ship. Something, somewhere, had gone terribly wrong, but none of the supervising programs could tell what it was. At every level, vital instructions were missing, and the instructions about what to do in the event of discovering that vital instructions were missing, were also missing.

Small modules of software - agents - surged through the logical pathways, grouping, consulting, re-grouping. They quickly
established that the ship's memory, all the way back to its central mission module, was in tatters. No amount of interrogation could determine what it was that had happened. Even the central mission module itself seemed to be damaged.

This made the whole problem very simple to deal with. Replace the central mission module. There was another one, a backup, an exact duplicate of the original. It had to be physically replaced because, for safety reasons, there was no link whatsoever between the original and its backup. Once the central mission module was replaced it could itself supervise the reconstruction of the rest of the system in every detail, and all would be well.

Robots were instructed to bring the backup central mission module from the shielded strong room, where they guarded it, to the ship's logic chamber for installation. 

This involved the lengthy exchange of emergency codes and protocols as the robots interrogated the agents as to the authenticity of the instructions. At last the robots were satisfied that all procedures were correct. They unpacked the backup central mission module from its storage housing, carried it out of the storage chamber, fell out of the ship and went spinning off into the void.

This provided the first major clue as to what it was that was wrong.

Further investigation quickly established what it was that had happened. A meteorite had knocked a large hole in the ship. The ship had not previously detected this because the meteorite had neatly knocked out that part of the ship's processing equipment which was supposed to detect if the ship had been hit by a meteorite.

The first thing to do was to try to seal up the hole. This turned out to be impossible, because the ship's sensors couldn't see that there was a hole, and the supervisors which should have said that the sensors weren't working properly weren't working properly and kept saying that the sensors were fine. The ship could only deduce the existence of the hole from the fact that the robots had clearly fallen out of it, taking its spare brain, which would have enabled it to see the hole, with them.

You may be wondering why I shared this 'Mostly Harnless' excerpt. I'll try and see if I can point out the relevance of dealing with a problem where the information you need is not directly available, and you can only find what you need through inference....

Remember back in March when I posted Getting all you can out of a keyboard layout, Part #9a?

In part of that post I talked about the fact that MapVirtuaKey[Ex] did not distinguish keys such as the left and right CONTROL keys, or the left and right ALT keys, since their scan codes differed only by an extended bit and MapVirtuaKey[Ex] strips out the extra bits.

And without explicitly mentioning how lame it was, I talked about how to work around this problem.... using indirect methods.

Now you might think that this blog represents such a powerful force at Microsoft that the mere suggestion of such a limitation inspired action at the highest levels and that the developer who owns the code was asked to immediately address the issue.

Of course, you'd be mistaken. Utterly mistaken.

Luckily, there was another Windows component that had the same requirement, and there was a developer who was slightly less warped than me who did not realize there was that odd, indirect way to get at the info.

And that request led to new functionality of MapVirtuaKey[Ex] -- an extension to two of the existing flags, a whole new flag, and constants to cover the flag values so you don't have to pass a bunch of numbers.

The update info that will make its way into the Platform SDK eventually (after a scrub by the doc. writer of course!):

0      MAPVK_VK_TO_VSC
uCode is a virtual-key code and is translated into a scan code. If it is a virtual-key code that does not distinguish between left- and right-hand keys, the left-hand scan code is returned. If there is no translation, the function returns 0.

1      MAPVK_VSC_TO_VK
uCode is a scan code and is translated into a virtual-key code that does not distinguish between left- and right-hand keys. If there is no translation, the function returns 0.
Windows Vista: the high byte of uCode can contain 0xe0 or 0xe1 extended scan code prefix to specify the extended scan code.

2      MAPVK_VK_TO_CHAR
uCode is a virtual-key code and is translated into an unshifted character value in the low order word of the return value. Dead keys (diacritics) are indicated by setting the top bit of the return value. If there is no translation, the function returns 0.

3      MAPVK_VSC_TO_VK_EX
Windows NT/2000/XP: uCode is a scan code and is translated into a virtual-key code that distinguishes between left- and right-hand keys. If there is no translation, the function returns 0.
Windows Vista: the high byte of uCode can contain 0xe0 or 0xe1 extended scan code prefix to specify the extended scan code.

4      MAPVK_VK_TO_VSC_EX
Windows Vista: uCode is a virtual key code and is translated into a scan code. If it is a virtual-key code that does not distinguish between left- and right-hand keys, the left-hand scan code is returned. If there is not translation, the function returns 0. If the scan code is an extended scan code, the high byte is the extend prefix (either 0xe0 or 0xe1).

Now if I were a lesser person I might have started a rumor about the VP who read my blog and intervened to get the feature in, but honestly I am just so happy that it is there that I see no need to make up any stories about it. :-)

It does mean that I might need to do a new part to that series to cover the things that are now easier to do in Vista, of course. But I can't remember the last time I was afraid to do a blog post....

 

This post brought to you by ܞ (U+071e, a.k.a. SYRIAC LETTER YUDH HE)


# RubenP on 29 Aug 2006 3:51 PM:

Just love Douglas Adams. A prophet indeed :-)

referenced by

2008/02/02 [Confusing functionality] + [New features] = [Documentation that can be confusing]

2007/01/04 Converting a project to Unicode: Part 8 (Fitting MSLU into the mix)

2006/09/14 Why doesn't MSKLC have a numeric keypad?

go to newer or older post, or back to index or month or day