August, 2007

  • The Old New Thing

    Probably the most expensive Harry Potter viewing I'll ever attend

    • 17 Comments

    Last week, I arranged to meet a friend downtown to see the latest Harry Potter movie. Traffic across the 520 bridge during the evening rush is always a disaster, so whenever I have to head into the city by myself after work, I usually take the bus, and today is no exception.

    It is a sunny day, which makes for pleasant weather but horrible traffic. For some reason, traffic is significantly worse on sunny days. Short version: The bus is running behind schedule, and it's caught up in downtown traffic, so I get off at an earlier stop than I planned and walk/run the rest of the way. It is during this stretch of "run to the next traffic light, cross if possible, else wait for the light" that my clip-on sunglasses must have fallen out of my pocket, because when I reach the theater, they are gone.

    And I didn't need to have run anyway, because my friend is late, and we miss the 6:40 showing. Fortunately, that is the only glitch in the day. We grab some dinner and catch the next show.

    A few days later, I stop by the eyeglasses store to order a replacement sunglasses clip. $85. That was one expensive Harry Potter movie.

    (By the way, I liked the movie.)

  • The Old New Thing

    It was not one of Explorer's design goals to provide a Turing-complete interface for bulk file renaming

    • 41 Comments

    Somebody wanted to append an extension to all files in a directory and couldn't find a way to do this type of bulk rename in Explorer. On the other hand, it's pretty simple from the command prompt:

    ren * *.ext
    

    The person then asked, "Can we get this and other multi-file operations added to Explorer?"

    • "There should be a way to rename a large number of files, appending .ext to the name of each file (for example changing x to x.ext)."
    • "There should be a way to rename a large number of files, changing ABC to XYZ in each name (for example changing Customer_ABC_History.doc to Customer_XYZ_History.doc)."
    • "There should be a way to rename a large number of files, swapping the first two words in each file name (for example changing Bob Smith.vcf to Smith, Bob.vcf)."
    • "There should be a way to rename a large number of files, naming each file after the date and time it was created (for example IMG_2150.JPG becomes Photo December 25, 2004 0735am.JPG)."
    • "There should be a way to rename a large number of files, inserting the word (Provisional) after the first word (for example changing Recommendations for Smith account.doc to Recommendations (Provisional) for Smith account.doc.)"
    • "There should be a way to rename a large number of files, changing the case of each file name (for example changing Recommendations for Smith account.doc to Recommendations For Smith Account.doc.)" (Note that the above case change is incorrect, but computers don't know that.)
    • "There should be a way to rename a large number of files, inserting the name of the album extracted from the mp3 metadata before the title (for example changing Tick Tock.mp3 to Beautiful Ride - Tick Tock.mp3.)"

    It was not one of Explorer's design goals to provide a Turing-complete interface for bulk file renaming. (Remember, you don't know what you do until you know what you don't do.)

    Explorer does an extremely simple type of bulk rename: Renumbering a group of files. If that doesn't suit your needs, you can use the command prompt.

    ren * *.ext
    

    Or you can write a batch file that does some editing before doing the rename.

    for %%i in (*.doc) do call :fancy %%i
    goto :eof
    :fancy
    set _=%1
    ren %_% %_:ABC=XYZ%
    

    You can generate a list of files to rename and then load it into your favorite editor to turn it into a batch file to execute.

    dir /b *.vcf > files.cmd
    vi files.cmd
    :%s/^\([^ ]*\) \([^ ]*\)\(.*\)/ren "\1 \2\3" "\2 \1\3"
    ZZ
    files
    

    Or you can write a program in your favorite language that does the most awesome-fancy renaming the world has ever seen.

  • The Old New Thing

    But now I'll never know which politician that alien backs for the next election

    • 13 Comments

    It has been reported that everybody's favorite mock tabloid The Weekly World News is ceasing publication. Seeing as this is The Weekly World News we're talking about, I'm not sure how much of this I'm going to believe, but people seem to be taking it at face value.

    I remember seeing a WWN article clipped out and posted on the door to a geology professor's office at XYZ college. The article's title was something like "Dinosaurs alive and well—on the moon!"* It was illustrated with a drawing of happy dinosaurs wandering around a tropical lunar paradise, and the article quoted "An XYZ geology professor" as having seen the dinosaurs through a telescope. (What's a geologist doing looking at the moon through a telescope?) This was a small college, so the professor figured he must have been the one.

    Nitpicker's corner

    *This story is from memory. I may have gotten details wrong. For example, the dinosaurs may have been on Mars, not the moon. The name of the college was probably not XYZ.

  • The Old New Thing

    What is the difference between the Folder and Directory (and other special) progids?

    • 23 Comments

    When you're installing your shell extension, you need to know which progid to hang it off of inside HKEY_CLASSES_ROOT. We'll start with the title question and then move on to other predefined (but perhaps not well-known) progids.

    • "Folder" is the progid for any shell folder. It could be a virtual folder (like Control Panel) or a file system folder (like C:\WINDOWS).
    • "Directory" is the progid for file system folders. This is a subset of "Folder".
    • "*" is the progid for all files. Doesn't matter what the extension is.
    • "." (that's a single period) is the progid for files without any extension.
    • "AllFileSystemObjects" is the union of "*" and "Directory". It is the progid for all files and for file system directories.
  • The Old New Thing

    Note to locals: Lincoln Center is in New York City, not Bellevue

    • 6 Comments

    In downtown Bellevue there is a mall named Lincoln Square, but I hear people refer to it with some frequency as Lincoln Center.

    Just a reminder: Lincoln Center is in New York City.

    Nitpicker's corner

    There are many other places in the world with the names Lincoln Square and Lincoln Center.

  • The Old New Thing

    Footnotes in Win32 history: VLM (Very Large Memory) support

    • 37 Comments

    A long-forgotten footnote in Win32 history is the set of functions known as "VLM" for "Very large Memory". To understand VLM, you first need to understand the Alpha AXP.

    The Alpha AXP was a wonderful architecture and I was sad to see it go. Partly because it meant that the years I spent learning the ins and outs of the processor were now just wasted space in my brain, good only for muttering incoherently during meetings and blog entries. Hang on a second...

    The Alpha AXP was a 64-bit processor. None of this "64-bit mode" versus "32-bit mode" that we have with the AMD64 and EM64T (and early versions of the Itanium). It was 64-bit all the time. Now, the instruction set did provide a few arithmetic instructions which operated on 32-bit values, but the results were always sign-extended back up to 64 bits. This one concession to 32-bit code meant that you could run code that was conceptually 32-bit on this 64-bit CPU: All the operating system has to do is treat the 32-bit addresses 0x00000000 through 0x7FFFFFFF as 64-bit addresses 0x00000000`00000000 through 0x00000000`7FFFFFFF, and treat 32-bit addresses 0x80000000 through 0xFFFFFFFF as 64-bit addresses 0xFFFFFFFF`80000000 through 0xFFFFFFFF`FFFFFFFF, The processor's natural sign extension did the rest.

    (And now you can see another reason why there is a no-man's land around the 2GB boundary. If objects were allowed to cross the 2GB boundary, they would end up being split up when converted to the Alpha AXP's 64-bit address space.)

    This is sort of analogous to running 16-bit Windows programs on an 80386 processor. Your 16-bit program could still use those 32-bit registers if it only knew they were there.

    This clever design of the Alpha AXP meant that you could read through quite a bit of Alpha AXP assembly language without being able to tell whether the code was designed as 32-bit or 64-bit code since it all looked the same. The only giveaway would be when the code loaded a pointer from memory.

    Anyway, back to VLM. Windows NT on an Alpha AXP was a 32-bit operating system on a 64-bit processor. The 32-bit address space was only a tiny fraction of the full 64-bit address space available to the processor. And VLM gave you access to that space that would otherwise go wasted.

    You allocated memory in the 64-bit address space with functions like VirtualAllocVlm. All of the VLM functions operated on 64-bit pointers (called PVOID64). Allocating memory via VLM returned you a PVOID64, a 64-bit pointer to the memory, and your program had to use these 64-bit pointers to access the memory. And like its successor AWE, VLM allocated non-paged memory.

    In addition to allocating memory, there were special functions for memory-mapping a file into the 64-bit address space and performing disk I/O into and out of these 64-bit addresses. But that's about it. The rest of Win32 still used 32-bit pointers, so you couldn't pass these 64-bit addresses to functions like lstrcmpi. You were given the raw materials for allocating memory in the 64-bit address space and the rest was up to you.

    These functions were designed for high-end database programs which required enormous quantities of memory and (more importantly) address space. The memory wasn't pageable because high-end database programs invariably perform their own highly specialized memory management, and paging just gets in the way.

    With the death of the Alpha AXP also came the death of VLM, since the Alpha AXP was the only architecture that supported 64-bit addresses in 32-bit code.

    This model of programming is not dead, however. It was seen in Windows 3.1 with the WINMEM32 library (which even let you create 32-bit code segments!), and a more restricted version of it lives on in AWE.

Page 5 of 5 (46 items) 12345