Holy cow, I wrote a book!
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
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.
That was one expensive Harry Potter movie.
(By the way, I liked the movie.)
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?"
It was not one of Explorer's design goals
to provide a Turing-complete interface for bulk file renaming.
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.
Or you can write a batch file that does some editing before
doing the rename.
for %%i in (*.doc) do call :fancy %%i
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
:%s/^\([^ ]*\) \([^ ]*\)\(.*\)/ren "\1 \2\3" "\2 \1\3"
Or you can write a program in your favorite language that does the
most awesome-fancy renaming the world has ever seen.
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.
*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.
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.
In downtown Bellevue there is a mall named
but I hear people refer to it with some frequency as
Just a reminder:
is in New York City.
There are many other places in the world with the names Lincoln Square
and Lincoln Center.
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
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
All of the VLM functions operated on 64-bit pointers
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)
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.