Vista preview handlers

by Matt 5. June 2007 17:07

Here's a right little collection of links for you. I should really put them on my list of Programs What I Run.

Anyway. Vista's got this nice preview pane that allows you to see, well, a preview of a selected file. Handy. Naturally enough, not all of your favourite file types are going to be supported out of the box, so here's a list of shell extensions to add that special magic.

Right. I feel a bullet list coming on.

But first things first. There is an MSDN article that showed how to build these extensions in managed code (which is allowed, because they run out of process. Don't run .net shell extensions in-process.) It adds a whole heap of previewers, but since it comes from a developer centric article, it's not exactly user friendly in terms of either installing or documentation. So, download the file, double click to extract it, go into the Installer directory and read the README.txt.

Now, you should have a previewer for:

  • .bin and .dat files, treated as binary files
  • .csv files displayed in a DataGridView
  • .isf files, which appear to be ink files from table pc's
  • .msi installer files displaying a list of all the files that might be installed
  • .resources files (used to hold strings and images during .net compilation)
  • .resx files (an xml based file that becomes a .resources file)
  • .snk and .keys files, again used by .net compilation to provide a strong name to an assembly.
  • .zip and .gadget. A rather lovely idea - displays a tree view of all the files in a zip based file. Gadget files are also zip files, so are also handled. You could take this further and register it as the previewer for .xpi (Firefox extensions), .jar files, and even .docx (although you might want to keep that one for the proper Word preview handler)
  • .pdf, via the Adobe Acrobat ActiveX control
  • .xaml!
  • Finally, there's an Internet Explorer preview handler. This is rather nifty and just displays the file in an IE control. It's registered for xml files (via the "xmlfile" registry key, not .xml. This means it gets anything that identifies itself as a .xml file, such as .rels). It's also registered for .config and an unknown .psq file type (which this link identifies as a "Product Studio Query File" and this link identifies "Product Studio" as a bug tracker within Microsoft). It also handles .xps files, because IE is the default xps viewer.

Now, a bunch of those preview handlers could handle other file types. The IE handler could display, oh, I don't know, html files? The MSDN article does have a sidebar on how to register other file types with existing extensions, but if that's too much of a drag, you can try this association editor.

And that's all from the same guy. What can anyone else add?

Oh, and these all work in Office 2007 on Vista, too. But not XP. Fortunately, someone has done all the dirty work of back-porting support for Office 2007 on XP. This package also includes most of the preview handlers already mentioned, but with a few more file types registered, such as .html, .htm, etc.


Vista | Shell Extensions | Preview Handlers

Programmatic access to UAC. Kinda.

by Matt 5. June 2007 05:28

I kinda like this web site. It offers a C++ source file with various functions to help in install time situations; functions like IsVista() and IsWow64(). And it also gives some functions to deal with User Account Control. GetElevationType(), IsElevated() and RunElevated() are going to be very useful.

The killer function, though is RunNonElevated(). This is a doozy.

Picture this - I run my installer. It needs to write to C:\Program Files, so gets elevated. Trying to be as nice as I can to my user, I offer them a chance to run my program at the end of the installer, as is common. Unfortunately, since the installer is now running elevated, my newly installed program will run elevated, which is not what I want.

So this function could be very useful. The downside is that Microsoft haven't actually provided any means of running a program non-elevated, so this function has to hack around it by injecting itself into the shell, which it knows is not elevated and getting explorer to spawn the process.

Is it just mean that sees the irony in having to inject code into one process to run another process securely?



Xml Diff and Patch tools

by Matt 16. April 2007 17:35

Ages ago, I found Microsoft's xml diff and patch tools on gotdotnet. Dead useful little package - it does exactly what it says on the tin, diffs and patches xml files.

I went looking for it again today, and of course, link rot had set in. Microsoft is phasing out gotdotnet, so when you head on over to you get an "Unspecified error" page, with no helpful links. Bit of a shame, that, seeing how loads of pages around the web point you there.

Fortunately, there are a couple of msdn articles. The first gives a nice overview of using the xmldiffpatch assembly in your own code, but not of the tools. And the link to download the tools returns an out of date 1.0 version.

But, that download has a sample to generate a html file from two differing xml files. And this second msdn article creates a Windows Form app over the top of this sample to generate and display the differences in a hosted browser window. Again, this uses an out of date 1.0 version.

Finally, I look at the home page of (which still has people uploading samples even though it's being decommissioned) and find a link to the XML tools page on msdn. Now, we get the newer 1.1 version. (There's also a link to the quite useful Xml Notepad on that page.)

And it doesn't install on Vista.

It's demanding .net 1.1 to be installed.

Keep me covered, I'm going in.

First, we need to open the executable in Visual Studio. This should display the resource view. Expand the RCDATA node, and right click on "CABINET". Export this data as "". Switch back to explorer, and double click on the .cab file. You can now copy out setup.exe, setup.ini and XmlDiffPatch.msi. In fact, we're just interested in the .msi file. If you double click on it, you get an error message that .net 1.1 isn't installed.

I can't find a way to fix this easily. The msi file has a custom action that checks for the installed .net framework versions, and compares them against a property it has stashed away. It would be nice if we could have just changed the SupportedRuntimes value in the setup.ini, or passed in an override value for the VSDSupportedRuntimes property on the command line, but no. We have to edit the .msi file. You'll need Orca installed (I think it comes as a .msi in the Windows SDK). Open the .msi file, scroll down to "CustomAction" and delete the VSDCA_VsdLaunchConditions custom action. Save the file and exit.

Double clicking the .msi will now allow you to install the software. Phew.

It seems to work, but bizarrely, the XmlPatch.exe file gains the Vista UAC shield. I guess because it's got the word "patch" in the name (and because it's in the Program Files directory. Copy it out, and it's fine). That's a bit pants. To fix that, you'll need to copy the following into a file called XmlPatch.exe.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="" processorArchitecture="X86" name="XmlPatch.exe" type="win32"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="asInvoker"/> 

Then drop to a command prompt. Seeing how you've already got the Windows SDK for Orca, you'll also get mt.exe from there. It should be the latest version (there are bugs in previous versions which can cause blue screens!). Run the following command line, using the mt.exe from the SDK:

mt -manifest XmlPatch.exe.manifest -outputresource:XmlPatch.exe

Finally, we've got a version of the xml diff and patch tools, ready to use. And it even comes with source. Installed to Program Files so that you can't compile it without moving it, but you've got source code. You can now build the all important dll, the XmlDiff and XmlPatch command line utils, and there's that sample that generates a html diff view for you. This was the sample I wanted to build, and what caused all of this pain. It'd better be worth it.


Vista | .net tools

Vista's UIPI. Mostly compatible

by Matt 15. April 2007 18:04

We all knew Vista's security changes were going to be far reaching. UAC is controversial, and big, but even if you've made bad assumptions in your code, it still has a good compatibility story. UIPI has a much more interesting acronym and the potential for some much more interesting edge case incompatibilities.

In case you're wondering, UIPI is User Interface Privelege Isolation - it limits the windows messages a low level integrity process can send to a high integrity level process. It's designed to stop Shatter attacks, and is a major part of IE7's protected mode.

Not even Microsoft are above falling for this.

When Explorer starts up, or restarts after a crash, it broadcasts a registered windows message of "TaskbarCreated", so all the little applets can add themselves back into the notification area (system tray).

Can you see where this is headed?

Bingo. Programs running as admin don't get the "TaskbarCreated" message.

Now, AIUI, you can get round this by allowing the "TaskbarCreated" message to be received, using the new ChangeWindowMessageFilter function. But the bigger question is why do have an admin privelege program running permanently in the notification area?

(For what it's worth, I wanted to call this post "UIPI-kay-ay mother f****r", but didn't really have the bottle.)



Notification icons in Vista. Popup UI?

by Matt 9. April 2007 16:56

I've just hit the msdn page for NOTIFYICONDATA, the structure passed through to Shell_NotifyIcon. It's been updated with Vista information. There have been a few changes, mostly quite dull, but check out this teaser for a new value for flags (red text emphasis mine):


Windows Vista and later: Use the standard ToolTip. When uVersion is set to NOTIFYICON_VERSION_4, the standard ToolTip is replaced by the application-drawn pop-up user interface (UI). If the application wants to show the standard tooltip in that case, regardless of whether the on-hover UI is showing, it can specify NIF_SHOWTIP to indicate the standard tooltip should still be shown. Note that the NIF_SHOWTIP flag is effective until the next call to Shell_NotifyIcon.

So, is this "application-drawn pop-up user interface" what's providing the fancy images for the battery, network and volume icons?

And if so, how do you actually draw it? That's not mentioned anywhere. (Well, it does say "application-drawn", so perhaps the question should be where? And how big? And do I have to do it all myself?)

One indication that this is what is being referred to is that these three icons don't actually appear in the normal notification area in Vista. Fire up Spy++ and it shows that these icons live in a window with a caption of "System Control Area" rather than the normal "Notification Area". This is mentioned in the NOTIFYICONDATA docs:

These icons are scaled down when they are displayed in the System Tray or System Control Area (SCA).

But that raises the question about how to add something to the SCA. Is that the guid is for in the struct?

PS. It's worth reading the remarks section for NOTIFYICONDATA; there's more going on with notification icons than you might first think. Balloon tips are queued. They display between 10 and 30 seconds, and this time doesn't start if you're not using your machine, or the screen saver is running. With Vista, they also don't appear when you're in in presentation mode. Shame you have to remember all of that when you need to roll your own.



UAC is Your (Mostly Silent) Friend

by Matt 3. April 2007 17:13

Now that the legendary Charles Petzold says UAC is ok, do you think the rest of the Windows world listen and realise it's actually a Good Thing?

My good buddy Jeff Prosise talks about setting up his new Vista machine and complains about the "constant badgering from the User Account Control (UAC)."

I've installed Vista on freshly formatted partitions of the three desktop machines I use (and replaced the video board on two of them), and while the UAC tends to be most active during setups and installations, it becomes virtually silent in day-to-day use. I use all three machines for writing and for WPF development with Visual Studio, and I rarely see the UAC any more. When it does pop up, I get the chance to re-evaluate what I'm trying to do.

Source: The UAC is Your (Mostly Silent) Friend



When will Sidebar be useful?

by Matt 8. March 2007 17:48

So, LifeHacker has picked up on the AmbientClock. Seeing this again, especially with their focus of using it in a Google gadget made me think that this is exactly the kind of gadget that could finally make the Vista Sidebar useful.

I've been running the Sidebar since I got Vista, and I'm still not really sold on it. I'm still failing to see what use these gadgets/widgets/whatever are. I think it just adds to the information overload. Most of the gadgets I've seen either give you access to information that's already easily available (such as battery status - already next to the clock) or that you just don't really need (CPU meter springs to mind. If I'm concerned about my CPU usage, I'll look in Task Manager to see what is actually slowing my machine down).

My current line up includes a weather gadget (I can look out the window, thanks), the standard RSS feed viewer (all the headlines are truncated, and it's not the nicest reading experience). I've got a BBC radio gadget, which is rather nice, but just doesn't see much use. The default clock is nice, and is probably why the Sidebar has stayed as long as it has. The nearest I've got to a killer app (at least in theory) is a clipboard ring. But it's kinda dull looking, and only supports text, and I haven't actually used it yet. I like the idea though.

An AmbientClock Sidebar gadget hooked up to your Windows Calendar (or Outlook) could be pretty impressive. So why is this different? The clock's already available, as is the calendar information. And the answer is I dunno. But there's a lot of this gadget stuff about - those users can't all be wrong. Right?



Missing Vista features #4 - WinFS

by Matt 20. February 2007 19:03

Oh yes. The WinFS Post. Dare linked to a previous post of his while commenting on Microsoft focusing on vision, rather than shipping, which reminded me that I hadn't gotten around to writing about it.

Here's the link to the more interesting post, and if you've been living under a rock and don't have a scooby-doo what I'm talking about, here's a great Wikipedia article about it all.

I didn't get to play with any actual bits, so I'm not about to shoot my mouth off about the technology, but I loved the concept. I was very disappointed to see WinFS go. It was the most exciting of the original Three Pillars of Longhorn (WinFS, Indigo and Avalon).

On the surface, it was all about search. I think we've nailed that one without needing WinFS. There were some advanced searches that we were promised (as Wikipedia says: "the phone numbers of all persons who live in Acapulco and each have more than 100 appearances in my photo collection and with whom I have had e-mail within last month"), but I wouldn't bet against Windows Desktop Search being able to handle something like that, especially when you see the surprisingly-off-by-default natural language search.

I think a lot of people unfairly dismissed the more interesting part - the data store. To me, this was the killer app. WinFS stored any data you wanted it to, in a structured manner, with relationships between items and properties and allowed you to search over the lot. This was huge.

It had a bunch of built in schema, so you could store contacts, emails, IMs, documents, pictures, videos, music and more. But as Dare points out, many people felt there was a chicken and egg situation. Most apps already had massive investments in their own data store (e.g. Outlook) so why would they throw that away and migrate to WinFS?

As I understood it, the architects of WinFS had already thought of this, and you could promote metadata from your custom data store into WinFS, and get back notifications when the WinFS data store changed. Bingo. No need to rewrite your app.

The really big thing about the data store was that it totally blew open the data silos. It effectively normalised all data formats. Yes, I can search for all contacts with Windows Desktop Search, but once I've got the results, there's not a lot else I can do, because some are stored in Outlook, some in vcard files, some in Vista Contacts, some in IM, etc. With WinFS, you just have a contact. You manipulated the WinFS Contact datatype and saved the changes back. That's incredibly powerful.

This post by Brandon Paddock of the WDS team is great - read the comments. He points out that WinFS would still have to store music in different formats - WMA, MP3, etc - so is this unified API viable, or just a little too idealistic?

Even if the unified data store is a step too far, WinFS is still a killer app from a dev point of view. Just about every app you build has to have local storage, and you always have to roll it yourself. You've got a whole heap of options, none of which are ideal. Xml files means reading the whole of each file into memory (like Sharpreader and RssBandit do - hence the large memory footprint), you could use a database, such as Access, SQL Server (Express), SQL Server Everywhere, SQLite, etc. But these have their own limitations - is the data you want to store suitable for a database (RSS feeds or email messages in a SQL database?) Is client/server appropriate? Is an in-process DB robust enough? You could even roll your own solution, which is fraught with peril. Or you could just let WinFS worry about it and get free searching to boot.

Ah WinFS, we hardly knew you...


Windows Desktop Search | Vista

Power management, Vista and me. Group hug!

by Matt 20. February 2007 17:44

In case you were wondering, the ongoing saga of my laptop display not working when coming out of sleep is finally fixed. Turns out, a simple BIOS update works wonders. I can now even display stuff on a projector, which I didn't know I couldn't do until I needed to do a presentation the other day...



Windows PowerShell for Windows Vista

by Matt 30. January 2007 16:21



Month List


Comment RSS