October, 2005

  • The Old New Thing

    The undeletable Outlook folder

    • 35 Comments

    For a while, I've had a few "undeletable Outlook folders". Even after deleting all the messages from them, Outlook just complains when I try to delete them. There was some sort of error message, but of course I didn't read it. The only option was OK, so I clicked it. As I recall, the message said something about "Can't delete because blah blah pending synchronization blah blah." I don't know what "pending synchronization" is, but it must be important if Outlook won't let me delete a folder because of it.

    Meanwhile, I also noticed that my Sync Issues folder grew by about a dozen error messages every day, and I had to go clean them out every so often. The messages looked something like this:

    9:26:59 Synchronizer Version 11.0.6352
    9:26:59 Synchronizing Mailbox 'Raymond Chen'
    9:26:59 Synchronizing local changes in folder '0618'
    9:26:59 Error synchronizing folder
    9:26:59		 [80004005-501-4B9-0]
    9:26:59		 The client operation failed.
    9:26:59		 Microsoft Exchange Server Information Store
    9:26:59		 For more information on this failure, click the URL below:
    9:26:59		 http://www.microsoft.com/support/prodredirect/outlook2000_us.asp?err=80004005-501-4b9-0
    9:27:00 Synchronizing local changes in folder '0611'
    9:27:00 Error synchronizing folder
    9:27:00		 [80004005-501-4B9-0]
    9:27:00		 The client operation failed.
    9:27:00		 Microsoft Exchange Server Information Store
    9:27:00		 For more information on this failure, click the URL below:
    9:27:00		 http://www.microsoft.com/support/prodredirect/outlook2000_us.asp?err=80004005-501-4b9-0
    9:27:01 Done
    

    I clicked the link to obtain further information, but the instructions there didn't solve my problem. I just chalked this up to "Outlook gets that way sometimes," and ignored the messages, since they didn't seem to be hurting me. I had almost resigned myself to carrying these two undeletable folders with me until I die.

    Then today I randomly stumbled across the solution.

    I right-clicked one of the "stuck" folders and selected "Clear Offline Items", even though there were no offline items in the folder. (I deleted all the messages from it; the folder was empty. How do you clear something that is empty?) I got a warning dialog that said something like, "Hey, there's some unfinished synchronization here, do you want to clear the items anyway?" I said, "Go for it."

    And then Outlook let me delete the folder.

    My guess is that Outlook's synchronization engine got wedged up on these two folders because there was some unfinished business that it just couldn't reconcile, and it said, "Eh, maybe it'll work tomorrow, but in the meantime, don't delete it yet. I'm still working on it." Repeat for several months, because tomorrow never comes. By telling Outlook, "Oh just give up already, trust me, I don't care any more," the synchronization engine released its objections to deleting the folder and let me finally wipe it out.

    If you have a mysteriously undeletable folder, you could try this, see if it helps.

    Update: I just hit the problem again. The error message is

    Outlook hat die Synchronisierung der lokalen Änderungen an Elementen in diesem Ordner noch nicht abgeschlossen. Der Order kann erst nach Abschluss der Synchronisierung mit dem Server gelöscht werden.

    Yes, I run Outlook in German. This translates to "Outlook has not yet completed the synchronization of local changes to items in this folder. The folder can only be deleted after completion of the synchronization with the server."

    This time, deleting the offline items wasn't good enough. Even though the Properties dialog says "Server folder contains: 0 items" and "Offline folder contains: 0 items", I nevertheless had to trigger a manual synchronization to reconfirm that zero equals zero before it would let me delete the folder.

    (Watch, people are now going to start sending me Outlook product support questions. Hey, I don't work on Outlook. I'm a hapless victim like you!)

  • The Old New Thing

    The history of the path separator in Japanese and Korean Windows

    • 10 Comments

    Why is the path separator on Japanese Windows the ¥ character? And why is it the ₩ character on Korean Windows? I've been prodding Michael Kaplan to delve into the history of this quirk, and he finally gave in to my repeated badgering. (Additional discussion on the Korean Won sign, the Japanese Yen sign, and currency symbols in general.)

  • The Old New Thing

    Thread affinity of user interface objects, part 5: Object clean-up

    • 23 Comments

    The window manager and GDI objects as a general rule will automatically destroy objects created by a process when that process terminates. (The window manager also destroys windows when their owner threads exit.) Note, however, that this is a safety net and not an excuse for you to leak resources in your own program with the attitude of "Oh, it doesn't matter, the window manager will clean it up for me eventually." Since it's a safety net, you shouldn't use it as your primary means of protection.

    For one thing, leaving junk behind to be cleaned up is just plain sloppy. It suggests that your program is too lazy (or stupid) to keep track of its own resources and has abdicated this to the safety net. It's like throwing your clothes on the floor because you know your mother will eventually come by to pick it up and put it away.

    For another thing, this clean-up happens inside the window manager and no other window manager activity will occur until the clean-up is complete. If you leaked hundreds or thousands of objects, the system will seem visually unresponsive because the window manager is busy. (The system is still running, though. Operations that do not rely on the user interface, such as computation-intensive operations or network activity will still proceed normally while the window manager is cleaning up.)

    Why didn't the window manager optimize the "massive clean-up" scenario? Because when you design a system, you focus on optimizing the case where people are using your system responsibly and in the manner intended. You don't want to reward the people who are abusing you. Imagine what kind of message you'd be sending if you designed the system so that people who abuse the system get better performance than people who follow the rules!

  • The Old New Thing

    Make money working at home in your pajamas, and it's completely legal!

    • 13 Comments

    Become a professional captioner.

  • The Old New Thing

    Thread affinity of user interface objects, part 4: GDI objects and other notes on affinity

    • 4 Comments

    GDI objects are much simpler. As a general rule, they all have process affinity: They can be used by any thread in the process that created them. If you use a GDI object from multiple threads, it is your responsibility to coordinate the object's use.

    Note that the window manager and GDI as a general rule keep their respective objects thread-safe. When I say that it is your responsibility to coordinate an object's use from multiple threads, I mean that you have to coordinate among your own threads if you're going to modify the object from one thread and read from it on another or modify it from two threads. For example, if one thread enumerates a menu while another is modifying it, the one doing the enumeration will get inconsistent results. Similarly, if two threads both try to change a menu item at the same time, the last writer will win.

    Next time, we wrap up with a discussion of clean-up.

  • The Old New Thing

    Newark Liberty International Airport Terminal A travel tips

    • 35 Comments

    The line for going through the security checkpoint at Terminal A of Newark Liberty International Airport splits into three lines after you get through the ID check. When you get to the decision point, they all look the same, but don't be fooled.

                 ID  / 3 ----------------------------------X
    >>>-----------|--  2 ------------------------X
               check \ 1 -------------X
    

    Take line 1. As you can see, it is a much shorter wait than the others.

    If you observe carefully as you get into line, you'll see that all the people in business suits are in line 1. That's because the business travelers know this secret and the tourists don't.

    The lines are uneven due to space constraints. In reality, the corridor looks more like this:

                 ID  / 3 -----------------------------------XXXXXXXXX---
    >>>-----------|--  2 ------------------------XXXXXXXXX  XXXXXXXXX 
               check \ 1 -------------XXXXXXXXX  XXXXXXXXX--------------
                                      XXXXXXXXX-------------------------
    

    (I still call it Newark International Airport, since that's the name it had when I lived in New Jersey.)

  • The Old New Thing

    Thread affinity of user interface objects, part 3: Menus, icons, cursors, and accelerator tables

    • 3 Comments

    The remaining user interface objects in common use are menus, icons, cursors, and accelerator tables.

    Menus do not have thread affinity. Any thread can use a menu. However, if two threads use a menu, it is the responsibility of those threads to coordinate among themselves how that menu will be used, so that one thread doesn't modify a menu while another is busy displaying it, for example. (More on this subject later.)

    Icons, cursors, and accelerator tables behave like menus. They do not have thread affinity. They are easier to manage than menus since they cannot be modified once created, so the only thing you have to worry about is not to use one after it has been destroyed.

    Next time, GDI objects and an expansion on the subject of thread safety.

  • The Old New Thing

    New blog on integrating Groove with Office

    • 25 Comments

    Andrew Wharton from Groove has started writing about integrating the team and its product with Office. His opening salvo sets the stage and hooked me in for what looks to be an interesting glimpse into life in another division at Microsoft. (Something that is as mysterious to me as it is to you.)

    In the early days of the Windows division, there was friction among the groups that were thrown together to form the project, because when your group is told to join forces with another group, your natural tendency is to treat the other group as "them". And of course "they" are dumber, slower, and less physically attractive than you are. That's why they're "they" and you're "us". "We" always make the right decisions and "they" always make the wrong ones.

    To remedy this situation, the powers that be established regular "Windows Integration Meetings" (also known as "WIMs"), wherein the disparate and mutually distrustful groups would get together and work out their differences. The medium for this process was, of course, beer and snacks.

    The "meetings" were a success. The groups began seeing each other as members of a team rather than adversaries. As the Windows division grew, these "Integration Meetings" welcomed new groups to the project and continued to serve their purpose of smoothing tensions among them.

    At some point, the "I" in "WIM" began to stand for "Informational" rather than "Integration", but that had no practical effect since people still call it the "WIM". Regardless of what the letter officially stands for, the "I" stands for "beer".

  • The Old New Thing

    Thread affinity of user interface objects, part 2: Device contexts

    • 9 Comments

    Last time, we discussed briefly the thread affinity rules that govern window handles.

    Device contexts (DCs) also have a certain degree of thread affinity. The thread that calls functions such as GetDC must also be the one that calls ReleaseDC, but as with window handles, during the lifetime of the DC, any thread can use it. If you choose to use a DC in a multi-threaded manner, it's your responsibility to coordinate the consumers of that device context so that only one thread uses it at a time. For example, to host windowless controls across multiple threads, the host obtains a DC on the host thread, then asks each control in sequence to draw itself into that DC. Only one control draws into the DC at a time, even if the control happens to be on a different thread.

    The thread affinity of DCs is much more subtle than that of window handles, because if you mess up and release a DC from the wrong thread, things will still seem to be running okay, but the window manager's internal bookkeeping will be messed up and you may get a bad DC from GetDC a little later down the line.

    Next time, the remaining user interface elements.

  • The Old New Thing

    The difficult balancing act between customization and supportability

    • 9 Comments

    My colleague Kam VedBrat (from who I shamelessly stole the pictures of thse high-DPI displays in my PDC talk) discusses the difficult balancing act between customization and supportability. (Part II.) Note that decisions on this subject also also impact compatibility: Windows Vista greatly expands the palette of objects covered by the visual style. Any visual styles designed for Windows XP need to be revised in order to cover those new Windows Vista elements. Whose reponsibility would it be to revise them?

Page 3 of 5 (41 items) 12345