• The Old New Thing

    Microspeak: Tell Mode / Ask Mode


    As a product nears release, the rate of change slows down, and along the way, the ship room goes through stages known as Tell Mode and Ask Mode.

    In Tell Mode, any changes to the product do not require prior approval, but you are required to present your changes to the next ship room meeting and be prepared to explain and defend them. The purpose of this exercise is to get teams accustomed to the idea of having to present their changes to the ship room as a warm-up for Ask Mode. There is also the psychological aspect: If you have to present and defend your changes, you are going to be more careful about deciding which changes to make, how you will go about making them, and how thoroughly you're going to validate those changes. For example, if a bug could be fixed by applying a targeted fix or by rewriting the entire class, you are probably not going to choose to rewrite. (In theory, the ship room may reject your changes after the fact, and then you have to go back them out. But this is rare in practice. The ship room usually lets you off with a warning unless your transgression was particularly severe.)

    The next stage of scrutiny is known as Ask Mode. In this stage, any proposed changes to the product must be presented to the ship room before they can be submitted. Rejection is more frequent here. Time has passed and the bug bar has gone up, and because it is easier to get forgiveness than permission.

    Here is a more detailed explanation of how one team implements the two modes.

    Note that there can be multiple levels of ship room. There may be a local feature team ship room, then a group-wide ship room, then a product-wide ship room, and it is not uncommon for each ship room to be in a different mode. For example, the local feature team ship room may be in Ask Mode, the group-wide ship room is in Tell Mode, and the product-wide ship room isn't looking at individual bugs yet. This means that when you want to make a change, you need to get permission from your local feature team, and then after you commit the change, you need to get forgiveness from the group ship room.

  • The Old New Thing

    Why are only some of the Windows 7 system notification icons colorless?


    André decided to play "gotcha" by noting that not all of the notification icons went colorless and wondered what the criteria was for deciding which ones to make colorless and which ones to make colorful.

    It's very simple: The design team generated colorless versions of the most commonly-seen notification icons. They didn't have the time to generate colorless versions of all notification icons, so they focused on the ones that gave them the most benefit.

    This is the standard tradeoff you have to make whenever you have finite resources. Eventually the marginal benefit of redrawing one more icon exceeds its marginal cost, at which point you stop. The marginal cost is measured not only in actual resources (designers can redraw only so many icons per day, and you have money to hire only so many designers) but also in opportunity cost (time spent redrawing icons to be colorless is time not spent on other design tasks).

    This is the same reason that not all icons in Windows XP were given the full-color perspective-view treatment. For example, nearly all of the icons in the Administrative Tools section are the old Windows 2000-style 16-color flat (or isometric) icons. The design team focused on the 100ish most commonly used icons and went to the effort of redrawing them in the Windows XP style. The more rarely-used icons were left in the old style because the cost of converting them did not merit the benefit.

    The same thing happened in Windows Vista, when the icon design changed yet again. The style became less stylized and more realistic, but not quite photorealistic, and the angle of presentation changed. The design team had the resources to convert the most commonly used icons, and the rest were left as they were.

    It's the Pareto Principle again. If you have finite resources (and who doesn't) you may find that you can get 80% of the benefit by doing only 20% of the work. And that leaves 80% of your capacity available to address some other problem.

  • The Old New Thing

    Communication between moving vehicles during the narrow window of the late 1990s


    The long holiday weekend in the United States means that there are probably going to be a lot of people on road trips.

    Back in the old days before mobile phones, if you had multiple cars traveling together on a long trip, you had to stay within visible range of each other so that you didn't get separated. And if the car at the end of the convoy needed to pull over to take a bathroom break or something, they needed to rush to the front of the group and pantomime through the window to the passengers in the lead car to tell them what they were going to do, and then everybody would pull over together.

    I still remember those days.

    Of course, nowadays, you'd just whip out your mobile phone and call the other people in the group. "Hey, we need to stop for a bathroom break. You can join us, or we'll just catch up with you down the road."

    There was a narrow window of a few years where WiFi hardware was generally available, if somewhat expensive (in the form of a PCMCIA PC Card for your laptop and a $1000 base station)¹ and mobile phone coverage along highways in less populated areas was spotty or nonexistent. That was the window of time during which I wrote a chat program for multi-car road trips.

    The idea was that we would establish an ad-hoc wireless network among the laptops, and the program would act as a peer-to-peer instant messaging program. We would be the world's fastest-moving WiFi hotspot. As long as the cars stayed within around 100 meters of each other, we would (presumably) still have connectivity. The program was robust to outages, and it could handle devices dynamically coming into or leaving communication range.

    With this technological contraption, we didn't have to make everybody stop and pull over in order to decide where to have lunch. We could just start an IM conversation and work it out while still moving. (But if we wanted to take a bathroom break, everybody had to stop; otherwise the cars would get out of range.)

    I over-engineered this program, designing it to handle chats that if printed out would require a roll of paper over 300 kilometers long. In other words, for a 300km trip, you would have to be sending instant messages fast enough that you could drive on the paper coming out of the printer. (Related.) Another way of doing the math was observing that the program could in theory handle a cross-country trip where people were sending 500 messages per second the entire time. (Well, except it would have run out of memory long before hitting its design limits.)

    This program met an even sadder fate than my in-car mp3 player. At least I got to use that program a few times. Mobile phone technology quickly improved to the point where the car chat program was no longer necessary. It was never used at all!

    ¹ I still have my $1000 base station packed in a box somewhere. I wouldn't be surprised if my my mobile phone now has a faster data plan than that thing.

  • The Old New Thing

    It rather involved being on the other side of this airtight hatchway: Surreptitious file access by administrator


    A security report was received that went something like this:

    A user can bypass file sharing locks by opening a read-only handle to the physical volume containing the file in question. This allows the user to extract the contents of protected files by reading the corresponding sectors directly from the disk. Since this operation requires administrator access, any user with administrator access can extract data from files that are normally inaccessible due to file locks, such as the SAM database.

    Yes, that's right. An attacker who gains administrator privileges can extract data from any file on the computer.

    But so what? The attacker is already on the other side of the airtight hatchway. They already pwn your machine. That a pwned machine can be pwned is not really all that surprising.

    That some files are not accessible due to file locks is not a security measure. It is a consequence of, um, file access.

    Besides, once you gain administrator access, a much easier way to steal the SAM is to merely grab a backup copy.

    What, you can't find a backup copy?

    No problem.

    After all, you're the administrator. One of your job responsibilities is to maintain regular system backups.

    So create a backup of the SAM file. Of course the system will let you do this. It is your job after all.

    For example, you can use the Volume Shadow Service to create a volume snapshot, then mount the snapshot and extract the SAM file.

    Bingo, instant copy of the SAM database.

    Just doing your job.

  • The Old New Thing

    2014 mid-year link clearance


    Another round of the semi-annual link clearance.

    James Mickens section

    January 2014: This World of Ours

    I have seen a video called “Gigantic Martian Insect Party,” and I have seen another video called “Gigantic Martian Insect Party 2: Don’t Tell Mom,” and I hated both videos, but this did not stop me from directing the sequel “Gigantic Martian Insect Party Into Darkness.”

    March 2014: To Wash It All Away

    Clearing the cache to fix a Web browser is like when your dad was driving you to kindergarten, and the car started to smoke, and he tried to fix the car by banging on the hood three times and then asking you if you could still smell the carbon monoxide, and you said, “Yeah, its better,” because you didn’t want to expose your dad as a fraud, and then both of you rode to school in silence as you struggled to remain conscious.

    And a recorded presentation: Computers are a Sadness, I am the Cure, which is hilarious because it's true, especially his final security recommendation.

  • The Old New Thing

    Why did it take so long for Windows to support a taskbar on more than one monitor?


    Mark wants to know why Windows has never supported having a taskbar on more than one monitor. (The question was asked before Windows 8 multi-monitor taskbar support became publically-known.)

    The feature has always been on the list, but it's a long list, and specifically the cost of designing, implementing, testing, performing usability tests, then redesigning the feature (because you will definitely need to redesign something as significant as this at least once) historically prevented it from escaping the minus-100-point deficit.

    Features do not exist in a vacuum, and decisions about features necessarily take into account the other features under consideration. For a feature to be adopted, it not only must be valuable enough in itself, but it almost must provide a better cost/benefit ratio than any other features under consideration. While the benefit of a multi-monitor taskbar is high, you have to scale it down by the percentage of users who would be able to take advantage of such a feature. I don't know the exact numbers, but I would hazard that fewer than ten percent of users use a multiple-monitor system on a regular basis, so any benefit would have to be ten times as great as the benefit of features that have broader use.

    On top of that, the development cost of a multiple-monitor taskbar is significantly higher than most other taskbar features. Just the compatibility constraints alone make you shudder. (Think about all the programs that do a Find­Window looking for the taskbar and assuming that there is only one.)

    What changed in Windows 8 that made a multiple-monitor taskbar a feature worth implementing? I don't know, but I can guess. First of all, the overall engineering budget for the taskbar may have been raised, so that more features from the list can make the cut. Or maybe the people in charge of the taskbar decided to go with their gut and ignore the numbers, implementing a feature specifically targetting the enthusiast community even though the work would not be justified if you went strictly by the cost/benefit analysis. By doing this, they ended up short-changing other features which were perhaps more worthy if you looked at the numbers.

    And then you'd be asking, "Why didn't you do feature Y? I mean, it would have been far more useful to far more people than the multiple-monitor taskbar."

    (Of course, now that I mentioned Windows 8, everybody will treat this as open season to post their complaints here.)

  • The Old New Thing

    As long as your file names meet operating system requirements, you can use whatever you like; the rest is up to you


    A customer had a question about the MSDN documentation on rules for legal file names:

    My employees keep naming documents with hyphens in the name. For example, they might name a file Budget-2012-Final.xlsx. It is my position that hyphens should not be used in this way, and the document should be named Budget 2012 Final.xlsx. Please advise on the use of hyphens within file names.

    Hyphens inside file names are legal, and you can use as many as you like, subject to the other rules for file names.

    If you are having an argument with your employees about file naming conventions, that's something you just need to work out among yourselves. Whatever you decide, the file system will be there for you.

  • The Old New Thing

    It rather involved being on the other side of this airtight hatchway: Denial of service by high CPU usage


    We received the following security vulnerability report:

    Windows is vulnerable to a denial of service attack that consumes 100% CPU.

    1. Use the following procedure to create a file that is enchanted by magic pixie dust: [...]
    2. Rename the file to TEST.EXE.
    3. Execute as many copies of the program as you have CPU cores.

    Observe that CPU usage climbs to 100% and never goes down. This a clear demonstration that Windows is vulnerable to a denial of service attack from magic pixie dust.

    The magic pixie dust is a red herring. This vulnerability report is basically saying "If you are allowed to run arbitrary programs, then it is possible to run a program that consumes all the available CPU."

    Well, duh.

    This is another case of if I can run an arbitrary program, then I can do arbitrary things, also known as MS07-052: Code execution results in code execution. (Or in the lingo of Internet memes, "High CPU is high.")

    Now, of course, if the magic pixie dust somehow allows a user to do things like access resources they do not have access to, or to circumvent resource usage quotas, then there would be a serious problem here, and if if the high CPU usage could be triggered remotely, then there is a potential for a denial-of-service attack. But there was nothing of the sort. Here's a much less complicated version of magic pixie dust:

    int __cdecl main(int, char **) { for (;;) { } /*NOTREACHED*/ }
  • The Old New Thing

    Cargo-cult registry settings and the people who swear by them


    Two customers (so far) wanted to know how to increase the duration of taskbar balloon notifications on Windows Vista. (By the way, I gave the answer some time ago.)

    They claimed that on Windows XP, they were using the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\Current­Version\Explorer\Tray­Notify, setting the value Balloon­Tip to a REG_DWORD specifying the number of seconds the balloon should appear. They wanted to know if this still worked in Vista.

    Heck, it didn't work even in Windows XP!

    That undocumented registry key actually controls whether the Windows XP taskbar should show the "To see the hidden icons, click this button" tip. It has nothing to do with how long the balloon stays on the screen.

    A quick Web search suggests that that particular setting has reached cult status, with everybody saying that the setting controls balloon duration, and nobody actually testing it. It's just a matter of faith.

    Even the sometimes-suggested trick of putting the registry key name in MSDN so searches can find it and direct users to the correct method wouldn't have helped, because this was the wrong registry key to begin with.

    (Remember, the answer is in the linked article.)

  • The Old New Thing

    Only senior executives can send email to the All Employees distribution list, but mistakes still happen


    Some time ago, a senior executive sent email to the All Employees distribution list at Microsoft announcing that a particular product was now available for dogfood. The message included a brief introduction to the product and instructions on how to install it.

    A few hours later, a second message appeared in reply to the announcement. The second message came from a different senior executive, and it went

    I got your note and tried it out. Looks good so far.

    Oopsie. The second senior executive intended to reply just to the first senior executive, but hit the Reply All button by mistake. This would normally have been caught by the You do not have permission to send mail to All Employees rule, but since the mistake was made by a senior executive, that rule did not apply, and the message went out to the entire company.

    People got a good chuckle out of this. At least he didn't say anything embarrassing.

    Bonus chatter: I'd have thought that these extra-large distribution lists would be marked Nobody can send to this distribution list, and then when somebody needed to send a message to the entire company, the email admins would create a one-day-only rule which allowed a specific individual to send one message.

Page 1 of 93 (922 items) 12345»