September, 2005

  • The Old New Thing

    Windows Server 2003 can take you back in time


    If you are running Windows Server 2003, you owe it to yourself to enable the Volume Shadow Copy service. What this service does is periodically (according to a schedule you set) capture a snapshot of the files you specify so they can be recovered later. The copies are lazy: If a file doesn't change between snapshots, a new copy isn't made. Up to 64 versions of a file can be recorded in the snapshot database. Bear this in mind when setting your snapshot schedule. If you take a snapshot twice a day, you're good for a month, but if you take a snapshot every minute, you get only an hour's worth of snapshots. You are trading off snapshot quality against quantity.

    Although I can count on my hand the number of times the Volume Shadow Copy service has saved my bacon, each time I needed it, it saved me at least a day's work. Typically, it's because I wasn't paying attention and deleted the wrong file. Once it was because I make some changes to a file and ended up making a bigger mess of things and would have been better off just returning to the version I had the previous day.

    I just click on "View previous versions of this folder" in the Tasks Pane, pick the snapshot from yesterday, and drag yesterday's version of the file to my desktop. Then I can take that file and compare it to the version I have now and reconcile the changes. In the case of a deleted file, I just click the "Restore" button and back to life it comes. (Be careful about using "Restore" for a file that still exists, however, because that will overwrite the current version with the snapshot version.)

    One tricky bit about viewing snapshots is that it works only on network drives. If you want to restore a file from a local hard drive, you'll need to either connect to the drive from another computer or (what I do) create a loopback connection and restore it via the loopback.

    Note that the Volume Shadow Copy service is not a replacement for backups. The shadow copies are kept on the drive itself, so if you lose the drive, you lose the shadow copies too.

    Given the ability of the Volume Shadow Copy service to go back in time and recover previous versions of a file, you're probably not surprised that the code name for the feature was "Timewarp".

    John, a colleague in security, points out that shadow copies provide a curious backdoor to the quota system. Although you have access to shadow copies of your file, they do not count against your quota. Counting them against your quota would be unfair since it is the system that created these files, not you. (Of course, this isn't a very useful way to circumvent quota, because the system will also delete shadow copies whenever it feels the urge.)

  • The Old New Thing

    Understanding the consequences of WAIT_ABANDONED


    One of the important distinctions between mutexes and the other synchronization objects is that mutexes have owners. If the thread that owns a mutex exits without releasing the mutex, the mutex is automatically released on the thread's behalf.

    But if this happens, you're in big trouble.

    One thing many people gloss over is the WAIT_ABANDONED return value from the synchronization functions such as WaitForSingleObject. They typically treat this as a successful wait, because it does mean that the object was obtained, but it also tells you that the previous owner left the mutex abandoned and that the system had to release it on the owner's behalf.

    Why are you in big trouble when this happens?

    Presumably, you created that mutex to protect multiple threads from accessing a shared object while it is an unstable state. Code enters the mutex, then starts manipulating the object, temporarily making it unstable, but eventually restabilizing it and then releasing the mutex so that the next person can access the object.

    For example, you might have code that manages an anchored doubly-linked list in shared memory that goes like this:

    void MyClass::ReverseList()
     WaitForSingleObject(hMutex, INFINITE);
     int i = 0; // anchor
     do {
      int next = m_items[i].m_next;
      m_items[i].m_next = m_items[i].m_prev;
      m_items[i].m_prev = next;
      i = next;
     } while (i != 0);

    There is nothing particularly exciting going on. Basic stuff, right?

    But what if the program crashes while holding the mutex? (If you believe that your programs are bug-free, consider the possiblity that the program is running over the network and the network goes down, leading to an in-page exception. Or simply that the user went to Task Manager and terminated your program while this function is running.)

    In that case, the mutex is automatically released by the operating system, leaving the linked list in a corrupted state. The next program to claim the mutex will receive WAIT_ABANDONED as the status code. If you ignore that status code, you end up operating on a corrupted linked list. Depending on how that linked list is used, it may result in a resource leak or the system creating an unintended second copy of something, or perhaps even a crash. The unfortunate demise of one program causes other programs to start behaving strangely.

    Then again, the question remains, "What do you do, then, if you get WAIT_ABANDONED?" The answer is, "Good question."

    You might try to repair the corruption, if you keep enough auxiliary information around to recover a consistent state. You might even design your data structures to be transactional, so that the death of a thread manipulating the data structures does not leave them in a corrupted state. Or you might just decide that since things are corrupted, you should throw away everything and start over, losing the state of work in progress, but at least allowing new work to proceed unhindered.

    Or you might simply choose to ignore the error and continue onwards with a corrupt data structure, hoping that whatever went wrong won't result in cascade failures down the line. This is what most people do, though usually without even being aware that they're doing it. And it's really hard to debug the crashes that result from this approach.

    Exercise: Why did we use indices instead of pointers in our linked list data structure?

    [Raymond is currently away; this message was pre-recorded.]

  • The Old New Thing

    Reading the output of a command from batch


    The FOR command has become the batch language's looping construct. If you ask for help via FOR /? you can see all the ways it has become overloaded. For example, you can read the output of a command by using the for command.

    FOR /F "tokens=*" %i IN ('ver') DO echo %i

    The /F switch in conjunction with the single quotation marks indicates that the quoted string is a command to run, whose output is then to be parsed and returned in the specified variable (or variables). The option "tokens=*" says that the entire line should be collected. There are several other options that control the parsing, which I leave you to read on your own.

    The kludgy batch language gets even kludgier. Why is the batch language such a grammatical mess? Backwards compatibility.

    Any change to the batch language cannot break compatibility with the millions of batch programs already in existence. Such batch files are burned onto millions of CDs (you'd be surprised how many commercial programs use batch files, particularly as part of their installation process). They're also run by corporations around the world to get their day-to-day work done. Plus of course the batch files written by people like you and me to do a wide variety of things. Any change to the batch language must keep these batch files running.

    Of course, one could invent a brand new batch language, let's call it Batch² for the sake of discussion, and thereby be rid of the backwards compatibility constraints. But with that decision come different obstacles.

    Suppose you have a 500-line batch file and you want to add one little feature to it, but that new feature is available only in Batch². Does this mean that you have to do a complete rewrite of your batch program into Batch²? Your company spent years tweaking this batch file over the years. (And by "tweaking" I might mean "turning into a plate of spaghetti".) Do you want to take the risk of introducing who-knows-how-many bugs and breaking various obscure features as part of the rewrite into Batch²?

    Suppose you decide to bite the bullet and rewrite. Oh, but Batch² is available only in more recent versions of Windows. Do you tell your customers, "We don't support the older versions of Windows any more"? Or do you bite another bullet and say, "We support only versions of Windows that have Batch²"?

    I'm not saying that it won't happen. (In fact, I'm under the impression that there are already efforts to design a new command console language with an entirely new grammar. Said effort might even be presenting at the PDC in a few days.) I'm just explaining why the classic batch language is such a mess. Welcome to evolution.

    [Raymond is currently away; this message was pre-recorded.]

  • The Old New Thing

    Spider Solitaire unseats the reigning champion


    A few months ago, the usability research team summarized some statistics they had been collecting on the subject of what people spend most of their time doing on the computer at home. Not surprisingly, surfing the Internet was number one. Number two was playing games, and in particular, I found it notable that the number one game is no longer Klondike Solitaire (known to most Windows users as just plain "Solitaire").

    That title now belongs to Spider Solitaire. The top three games (Spider Solitaire, Klondike Solitaire, and Freecell) together account for more than half of all game-playing time.

    Personally, I'm a Freecell player.

    Exercise: Why aren't games like Unreal Tournament or The Sims in the top three?

  • The Old New Thing

    Precision is not the same as accuracy


    Accuracy is how close you are to the correct answer; precision is how much resolution you have for that answer.

    Suppose you ask me, "What time is it?"

    I look up at the sun, consider for a moment, and reply, "It is 10:35am and 22.131 seconds."

    I gave you a very precise answer, but not a very accurate one.

    Meanwhile, you look at your watch, one of those fashionable watches with notches only at 3, 6, 9 and 12. You furrow your brow briefly and decide, "It is around 10:05." Your answer is more accurate than mine, though less precise.

    Now let's apply that distinction to some of the time-related functions in Windows.

    The GetTickCount function has a precision of one millisecond, but its accuracy is typically much worse, dependent on your timer tick rate, typically 10ms to 55ms. The GetSystemTimeAsFileTime function looks even more impressive with its 100-nanosecond precision, but its accuracy is not necessarily any better than that of GetTickCount.

    If you're looking for high accuracy, then you'd be better off playing around with the QueryPerformanceCounter function. You have to make some tradeoffs, however. For one, the precision of the result is variable; you need to call the QueryPerformanceFrequency function to see what the precision is. Another tradeoff is that the higher accuracy of QueryPerformanceCounter can be slower to obtain.

    What QueryPerformanceCounter actually does is up to the HAL (with some help from ACPI). The performance folks tell me that, in the worst case, you might get it from the rollover interrupt on the programmable interrupt timer. This in turn may require a PCI transaction, which is not exactly the fastest thing in the world. It's better than GetTickCount, but it's not going to win any speed contests. In the best case, the HAL may conclude that the RDTSC counter runs at a constant frequency, so it uses that instead. Things are particularly exciting on multiprocessor machines, where you also have to make sure that the values returned from RDTSC on each processor are consistent with each other! And then, for good measure, throw in a handful of workarounds for known buggy hardware.

  • The Old New Thing

    The double-Ctrl+Alt+Del feature is really a kludge


    Most people who care about such things know that you can press Ctrl+Alt+Del twice from the Welcome screen and sometimes you will get a classic logon dialog. (Note: "Sometimes". It works only if the last operation was a restart or log-off, for complicated reasons that are irrelevant to this discussion.)

    The ability to do the double-Ctrl+Alt+Del was added as a fallback just in case there turned out to be some important logon scenario that the new Welcome screen failed to cover, but which the designers had failed to take into account by simple oversight. Scenarios such as smartcard or fingerprint logon.

    In other words, it's a kludge.

    In the time since Windows XP came out, the logon folks have kept an eye out to see if there indeed were any scenarios that weren't covered by the Welcome screen. I think the only one that came up was Kerberos authentication.

    Now that (once they fix the Kerberos problem) they have covered all the bases, the designers are probably going to feel more confident about the new logon design, and the double-Ctrl+Alt+Del panic button will likely be removed.

    So don't get too attached to it.

    This is why the Welcome screen shows that Administrator account if there are no other members of the Administrators group on the system: If it didn't show the Administrator account, you would be locked out of your own computer.

    "No I'm not. I can use the double-Ctrl+Alt+Del trick to log on as the Administrator."

    Well, okay, that works today, but you're relying on a panic button that might not be there tomorrow.

    [Raymond is currently away; this message was pre-recorded.]

  • The Old New Thing

    Why is there no all-encompassing superset version of Windows?


    Sometimes, I am asked why there is no single version of Windows that contains everything. Instead, as you move up the ladder, say, from Windows XP Professional to Windows Server 2003, you gain server features and lose workstation features. Why lose features when you add others?

    Because it turns out no actual customer wants to keep the workstation features on their servers. Only developers want to have this "all-encompassing" version of Windows, and making it available to them would result in developers testing their programs on a version of Windows no actual customer owns.

    I think one of my colleagues who works in security support explained it best:

    When customers ask why their server has Internet Explorer, NetMeeting, Media Player, Games, Instant Messenger, etc., installed by default, it's hard for the support folks to come up with a good answer. Many customers view each additional installed component as additional risk, and want their servers to have the least possible amount of stuff installed.

    If you're the CIO of a bank, the thought that your servers are capable of playing Quake must give you the heebie-jeebies.

    [Raymond is currently away; this message was pre-recorded.]

  • The Old New Thing

    Ten things I noticed at the 2005 PDC


    Supplementing Sara Ford's PDC trip report: Some of my own stories and observations from the PDC.

    1. Tip: If you're designing a hotel, don't put big noisy fountains right next to the check-in desk. Turns out that if you do that, conversation between a guest and the desk staff becomes rather difficult. Eventually, guests get tired of asking the staff to repeat everything they say and just nod politely.

    2. Tip: Go ahead, walk from the hotel to the convention center in the morning. It's good exercise, and goodness knows you need some exercise after all that food you've been eating. And who knows, you might run into a Dane named Mads [fix misspelling, 10am] and end up comparing the Swedish, Danish, and German languages for fifteen minutes, and be reassured by said Dane that Danish pronunciation isn't as difficult it sounds. Hey, it could happen.

    3. Observation: At the hip revolving cocktail lounge at the top of the hotel, there are two types of people. There are the cool people. And there are the nerds who are in town for a technology conference. You, my friend, are one of the nerds. (And you also would have computed that the lounge performs one turn in approximately 75 minutes.)

    4. Tip: When you're waiting for the elevator to arrive, don't peek through the crack in the doors if the elevator is external. You will see the sky and get all creeped out.

    5. Tip: If there is a police officer on a motorcycle waiting at a stoplight, don't jaywalk right in front of him. It turns out he'll notice and write you a ticket. (Actually, he might just let you off with a warning, but why chance it? Drivers in Los Angeles are crazy. He's stopping you for your own safety. Fortunately, I did not have to learn this lesson first-hand.)

    6. Observation: I'm sorry, I don't care how yummy it is. A fountain of chocolate is just plain wrong.

    7. Observation: They say the camera adds ten pounds. What they didn't say is that it also makes your left hand look all withered and deformed. In speaker training, they teach you to keep your hands up, closer to your face. That's why in all the pictures of Bill Gates giving a speech, his hands are at chest level or higher. I tried to keep my hands up, but my left hand tends to droop and turn into one of those claw things.

    8. Observation: Talking with customers for over eleven hours straight really wipes you out. It also gives you a sore throat (and I'm afraid I may have caught something but I'm doing a pretty good job of fighting it off so far).

    9. Bonus typo: At Ask the Experts, one of the sections was titled "Communcation".

    10. Tip: If you're going to go from the PDC straight to the airport, stuff an extra shirt in your day pack so you can change out of your PDC staff shirt and not wear it all the way back to Redmond. Because it turns out that if you wear a staff shirt outside the convention hall, you just look like a nerd. (See item 3.)

    I met up with Sara at closing time Friday since we coincidentally had the same flight out. Since the flight wasn't for a few hours, it was nice to have someone to chat with to pass the time. (And yet nobody took her up on her lunch date offer. What, were you scared of her? Really, she's a very nice person.)

    Boarding for our flight was announced and we waited our turn on the Jetway®. After a few minutes, an agent wormed her way through the line and headed for the plane. It was then that we realized, "Hey, this line hasn't moved for a long time. I wonder what's going on."

    Another few minutes later, a police officer walked down the hall and onto the plane.

    Everybody moved to the walls, clearing a path down the center. Because when a police officer gets on the plane, you know he's coming back off one way or another, and it's not going to be pretty. (It's not like the flight crew ask for a police officer because they would like him to sing a song.)

    Some time later, a second police officer got on the plane. And then two more airport employees. Everybody waiting in line was trying to guess what was going on.

    Eventually, a middle-aged gentleman walked calmly off the plane, followed by the two police officers and the airport employees. As the last of the airport employees went past, someone in the line asked, "What happened?"

    The airport employee didn't break stride and just said, "Idiot."

    As we got on board, everybody was trying to figure out what happened. I was seated next to two gentlemen who didn't know either; the disruption was at the back of the plane. Sara did a pretty good job of fact-finding and the story (fourth-hand by now) was that the gentleman had a ticket for a later flight but tried to muscle his way into a seat and became rather unpleasant when the flight crew asked him to leave. When the police showed up, he immediately backed down, realizing that the jig was up, and went quietly.

    There were, of course, no seats available on any earlier flights. Los Angeles to Seattle the afternoon after the Microsoft PDC, tickets are going to be scarce. Probably half the people on the flight were Microsoft staff returning home. This gentleman's effort to get home two hours earlier made an entire planeful of people late by ten minutes. And I suspect he's going to have a hard time buying a ticket from that airline for a while...

  • The Old New Thing

    But I have Visual Basic Professional


    Back in 1995, I was participating in a chat room on MSN on the subject of device driver development. One of the people in the chat room asked, "Can I write a device driver in Visual Basic?"

    I replied, "Windows 95 device drivers are typically written in low-level languages such as C or even assembly language."

    Undaunted, the person clarified: "But I have Visual Basic Professional."

  • The Old New Thing

    Giving fair warning before plugging in your computer


    That colleague who gave me the AOL CD that came with a big-iron server later received a prototype Itanium computer for testing purposes. The early Itaniums were behemoths. They weighed a ton, sounded like a weed whacker, and put out enough heat to keep you comfortably warm through the winter. (If you opened them up, you would likely see several carefully-shaped Styrofoam blocks with the label "Do not remove! Engineering styrofoam!" I never thought I would ever see the phrase "engineering styrofoam" used seriously. Note: Styrofoam® is a registered trademark of the Dow Chemical Company; consequently, it should be capitalized. The generic term is "foamed polystyrene". Mind you, the Dow Chemical Company also claims to have trademarked the color Blue [see **].)

    Never one to read all the safety labels before playing with a new toy, my colleague took the heavy-duty double-capacity power cables and ran them to the normal wall socket. Then he threw the power switch.

    And the power went out in the entire building wing.

    The power surge from the Itanium overloaded the poor wall socket and tripped the wing's circuit breaker. Everybody went through the standard power outage drill, while speculating amongst themselves what the cause for this one might be.

    It didn't take long for word to get out. "Fred plugged in his Itanium." (Not his real name.)

    After the electricians came by to check that everything was okay, they reset the circuit breaker and everybody got back to work.

    My colleague re-cabled the machine to be more friendly to the building's power circuitry. Then he sent out email to the entire team.

    "I'm turning it on!"

    Everbody laughed.

    And then hit Ctrl+S just in case.

Page 1 of 4 (39 items) 1234