In Microspeak, fit is a predicate noun which is never used on its own but always comes with a modifying adjective. For something to be a good fit is for something to be appropriate or suitable for a particular situation. The opposite of a good fit is not a bad fit, because that's pejorative. Rather, something that is not a good fit is referred to as a poor fit.

The purpose of a previewer plug-in is to allow users to view the media without opening it. An image editing tool would not be a good fit for the previewing feature. (Alternatively, "would be a poor fit for the previewing feature.")

To be a good fit with a particular group is to mesh well with that group's existing practices and conventions.

The Datacenter Edition of the product is a poor fit for most small businesses.

The group in question need not consist of people.

The results are obtained incrementally, which makes it a good fit for IQueryable<T> and LINQ.

Microsoft Human Resources loves to apply the concept of "fit" to people fitting into a job position.

matushorvath was curious about the WINA20.386 file that came with some versions of MS-DOS.

The WINA20.386 file predates my involvement, but I was able to find some information on the Internet that explained what it was for. And it's right there in KB article Q68655: Windows 3.0 Enhanced Mode Requires WINA20.386:

Windows 3.0 Enhanced Mode Requires WINA20.386

Windows 3.0 enhanced mode uses a modular architecture based on what are called virtual device drivers, or VxDs. VxDs allow pieces of Windows to be replaced to add additional functionality. WINA20.386 is such a VxD. (VxDs could be called "structured" patches for Windows.)

Windows 3.0 enhanced mode considers the state of the A20 line to be the same in all MS-DOS virtual machines (VMs). When MS-DOS is loaded in the high memory area (HMA), this can cause the machine to stop responding (hang) because of MS-DOS controlling the A20 line. If one VM is running inside the MS-DOS kernel (in the HMA) and Windows task switches to another VM in which MS-DOS turns off A20, the machine hangs when switching back to the VM that is currently attempting to execute code in the HMA.

WINA20.386 changes the way Windows 3.0 enhanced mode handles the A20 line so that Windows treats the A20 status as local to each VM, instead of global to all VMs. This corrects the problem.

(At the time I wrote this, a certain popular Web search engine kicks up as the top hit for the exact phrase "Windows 3.0 Enhanced Mode Requires WINA20.386" a spam site that copies KB articles in order to drive traffic. Meanwhile, the actual KB article doesn't show up in the search results. Fortunately, Bing got it right.)

That explanation is clearly written for a technical audience with deep knowledge of MS-DOS, Windows, and the High Memory Area. matushorvath suggested that "a more detailed explanation could be interesting." I don't know if it's interesting; to me, it's actually quite boring. But here goes.

The A20 line is a signal on the address bus that specifies the contents of bit 20 of the linear address of memory being accessed. If you aren't familiar with the significance of the A20 line, this Wikipedia article provides the necessary background.

The High Memory Area is a 64KB-sized block of memory (really, 64KB minus 16 bytes) that becomes accessible when the CPU is in 8086 mode but the A20 line is enabled. To free up conventional memory, large portions of MS-DOS relocate themselves into the HMA. When a program calls into MS-DOS, it really calls into a stub which enables the A20 line, calls the real function in the HMA, and then disables the A20 line before returning to the program. (The value of the HMA was discovered by my colleague who also discovered the fastest way to get out of virtual-8086 mode.)

The issue is that by default, Windows treats all MS-DOS device drivers and MS-DOS itself as global. A change in one virtual machine affects all virtual machines. This is done for compatibility reasons; after all, those old 16-bit device drivers assume that they are running on a single-tasking operating system. If you were to run a separate copy of each driver in each virtual machine, each copy would try to talk to the same physical device, and bad things would happen because each copy assumed it was the only code that communicated with that device.

Suppose MS-DOS device drivers were treated as local to each virtual machine. Suppose you had a device driver that controlled a traffic signal, and as we all know, one of the cardinal rules of traffic signals is that you never show green in both directions. The device driver has two variables: NorthSouthColor and EastWestColor, and initially both are set to Red. The copy of the device driver running in the first virtual machine decides to let traffic flow in the north/south direction, and it executes code like this:

if (EastWestColor != Red) {
 SetEastWestColor(Red);
}
SetNorthSouthColor(Green);

Since both variables are initially set to Red, this code sets the north/south lights to green.

Meanwhile, the copy of the device driver in the second virtual machine wants to let traffic flow in the east/west direction:

if (NorthSouthColor != Red) {
 SetNorthSouthColor(Red);
}
SetEastWestColor(Green);

Since we have a separate copy of the device driver in each virtual machine, the changes made in the first virtual machine do not affect the values in the second virtual machine. The second virtual machine sees that both variables are set to Red, so it merely sets the east/west color to green.

On the other hand, both of these device drivers are unwittingly controlling the same physical traffic light, and it just got told to set the lights in both directions to Green.

Oops.

Okay, so Windows defaults drivers to global. That way, you don't run into the double-bookkeeping problem. But this causes problems for the code which manages the A20 line:

Consider a system with two virtual machines. The first one calls into MS-DOS. The MS-DOS dispatcher enables the A20 line and calls the real function, but before the function returns, the virtual machine gets pre-empted. The second virtual machine now runs, and it too calls into MS-DOS. The MS-DOS dispatcher in the second virtual machine enables the A20 line and calls into the real function, and after the function returns, the second virtual machine disables the A20 line and returns to its caller. The second virtual machine now gets pre-empted, and the first virtual machine resumes execution. Oops: It tries to resume execution in the HMA, but the HMA is no longer there because the second virtual machine disabled the A20 line!

The WINA20.386 driver teaches Windows that the state of the A20 should be treated as a per-virtual-machine state rather than a global state. With this new information, the above scenario does not run into a problem because the changes to the A20 line made by one virtual machine have no effect on the A20 line in another virtual machine.

matushorvath goes on to add, "I would be very interested in how Windows 3.0 found and loaded this file. It seems to me there must have been some magic happening, e.g. DOS somehow forcing the driver to be loaded by Windows."

Yup, that's what happened, and there's nothing secret about it. When Windows starts up, it broadcasts an interrupt. TSRs and device drivers can listen for this interrupt and respond by specifying that Windows should load a custom driver or request that certain ranges of data should be treated as per-virtual-machine state rather than global state (known to the Windows virtual machine manager as instance data). MS-DOS itself listens for this interrupt, and when Windows sends out the "Does anybody have any special requests?" broadcast, MS-DOS responds, "Yeah, please load this WINA20.386 driver."

So there you have it, the story of WINA20.386. Interesting or boring?

A customer reported an incompatibility in Windows 7: If A: is a floppy drive and they call Load­Library("A:\\foo.dll") and there is no disk in the drive, the Load­Library call fails with the error ERROR_NOT_READY. Previous versions of Windows failed with the error ERROR_MOD_NOT_FOUND.

Both error codes are reasonable responses to the situation. "The module couldn't be found because the drive is not ready." Programs should treat a failed Load­Library as a failed library load and shouldn't be sensitive to the precise reason for the error. (They can display a more specific error to the user based on the error code, but overall program logic shouldn't depend on the error code.)

Fortunately, the customer discovered this discrepancy during their pre-release testing and were able to accommodate this change in their program before ever releasing it. A sigh of relief from the application compatibility team.

Episode 1.

It's often the case that when a question from a customer gets filtered through a customer liaison, some context gets lost. (I'm giving the customer the benefit of the doubt here and assuming that it's the customer liaison that removed the context rather than the customer who never provided it.) Consider the following request:

We would like to know more information about the method the shell uses to resolve shortcuts.

This is kind of a vague question. It's like asking "I'd like to know more about the anti-lock braking system in my car." There are any number of pieces of information that could be provided about the anti-lock braking system.

• "It requires a Class C data bus."
• "The tire position sensors are on the wheel-axis."
• "It is connected to the brakes."
• "It is shiny."

When we ask the customer, "Could you be more specific what type of information you are looking for?" the response is sometimes

We want to know everything.

This is not a helpful clarification. Do they want to start with Maxwell's Equations and build up from there?

As it happened, in the case of wanting more information about the method the shell uses to resolve shortcuts, they just wanted to know how to disable the search-based algorithm.

This sort of "ask for everything and figure it out later" phenomenon is quite common. I remember another customer who wanted to know "everything" about changing network passwords, and they wouldn't be any more specific than that, so we said, "Well, you can start with these documents, perhaps paying particular attention to this one, but if they tell us what they are going to be doing with the information, we can help steer them to the specific parts that will be most useful to them."

As it turned out, all the customer really wanted to know was "When users change their password, is the new password encrypted on the wire?"

Third example, and then I'll stop. Another customer wanted to know everything about how Explorer takes information from the file system and displays it in an Explorer window. After asking a series of questions, we eventually figured out that they in fact didn't want or need a walkthrough of the entire code path that puts results in the Explorer window. The customer simply wanted to know why two specific folders show up in their Explorer window with names that didn't match the file system name.

When you ask for more information, explain what you need the information for, or at least be more specific what kind of "more information" you need. That way, you save everybody lots of time. The people answering your question don't waste their time gathering information you don't need (and gathering that information can be quite time-consuming), and you don't waste your time sifting through all the information you don't want.

You might say that these people are employing the for-if anti-pattern:

foreach (document d in GetAllPossibleDocumentation())
{
 if (d.Topic == "password encryption on the wire") return d;
}

A customer liaison reported that their customer wants to be able to access their machine without needing a password. They just want to be able to net use * \\machine\share and be able to access the files right away. I guess because passwords are confusing, easy to forget, and just get in the way. Anyway, the customer discovered that they could do so on Windows XP by going to the folder they want to share, going to the Sharing tab, then clicking on the If you understand the security risks but want to share files without running the wizard link,

and then on the Enable File Sharing dialog, clicking Just enable file sharing.

What the customer wanted to know was if there was a way they could automate this process.

My response to the customer liaison went like this:

Your customer has chosen to ignore not one but two security warnings. Furthermore, since they are looking for an automated way of doing this, it sounds like they intend on deploying this "feature" to all the computers in their organization. Maybe they just enjoy being part of a botnet? Your customer is basically saying "I wish my computer to have no network security." They should at least restrict access to authenticated users. But if they if they insist on having their corporate network turned into a spam farm, they can enable the Guest account and say that it can "Access this computer from the network." Congratulations, your computers will soon be filled with malware and porn.

That last sentence made it into some people's quotes file.

While wasting time doing valuable background research on my computer, I received the following suggestion:

For enchanced video quality, click here.

It's good to know that the typo that I first encountered in 1993 is still alive and kicking.

(And even though it's not important to the story, people will demand some sort of follow-up, so here it is: I submitted feedback to the vendor, who said that it was a known issue fixed in the next update.)

Amit was curious why it takes longer for Task Manager to appear when you start it from the Ctrl+Alt+Del dialog compared to launching it from the taskbar.

Well, you can see the reason right there on the screen: You're launching it the long way around.

If you launch Task Manager from the taskbar, Explorer just launches taskmgr.exe via the usual Create­Process mechanism, and Task Manager launches under the same credentials on the same desktop.

On the other hand, when you use the secure attention sequence, the winlogon program receives the notification, switches to the secure desktop, and displays the Ctrl+Alt+Del dialog. When you select Task Manager from that dialog, it then has to launch taskmgr.exe, but it can't use the normal Create­Process because it's on the wrong desktop and it's running under the wrong security context. (Because winlogon runs as SYSTEM, as Task Manager will tell you.)

Clearly, in order to get Task Manager running on your desktop with your credentials, winlogon needs to change its security context, change desktops, and then launch taskmgr.exe. The desktop switch is probably the slowest part, since it involves the video driver, and video drivers are not known for their blazingly fast mode changes.

It's like asking why an international package takes longer to deliver than a domestic one. Because it's starting from further away, and it also has to go through customs.

A customer designed a system which uses shared memory. Specifically, for each database file, they create a corresponding shared memory block of, say, 200MB. Multiple clients which connect to the same database file use the same shared memory block. Naturally, if two processes each access the same database file, each process will map the shared memory block into their respective address space. The question arose regarding what happens if one process connects to the same database file twice. Will the two calls to Map­View­Of­File share the same address space, or will each one allocate a separate chunk of address space?

Win32 makes no guarantees what will happen. All that you can be sure of is that the memory will be mapped into your address space, and you will get a pointer to it, and when you're done, you call Unmap­View­Of­File. Whether the two calls return the same pointer is unspecified.

In fact, Windows 95 returned the same pointer, whereas Windows NT returns a different pointer. We saw this earlier when we intentionally mapped the same shared memory block multiple times, and observed somebody actually taking a dependency on this behavior in order to effect the strangest way of detecting Windows NT. Don't take a dependency on this behavior; who knows, maybe a future version of Windows NT will consolidate multiple mappings in order to conserve address space.

If you want force this consolidation behavior, you'll have to roll it yourself, say with a lookup table of active mappings and a reference count.

Every year, I put together a little pocket guide to the Seattle Symphony subscription season for my symphony friends to help them decide which ticket package they want. As before, you might find it helpful, you might not, but either way, you're going to have to suffer through it. Here's the at-a-glance season guide for the 2012/2013 season. (Full brochure. Seattle Times coverage.)

Legend:

For those not familiar with the Seattle Symphony ticket package line-ups: Most of the ticket packages are named Masterworks nX where n is the number is the number of concerts in the package, and the letter indicates which variation. Ticket packages have been combined if they are identical save for the day of the week. For example, 7C and 7D are the same concerts; the only difference is that 7C is for Thursday nights, while 7D is for Saturday nights. The Beyond the Score concerts focus on only one of the pieces. The WolfGang series is available only to members of the WolfGang club.

This chart doesn't include "one-off" concert series such as the Mainly Mozart or Distinguished Artists series. A "one-off" series is a concert series which shares no concerts with any other series.

Changes from last season:

• The Rush Hour series was redesigned and became the Symphony Untuxed series.
• Symphony Specials was dropped.
• The Baroque & Wine Series and Mainly Mozart concerts still exist, but I dropped them from the table since they are now one-off series.
• WolfGang already existed but I added it to the list now that there's room for it.

The comments column very crudely categorizes the works to assist my less-classically-aware friends. This is, of course, a highly subjective rating system, but I tried to view each piece from the ears of my symphony friends. Thus, I rated downward pieces that I personally like but which others might not and rated up pieces that I may not find musically satisfying but which nevertheless tend to be crowd-pleasers.

These predictions have, of course, proven wrong in the past.

Here's what the comments mean. Note that they do not indicate whether the piece is significant in a musicological sense; they're just my guess as to whether my friends are going to like it. (For example, I know that my friends don't like minimalism, and I suspect they don't like serialism, so I rated the Adams and Berg down even though I think they're quite good. They also don't like vocal pieces. On the other hand, it turns out that I overcame my Bruckner jinx, so I can at least give the Bruckner a positive score this time. Let's just hope it's not the Hass edition.)

• Awesome: Guaranteed crowd-pleaser.
• Excellent: You will definitely like this piece.
• Good: You will probably like this piece.
• Okay: You may like this piece.
• Nervous: I have a bad feeling about this one.
• Polarizing: Some people will love it; others will hate it.
• Wildcard: I have no idea what will happen.

In many cases, I am not familiar with the piece and am basing my evaluation on what I know about the composer (or am just guessing).

You may have noticed a minor inconsistency between pinning a program to the Start menu and pinning a destination to a program's Jump List. Although pinned items appear at the top of the respective lists, and both the Start menu and Jump List let you right-click an item and select Pin/Unpin, the Jump List also lets you pin and unpin an item by clicking on the pushpin. Why doesn't the Start menu have a pushpin in addition to the right-click menu?

For a time, items on the Start menu did have a pushpin, just like items on Jump Lists. The design had a few problems, however. Start menu items can also have a triangle indicating the presence of a flyout menu, and the presence of two indicators next to an item made the interface look awkward and too busy. And what do you do if an item has only one indicator? Do you right-justify all the indicators? Or do you place the indicators in columns and reserve blank space for the missing ones?

Both look ugly for different reasons. The right-justify-everything version looks ugly because the pushpin appears to keep moving around. The blank-space-if-no-flyout version looks ugly because you have a pushpin hovering in the middle of nowhere. (Imagine trying to click on one of these things: You just have to "know" that the magic click spot for pinning an item is 20 pixels to the left of the far right edge.)

But the real death blow to showing a pushpin for pinning items to the Start menu was the usability testing. Users had trouble figuring out where to click to pin an item or to open the Jump List and frequently got the opposite of what they wanted. Since opening the Jump List is by far the more common operation, it won the battle of the prominent UI affordance, and the option for pinning and unpinning was left to a context menu.

Which, as it happens, is where the pin/unpin option started in the first place.