April, 2010

The letters SQM originally stood for Service Quality Monitoring, but that doesn't really answer the question, "What is SQM?"

SQM is the internal code name for the technologies behind what is publically known as the Microsoft Customer Experience Improvement Program. This is a voluntary program that customers can opt into, which gathers information about Office (say), information such as which menu options you use most often, how often you undo an autocorrection, what types of "impossible" things the program had to recover from, which error messages you've been shown, and which file format converters you use. (That's a quick overview of the Customer Experience Improvement Program; click through to read more, including the privacy policy.)

To me, what raises this beyond just an internal code name to the level of Microspeak is that the term has become linguistically productive. In addition to the term SQM being used to refer to the technology itself, you can also find it used as a verb: "The information gets SQMmed once a month." "Can we SQM this data?"

The letters SQM are pronounced as if it were spelled squim, which happens also to be the pronunciation of the Washington town Sequim. Along with Enumclaw, Puyallup, and Tulalip, Sequim is a Washington place name which is used to distinguish the locals from the outsiders. I strongly suspect that whoever came up with the name SQM did so specifically as a tribute to the town best known for its annual lavender festival.

Bonus history: At some point, somebody decided that the letters SQM no longer stand for Service Quality Monitoring; they now stand for Software Quality Metrics. That this change occurred without anybody noticing proves that nobody really cares what the letters stand for in the first place. I've heard from multiple sources that the original name came from the MSN team.

Pre-emptive clever comment: Verbing weirds language.

Via the suggestion box, Aaron Lerch asks whether a non-administrator can retrieve/evaluate environment variables as they would appear for another user.

This falls into the category of asking for a security hole as a feature, specifically an information disclosure security hole, because you are extracting information from a user's private data which has security access controls that do not grant everybody access. Generally speaking, users have full access to their data, as does the operating system itself, but nobody else. Administrators can get access to the data by taking ownership and modifying the ACL or using security overrides like Se­Debug­Privilege, but that's the general idea. And certainly, unprivileged users don't have access to the data from other unprivileged users.

The way to get a user's initial environment variables is to call the Create­Environment­Block function, passing the token of the user you are interested in. Note that it's more than just scraping the registry, because you also have to take into account group policy objects and the possibility that the information in the registry is incorrect because it is a stale cached roaming profile.

A customer was having trouble with their shell namespace extension:

When we click the [+] button next to our shell namespace extension in the folder tree view, the tree view shows both files and folders, even though it's supposed to show only folders. Our IShell­Folder::Get­Attributes­Of does return the correct values for SFGAO_FOLDER (including it for the folders and omitting it for the non-folders). What are we doing wrong?

The tree view enumerates the children of a folder by calling IShell­Folder::Enum­Objects and passing the SHCONTF_FOLDERS flag while omitting the SHCONTF_NONFOLDERS flag. This means that it is only interested in enumerating child folders. Child non-folders should be excluded from the enumeration.

It so happens that the customer's shell namespace extension was not respecting the SHCONTF_FOLDERS and SHCONTF_NONFOLDERS flags; it always enumerated all objects regardless of what the caller requested.

Fixing the enumerator fixed the problem.

bhiggins asks about the mysterious function EnumClaw that existed in some versions of the Win32 documentation.

I went digging through the MSDN archives and was close to giving up and declaring the cause lost, but then I found it: A copy of the EnumClaw documentation.

EnumClaw

The EnumClaw function returns the child or the parent of the window whose HWND is passed in.

HWND EnumClaw(
  HWND hwndParent    // handle to parent window
);

Parameters

hwndParent

[in] Handle to the parent window.

Return Values

If the function succeeds, the return value is the HWND of the child of the hwndParent window. If the window has no child, the return value is the HWND of the parent of the hwndParent window.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

Requirements

  Windows NT/2000/XP: Included in Windows XP and Windows .NET Server.
  Windows 95/98/Me: Unsupported.
  Header: Declared in Winuser.h; include Windows.h.
  Library: Use User32.lib.

See Also

Windows Overview, Window Functions.

There was never a function called EnumClaw. This was a joke inserted by the documentation folks, a pun on the Washington city named Enumclaw. (The state of Washington has a lot of place names which come from Native American words. Other examples are Sequim, Puyallup, and Tulalip. At least Enumclaw is pronounced almost like it's spelled.)