Holy cow, I wrote a book!
As a general rule,
child processes inherit the environment of their parent.
But if the parent is non-elevated and the child is elevated,
then this inheritance does not happen.
There are two answers to this question.
For the kernel-color glasses answer,
I defer to
Chris Jackson, the App Compat Guy.
It's interesting to see how it all works,
but it doesn't explain
why the mechanism was designed to block
environment variable inheritance.
The reason for the design is that
allowing an elevated process to inherit the PATH
from a non-elevated process creates an attack vector.
The non-elevated process sets its PATH to put
some attacker-controlled directories ahead of the directories
the elevated application actually expects.
For example, suppose the elevated application links to
C:\Program Files\Common Files\Contoso\ContosoGridControl.dll.
It arranges for this by setting the system PATH
to include the
C:\Program Files\Common Files\Contoso
Or maybe the program calls
LoadLibrary on a DLL that might not exist,
and it handles the case that the call fails by disabling
some optional feature.
(Whether this is a good idea or not is beside the point.)
C:\Program Files\Common Files\Contoso\ContosoGridControl.dll
C:\Program Files\Common Files\Contoso
changes the PATH to read
\\rogue\server;C:\Program Files\Common Files\Contoso,
so that the library search finds the evil copy on the rogue server
before finding the expected version in the Common Files
(or in the case of a DLL that may not exist,
it finds the evil copy on the rogue server instead of failing outright).
\\rogue\server;C:\Program Files\Common Files\Contoso
Bingo, the attacker has injected arbitrary code into an elevated
For similar reasons,
the current directory is reset to the system directory
when a non-elevated program launches an elevated program.
If the environment and current directory were inherited,
then malware could ask to elevate Program X with a
custom current directory or environment. The user will
merely be asked if they want to run Program X elevated,
unaware that it is being run in a nonstandard manner,
using an execution environment that did not receive
As a result, the malware would be able to sneak into the administrator
account under sheep's clothing (the sheep being Program X).
What if you want to run another program elevated,
and with a custom current directory or environment?
Write a wrapper program which sets the current directory
and environment, then launches the desired target process.
Then ask the user for permission to run the wrapper elevated.
If an operation includes as part of its processing sending messages,
then naturally the target window for those messages must be
processing messages (or more precisely, the thread which owns the
target window must be processing messages) in order for the
operation to complete.
Because processing messages is the only way a window can receive messages!
It's sort of tautological yet not obvious to everyone.
Generally you run into this problem when you try to manipulate
a window from a thread different from the one which created
Since windows have thread affinity,
operations from off-thread
typically need to get moved onto the thread which owns the window
because that's where the window really "lives".
The window manager will often try to see how much it can do
without marshalling to the thread which owns the window,
but when message traffic is involved,
you are pretty much stuck.
Messages are delivered to a window on the thread to which the window
belongs, and there's no way around that.
There are subtle ways in which a function called off-thread
can result in message traffic.
Generally speaking, you should just assume that any operation on
a window may generate messages:
Even if they don't do so today, they may do so in the future.
For example, changing a window's style did not generate message traffic
in early versions of Windows, but in
Windows 95, it began generating
This isn't called out explicitly in the documentation for
but it's implied by the documentation for
WM_STYLECHANGING and WM_STYLECHANGED.
Why isn't there an explicit callout in the documentation for
At the time the SetWindowLong documentation was
originally written, the WM_STYLECHANGING and
WM_STYLECHANGED messages did not exist.
Therefore the documentation was complete at the time of writing.
Circumstances changed elsewhere in the system that had
secondary effects on SetWindowLong,
but nobody bothered to update the documentation,
probably because it didn't even occur to anybody
that these effects existed.
And then these secondary effects lead to tertiary effects:
SetScrollInfo may change the window style
to add or remove the WS_HSCROLL or
which in turn results in a call to
SetWindowLong which in turn results in sending
the WM_STYLECHANGING and WM_STYLECHANGED
Next come quaternary effects on functions like
since they call
SetScrollInfo as part of their functioning.
And so on, and so on.
Just tracking down the full ripple
effect of those two new messages is probably impossible.
But the root cause of all these ripple effects is
operating on a window (particularly modifying a window)
from a thread
different from the thread that owns the window.
Avoid that, and you'll avoid the whole issue of which operations
generate messages and which manage to sneak by without needing to
send any messages (at least not yet).
(co-hosted by former Seattleite Bill Radke—we miss you, Bill!)
a story on the Princeton Laptop Orchestra,
which calls itself
It's an interesting experiment,
but computer music doesn't really move me.
It's not the computer-ness that bugs me
(I was fascinated by music played on Gameboys, after all)
but rather the lack of traditional musicality.
the chord that opens the piece on online gambling creeps me out.
Not because of the piece itself,
but because it is dangerously reminiscent of the chord played
at the Tulalip Casino,
a steady synthesized triad played at low volume so you can
barely hear it.
And after a while, you simply stop hearing it,
and then you have to whack yourself on the head and make yourself
hear it again because allowing it to sink into your subconscious
means that they've won.
It's the season where people with fruit trees in their yard
are drowning in fresh fruit, be they pears, apples, plums, whatever.
It's not long before you find yourself desperately looking for
people to give it away to, having pretty much run out of things
you can make plums into.
This is where
Community Fruit Tree Harvest steps in.
The Seattle Times
The Seattle Post-Intelligencer.
Lettuce Link for donating produce from your home garden.)
The volunteers at Community Fruit Tree Harvest will visit your house
and pick the fruit from your tree,
donating it to local food banks.
Everybody wins: You don't have to deal with all the extra fruit,
the food banks get fresh fruit,
nothing goes to waste.
(This is one of those "Why didn't somebody think of this sooner?"
type of programs.)
Contact telephone numbers are on the web pages.
It appears that they currently cover the Wallingford,
Phinney Ridge, and Green Lake neighborhoods.
NPR reported on The Thing?,
surreal yet kitchy roadside attraction on Interstate 10
which has cryptic (and therefore intriguing) advertising signs
for hundreds of miles.
Rene Gutel of member station KJZZ in Phoenix
gets to the bottom of the enduring mystery: What is The Thing?
A customer noticed that when the user hovered over their
application name in the Start menu, the infotip that pops up
includes their product name:
... but no other program on the Start menu included the product
name in the description:
The customer compared their shortcut with the other ones
but couldn't find anything that was telling Explorer,
"Include the program name in the pop-up infotip, please."
Because the reason for the name being included in the infotip
had nothing to do with the properties stored in the shortcut.
The reason the name was included in the infotip is that the
name was being truncated in the main display.
When an infotip is about to be displayed for a listview item,
the listview sends a
If the LVGIT_UNFOLDED flag is not set, then
the infotip is being displayed for a truncated item, and
the pszText is pre-filled with the full name.
The program should then append its information to the existing text
so that the full name is the first line of the infotip.
On the other hand, if the
LVGIT_UNFOLDED flag is set, then
the item text is fully-visible and you should just copy your
desired description text into the pszText buffer.
The customer was happy to get this information.
Their designer wanted only the description to appear in the infotip,
and now they know that they need to shorten the program name
to make the name disappear from the infotip.
Software Development Kit for
Microsoft® Pre-Release Windows Operating System Code-Named "Longhorn",
Beta 1 Web Setup.
Some times ago, I described
why a corrupted binary sometimes results in the error
"Program too big to fit in memory".
Commenter Neil was under the impression that
nonrelocatable programs files could be larger than 64KB
and used the DEBUG command to verify this assertion.
While it's true that DEBUG can load files bigger than 64KB,
that doesn't mean that they will load as a program.
If DEBUG decide that you didn't give it a program
(the file extension is not EXE or COM),¹
then it treats the file on the command line as a data file
and loads it into memory in its entirety,
provided it fits in memory in its entirety.
When it does this,
the BX register contains the upper 16 bits of the file size,
and CX contains the lower 16 bits.
This is also the format that is used when writing files back out:
Use the n command to set the name of the output file
and set BX:CX to the file size.
Even though DEBUG has been obsolete for over a decade,
it is still useful for exactly this purpose:
You can use it as a hex editor for files less than around 512KB.
But don't deceive yourself into thinking that you created a COM file
that is bigger than 64KB.
¹There is another extension which has special meaning to
DEBUG, but it's not relevant to the discussion.
On my way to work, I saw a Notice of Proposed Land Use Action.
The proposed new use for the property was
long-term temporary parking.
What the heck is long-term temporary parking?
When you set your Explorer to Details view,
it can become tricky to drop an item onto the window background
(in order to move it into the folder)
because Details view sets full row select (starting in
This helps users of tablets and touch screens, because it
increases the size of the target when dragging and dropping
into a folder.
On the other hand,
when you have more items than fit on the screen,
every pixel in the view corresponds to an item;
there is no background any more.
So how do you drop on the background?
If you're using Windows 7,
you can take advantage of a little gutter space to the left and
right of the columns.
There is a gutter to the left of the leftmost column and
another gutter to the right of the rightmost column.
Windows Vista doesn't have these gutters, but you can
create a gutter on the right hand side by resizing your
columns narrow, and then resizing the window wider than
the sum of all the columns.
Yes, it's clumsy.
Less clumsy is dropping onto the Details panel at the bottom
of the window,
which works both on Windows Vista and Window 7.
Dropping onto the Details panel is treated as a drop on the
And the Details panel is a nice big target for your drag/drop
so those of you using a tablet or touch screen should have no
trouble finding it.
(Those gutters are nice for mouse-based users, but if you've
got fat fingers, they're not much help on a touch screen.)
If you've turned off the Details panel,
you can also drop onto the title bar.
It's not as big as the Details pane, but it's still bigger
than the gutters.
Finally, there's always the copy/paste approach instead of
Multi-select the items you want to transfer,
right-click them and select Copy (or Cut, as appropriate),
then go to the destination folder,
and under the Organize menu, select Paste.
Except for the gutters, all of these techniques also work
for Windows Vista.
Commenter Medinoc complains that, with the switch to full row select,
it's very hard to click on the background.
Actually, it's not that bad.
You can right-click on
the blank space of any unselected item.
find an unselected
item with a name that doesn't fill the entire Name column
and look at all that white space to the right.
You can right-click there and it will be treated as as a right-click
on the background.
The full row is still
treated as part of the item when dropping,
for the benefit of people using tablets and touch screens,
or people who simply want to hit a target bigger than a 16×16 icon.
It's that time again: Linking to other Microsoft bloggers.