All Your Base Are Belong To Us : Windows7

Restart Windows and Restart All Registered Applications: shutdown -g

Sasha Goldshtein — Sun, 14 Aug 2011 20:19:06 GMT

The Windows Restart Manager (introduced in Windows Vista) supports gracefully shutting down and restarting applications that registered for restart with the RegisterApplicationRestart API.

This functionality is used by Windows Update – thanks to the Restart Manager, when I come yawning to my desktop PC in the morning, even following a system restart, I have my Outlook, browser windows, OneNote, Visual Studio, and Messenger all lined up as they were when I went to bed.

Suppose you want to initiate one of these “automagically restart everything after restart” restarts. As of a few weeks ago, I had it in my head that you have to write a small app that uses the Restart Manager APIs (e.g. RmStartSession and RmShutdown) to do this.

And then it hit me that the shutdown command must have support for doing this. And indeed, it has:

shutdown /g

Debugging Windows Service Startup with Service Isolation

Sasha Goldshtein — Tue, 10 May 2011 21:12:44 GMT

A year and a half ago I touched on the subject of debugging process startup, such as the startup of Windows Services, using the GFlags utility (the ImageFileExecutionOptions registry key).

The general idea is to rely on the Windows loader to launch a debugger instead of the debugged process, and trace your way through the process startup code. Unfortunately, this relies on the debugged process to run in the same session as you—otherwise, you won’t be able to actually see the debugger.

Starting from Windows Vista, Windows services are isolated into a separate session to which you do not have access when you are logged onto the system. The debugger is launched within this session as well, which produces the undesired result of having the service stuck waiting for the debugger, and the debugger stuck waiting for your input which you cannot provide. (To learn more about Session 0 Isolation, check out the trusty Windows 7 Training Kit which covers several application compatibility topics with detailed code examples.)

What can you do to debug service startup on Windows Vista or newer OS versions? All you need is to fire a remote debugging server that debugs the service, and connect to its debugging session from a debugging client. Assuming that your Debugging Tools for Windows installation resides in C:\Debuggers, you can configure the following as the Debugger string in GFlags:

C:\Debuggers\ntsd.exe -server tcp:port=10000 -noio

When you start the service, you will notice an ntsd.exe instance launch in session 0; you’ll need to connect to the debugging session quickly by launching WinDbg (or NTSD), choosing File | Connect to Remote Session, and providing tcp:port=10000 as the transport. (Note that when debugging service startup, you might want to increase the service startup timeout to prevent the SCM from giving up on your service. Unfortunately, this is a global setting; another option is to request additional time from code.)

What Did My Manifest Do: A Referral Was Returned from the Server

Sasha Goldshtein — Thu, 02 Sep 2010 20:43:45 GMT

The UAC section of an application’s manifest contains two simple settings under the <requestedExecutionLevel> element of the <requestedPrivileges> node:

level – asInvoker, requireAdministrator, or highestAvailable. This setting controls whether the application will require elevation before it runs.
uiAccess – true or false. This setting determines whether the application will exempt from UIPI rules introduced as part of the Windows Integrity Mechanism.

If you really need the uiAccess element (and you should be really convinced that you understand why you need it before proceeding), then your application must be signed, and by default, must reside in one of the secure locations, namely \Program Files, \Windows\system32, or \Program Files (x86).

This latter setting can be changed through group policy (see the screenshot below), but there’s no way to circumvent the certificate verification.

If your application doesn’t comply with these requirements but the manifest still contains the uiAccess=true setting, your process will fail to launch with the cryptic “A referral was returned from the server” error message:

This isn’t the friendliest way of saying that there’s something wrong with your UAC manifest setting, but that’s why I’m writing this post.

Windows 7 How-To Videos: Libraries and Federated Search

Sasha Goldshtein — Wed, 14 Apr 2010 16:35:44 GMT

More Windows 7 videos that I recorded have been posted on Channel 9. This installment deals with Windows 7 shell libraries and Federated Search, a subject that I haven’t covered in depth on my blog. The videos feature an introduction to shell libraries and demonstrate how to integrate your application with Windows 7 libraries from managed and native code, how to register for library change notifications (if you care about changes to library contents), and how to use Federated Search to integrate your search provider into Windows Explorer.

[I don’t remember if I told you this in my last post, but all videos have an accompanying code download which is the precise version of the code that I used when recording these videos.]

Introduction to Windows 7 Libraries

Integrating with Shell Libraries, Part 1

Integrating with Shell Libraries, Part 2

Federated Search

Stay tuned for more! :-)

Windows 7 How-To Videos: Windows 7 Taskbar

Sasha Goldshtein — Sun, 28 Mar 2010 19:23:26 GMT

Rather than make an HTML index of the videos, I figured it would be more convenient for my visitors to watch the videos directly from here, thanks to the Channel 9 embedding capabilities (and Silverlight).

Introduction and Application ID

Overlay Icons and Progress Bars

Jump Lists Part 1

Jump Lists Part 2

Custom Previews and Thumbnail Clips

Tabbed Thumbnails

When more videos are posted, I will create new posts that will have them embedded.

Windows 7 How-To Videos: Introduction to the Windows 7 Taskbar

Sasha Goldshtein — Sun, 28 Mar 2010 19:17:19 GMT

As part of our work on the Windows 7 training materials, I recorded 23 short how-to videos explaining how to use the new Windows 7 features from managed code (often using the Windows API Code Pack) and from native code. Our Sela team, including Alon, Dima, Arik, and many others, collaborated on the slide decks, demo code, and other aspects of these recordings.

The first installment of these videos is already live on Channel 9—you can download or watch online six videos about the Windows 7 taskbar. As you might remember, the Windows 7 taskbar is one of my favorite new APIs in Windows 7, and I’ve covered it extensively in a series of posts, in an MSDN Magazine article, and in our book, Introducing Windows 7 for Developers.

Amongst the upcoming videos you’ll find an in-depth look at background services and trigger-start services; Libraries and Federated Search; an introduction to Ribbon development; and a series of videos on instrumentation (ETW, WMI, the Troubleshooting Platform, and other topics).

Here’s an index of the videos you can watch right now on Channel 9:

And here’s an index of my posts about the Windows 7 taskbar:

PDC 2009 Day 3: Developing Applications for Scale-Up Servers Running Windows Server 2008 R2

Sasha Goldshtein — Fri, 20 Nov 2009 02:01:50 GMT

Pedro Teixeira is going to talk about processes and threads in systems with more than 64 logical processors as well as user-mode scheduling.

Surprisingly for some people, NUMA is not an esoteric hardware architecture. Even high-end gaming rigs today are NUMA; Pedro is going to use a loaned machine by HP that has 256 processors with 1TB of physical memory.

Processor Groups

Adding support for more than 64 logical processors required a breaking app compat change, because CPU masks were represented in Windows by a bitmask. Therefore, CPUs are now addressed by 64-processor groups and there’s a need for new APIs that interact with these groups. Currently there’s a maximum of four groups, but this is an artificial limitation. (Processor groups are only available on 64-bit platforms.)

Groups are distributed by proximity – all logical processors in a core (hyper-threading), all cores in a socket, closer sockets on the board, NUMA nodes, and closer NUMA nodes. This guarantees that within one CPU group the computational resources are as close as possible.

Windows actually tests the distances between NUMA nodes in spite of what the hardware reports, to determine the true proximity metric for processor groups.

Each thread can belong only to one CPU group. Threads can be assigned to groups using CreateRemoteThreadEx with a special thread initialization attribute, or using SetThreadGroupAffinity. Processes are assigned to groups in round-robin, and the threads inherit the group from the parent thread and from their process.

NUMA and Proximity Information

There are also new APIs that can be used to extract the system topology information with relationships between cores, NUMA nodes, and so forth. As part of this topology, information about memory technology and device location are also exposed – e.g. physical devices and network storage connected to a NUMA node directly. (So it’s not just about memory anymore, and it’s not surprising considering DMA must be performed from these devices. NUEA – non-uniform everything access :-))

Future hardware allows for load-balancing of NUMA nodes within the same box – e.g. by having two NICs with the same IP address, connected to separate NUMA nodes, that can use sophisticated rules for load-balancing of requests to the nodes. More new APIs allow extracting the NUMA node information from a socket or a file handle, and more.

[None of the demos worked during the presentation because the network connection to the monster HP machine was very flaky. Hopefully we’ll be able to get the demos after the talk.]

User-Mode Scheduling

UMS enables developers to write their own implementation of scheduling in user-mode, without going into the kernel, including synchronization primitives (which ConcRT implements). If one thread happens to use a kernel synchronization primitive, the user-mode scheduler still gets a chance to reschedule another task on that thread.

UMS is nothing like fibers – fibers allow for switching between contexts, but threads are much more than that (e.g. impersonation information), and UMS allows you to switch threads and not just contexts.

UMS is about splitting threads into a user part and a kernel part so that they can be switched separately (lazily switched). In user-mode, it’s possible to switch back and forth the user part of the thread (registers, stack and meta-information) without going into the kernel, running on the “wrong” kernel thread because the kernel information is not required as long as the thread runs in user-mode. When going into the kernel, UMS makes sure that the thread parts match (a thread switch).

In UMS there is a scheduler thread to represent each core, and you would usually create one scheduler thread per core – these decide which thread to run next. When creating a user scheduler, you provide a callback function that is called when necessary (a “message loop”). The scheduler decides what to do next by executing a worker thread – from a kernel perspective, these are full threads, not fibers. The worker threads are pushed by the kernel into a queue called the UMS completion list. (You can have as many UMS completion lists as you’d like – each UMS scheduler can create a completion list or share them, and so forth.)

The first thing the scheduler should do is pop worker threads from the UMS completion list and put them in its own ready list, perform scheduling and executes the worker thread.

A UMS thread can yield the processor, passing control to the scheduler. Yielding is a means for implementing arbitrary synchronization mechanisms in user-mode (e.g. an event wait in a library could mean storing away some contextual wait information and then yielding – the scheduler will be responsible for not scheduling the thread until the wait condition occurs).

When a worker thread performs a kernel call and blocks, the scheduler thread is again called with a notification that the thread was blocked. It can select another UMS thread and run it. (It’s the same yield as in the previous paragraph, but a kernel yield and not a user yield.) When the worker thread unblocks, it’s put in the UMS completion list and the scheduler is now responsible to look at the UMS completion list when it’s next invoked and move the threads from there to its private ready list.

If there’s no work in the ready list: The function for popping from the UMS completion list can block (with a timeout parameter), and you can also obtain an event that will be signaled when there’s something in the UMS completion list. This enables the scheduler to wait for work to be scheduled. However: Never return from the scheduler function!!! (When you return from the scheduler function, you’re back to the normal thread that you converted to the scheduler thread.)

There’s no support for preemption at the moment, so it’s impossible to implement a quantum-style scheduler. It’s possible to implement something like this using a watchdog thread that would call SuspendThread – that blocks and puts the thread in the UMS completion list.

[All in all, UMS is a very interesting mechanism. Alon and I agreed to write a sample together that shows off the basic features of UMS. Hopefully we’ll be able to publish it soon.]

PDC 2009 Day 2: Developing with the Windows API Code Pack for Microsoft .NET Framework

Sasha Goldshtein — Thu, 19 Nov 2009 08:11:50 GMT

Yochay, a good friend and co-author of “Introducing Windows 7 for Developers” and of the “Windows 7 Taskbar APIs” MSDN Magazine article, is delivering a presentation on the Windows API Code Pack. (Which is a library of managed APIs to interact with Vista and Windows 7 features that are otherwise accessible only from native code through COM and Win32 APIs.)

This library replaces many of the sample managed integration libraries that our team at Sela developed for the Windows 7 Metro Training, such as the Taskbar integration library, the Sensor and Location integration library, and many others. It’s great to see these technologies converging into an almost-supported library, and especially great to see some of them emerge in .NET 4.0 (Location, taskbar, multitouch and other features).

Yochay announced the latest version of the Windows API Code Pack – version 1.0.1, which mainly offers bug fixes and performance improvements, as well as many new demos.

Next, he demonstrated an application called Fishbowl which is the WPF version of the Facebook Silverlight application featured in Scott Guthrie’s keynote earlier today. It’s a full client application, so it can take advantage of the new Windows 7 features. It has a jump list with the latest notifications when the app is open or some launch tasks when the app is closed, and a thumbnail toolbar. Another example of an application taking advantage of Windows 7 is the Amazon Kindle for PC and it has a smart jump list with recent books and some tasks, as well as proper multitouch support.

Then, Yochay shows the XP to Windows 7 reference application called “PhotoView” which we at Sela developed. It’s an application that demos all the features of Vista and Windows 7 and still supports Windows XP with a smart plugin architecture. Yochay showed sensor integration in the app, which responds to ambient light changes by changing the color intensity of the picture displayed.

Throughout the session, Yochay proceeds to show us lots of code from the Windows API Code Pack itself as well as various demos that ship with it or that were built during the past few months.

If you’re not writing Windows 7 applications today, you should start thinking about giving yourself a competitive advantage. If you’re not using the Windows API Code Pack, go ahead and download it today, and use the Windows 7 Training Kit to bring yourself up to par with all its features.

Introducing Windows 7 for Developers: Foreword by Mark Russinovich

Sasha Goldshtein — Wed, 18 Nov 2009 10:50:11 GMT

Before Mark’s session today at the PDC, I exhibited typical Israeli chutzpah while he was helping himself for some coffee, and introduced myself as one of the co-authors of Introducing Windows 7 for Developers.

Mark did us the honor of writing the book’s foreword, and he even found it useful for the Disk2vhd Sysinternals utility which creates a virtual machine hard disk from your existing physical disk – the latest release of the utility shows the operation’s progress using the Windows 7 taskbar’s capability to show a progress bar.

In Mark’s own words:

For a programming book to be worth reading in this day of instant access to online documentation and code samples, it must provide complete and coherent introductions and overviews to new concepts as well as clearly explained and straightforward code samples that are easy to reuse. Yochay, Sasha, Laurence, and Alon have delivered both in this book that’s sure to become your Windows 7 programming companion whether you program to .NET or Win32 API. I’ve started adding Windows 7 functionality to the Sysinternals tools and the description and example of how to exploit the taskbar icon’s progress display enabled me to enhance the Sysinternals Disk2Vhd tool literally in a matter of minutes. I know I’ll be turning to this as I continue to update the tools, and I’m confident you will too, as you strive to give your applications that extra edge.

Thanks Mark!

PDC 2009 Day 1: Windows 7 and Windows Server 2008 R2 Kernel Changes

Sasha Goldshtein — Wed, 18 Nov 2009 05:03:56 GMT

It’s not the first time that I hear Mark Russinovich’s session on the Windows 7 and Windows Server 2008 R2 kernel changes.

Eran Stiller wrote a good post summarizing the main kernel changes (based on the materials from the Windows 7 Bootcamp at the PDC pre-conference day), so I’m not going to repeat the same here.

Additionally, you can watch Mark talk about Windows 7 internal changes on Channel 9.

Among the biggest kernel changes are optimizations that have to do with scaling Windows to hundreds of processors, such as eliminating the dispatcher (scheduler) lock, the PFN database lock and other exciting changes to mechanisms described in great detail in the Windows Internals book.

If you’re interested in a complementary point of view on user-mode changes and new features relevant to Windows 7 developers, go ahead and read Introducing Windows 7 for Developers :-)

Introducing Windows 7 for Developers

Sasha Goldshtein — Tue, 17 Nov 2009 01:16:47 GMT

Our book, “Introducing Windows 7 for Developers”, is now in stock on Amazon!

Several months ago, Alon Fliess, Yochay Kiriaty, Laurence Moroney and I decided to write a Windows 7 book for developers. With the abundance of new features in Windows 7 and the great interest from the developer community, we just had to write a book about Windows 7 from a developer perspective :-)

I’m at the PDC right now, and I already had an opportunity to sign a couple of Yochay’s copies—it feels amazing to finally see the result of the several months’ effort it took to write it. Although there are four co-authors to the book, it wouldn’t have been possible without the amazing support of our colleagues and managers, with special thanks to David Bassa and Dima Zurbalev; and it wouldn’t have been possible without our amazing technical reviewer, Christophe Nasarre, and the Microsoft Press editorial team.

Among the features covered by the book you’ll find multitouch, the new Windows 7 taskbar, libraries, the Ribbon UI framework, Sensor and Location, and many others. We tried to make the book as practical as possible with lots of inline code and stand-alone code samples that demonstrate the features from managed and native code. Our managed samples primarily use the Windows API Code Pack, but as you probably know by now, some features like multitouch, taskbar support and Sensor and Location are going to be part of .NET 4.0 and WPF 4.0.

If you get a copy of the book and have any comments or thoughts, please feel to contact me directly and let me know what you think. And if you’re at the PDC, feel free to drop by and say hello!

C++ Wrapper for Windows 7 Taskbar Tabbed Thumbnails

Sasha Goldshtein — Tue, 08 Sep 2009 03:24:18 GMT

A few weeks ago we took a detailed look at the intrinsic details of providing Windows 7 taskbar tab thumbnails and live previews in a Win32 application.

As part of that post I mentioned a C++ wrapper called TabWindow which takes care of most of the nasty details and leaves only the work of creating the tab controls and rendering them to the application developer.

Here’s the public API of the TabWindow class and its corresponding TabWindowEventsSink callback interface (slightly edited to fit):

class TabWindow
{
public:
    TabWindow(HWND wnd, HWND parent, LPCWSTR name, SIZE_T index);
    ~TabWindow();
 
    void SetThumbnail(HBITMAP hbm, bool invalidate = true);
    void SetPreview(HBITMAP hbm, bool invalidate = true);
    void SetOffset(POINT offset);
    void InvalidatePreviews();
 
    void SetEventsSink(TabWindowEventsSink* sink);
 
    HWND Hwnd() const { return _proxy; }
    HWND HwndTarget() const { return _target; }
    LPCWSTR Name() const { return _name; }
    SIZE_T Index() const { return _index; }
    void SetIndex(SIZE_T index) { _index = index; }
 
    static ATOM RegisterClass();
    static void EnableCustomPreviews(HWND hwnd);
    static void DisableCustomPreviews(HWND hwnd);
    static void SetTaskbarListPtr(ITaskbarList3* pTaskbar);
};

class TabWindowEventsSink
{
public:
    virtual HBITMAP OnSendPreview(HWND hwnd) = 0;
    virtual HBITMAP OnSendThumbnail(HWND hwnd, int w, int h) = 0;
    virtual void OnActivateTab(TabWindow* pTab) = 0;
    virtual void OnDestroyTab(TabWindow* pTab) = 0;
};

The use of this class is fairly straightforward. The UI controller of your application is responsible for the creation of tab windows that correspond to individual tab controls (or possibly a completely different UI paradigm).

On initialization, the UI controller should pass the ITaskbarList3 pointer to the static SetTaskbarListPtr method and call the static RegisterClass method. When a new tab window is created, an associated TabWindow instance should be created and associated with an index (for book-keeping purposes). Next, your UI controller should derive from the TabWindowEventsSink abstract class and implement its pure virtual methods—the first two provide the window thumbnail and live preview, and the former two react to the user activating or closing the tab from the taskbar.

A picture is worth a thousand words and a complete sample is probably worth even more, so I simplified the HOL solution from the Windows 7 Training Kit to demonstrate the TabWindow class for thumbnail and preview management. The resulting application looks like this:

…and has the following taskbar preview:

All the obvious commands work—you can activate a tab from the taskbar and it will activate the appropriate tab in the application, you can close a tab from the taskbar, and so on.

The sample solution can be downloaded from here. Have fun!

Creating a Custom Windows 7 Troubleshooting Pack

Sasha Goldshtein — Sat, 05 Sep 2009 22:52:17 GMT

Windows 7 offers a built-in troubleshooting platform that consolidates the typical user’s support and troubleshooting needs into a single consistent user interface with dozens of specific troubleshooters for common problems.

If you haven’t seen the Troubleshooting Platform in action yet, go ahead and type “troubleshooting” into your Windows 7 start menu and open the Troubleshooting control panel applet.

You can try some of the troubleshooters now. I’ll wait here. One of the easiest ones to repro and use is the “Check for performance issues” troubleshooter. Go ahead and change your power plan to the “Power Saver” plan and run the troubleshooter (while on AC power). The troubleshooter will attempt to detect performance problems for a few seconds, and then it will tell you that you’re using a power plan that can decrease your system’s optimal performance, and even offer to automatically fix the problem by moving you back to the “Balanced” power plan.

The first thing I thought about when I saw this platform in action was: How can I write a troubleshooter myself? How can I use the same consistent user interface to offer users of my software a self-support mechanism? (…And if you currently have any support costs at all for your own software, you must be asking yourself the same questions.)

Fortunately, writing a troubleshooting pack is fairly easy. There’s a neat tool that ships with the Windows 7 SDK called the Troubleshooting Pack Designer. You’ll find it in your SDK root under the Bin\TSPDesigner folder.

What I’m going to do in this short blog post is show you how to create a simple troubleshooting pack that will troubleshoot a very simple problem—if there is no folder named Temp in the C:\ root drive, it will create that folder automatically. You can imagine how this can be useful for legacy applications that disregard UAC and create folders all over the place.

To begin, I’ll click the new project icon and choose a location for the troubleshooting pack that I’m creating.

Next, there are all kinds of details to fill in, including the project name, description and privacy URL for the troubleshooter users. Next, we need to add a root cause, which is a general title for the thing that the troubleshooting pack can detect. Again we need to fill in some details.

Now it’s time to define the troubleshooter. Again there are some questions to answer first—the troubleshooter might or might not require elevation and might or might not require user interaction. My troubleshooter doesn’t require any of these.

Now we’re going to create a resolver—that’s the part of the troubleshooting pack that actually solves the problem. Again we need to give it a name and a description, and answer a few questions—does the resolver have any adverse side effects, does it have to run elevated, does it need any user interaction.

Finally, we have to define a verifier script—that’s the part that makes sure the problem is gone. In this case, we can reuse the troubleshooter script, so that’s what I’m telling the designer to do.

Now that I’ve defined all the parts of the troubleshooting pack, I need to write the actual code that detects, resolves and verifies the problem. That is done by using the “Edit Root Cause Scripts” link on the left. This opens the PowerShell IDE that ships in Windows 7. The language of choice for the Windows Troubleshooting Platform is PowerShell 2.0, which means that you can easily integrate your existing troubleshooting scripts using the standard .NET facilities or interop mechanisms.

In the troubleshooter script, I’m going to do a very simple check for the existence of the C:\Temp directory (the same script can be reused by the verifier part of the pack because it doesn’t have any side effects). Here’s the code:

$RootCauseID = "NoTempDirectory"
$RootCauseDetected = -not [System.IO.Directory]::Exists("C:\\Temp")
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected

Now let’s move on to the resolver script. Here we’re going to create the C:\Temp directory, nothing more. Here’s the code:

[System.IO.Directory]::CreateDirectory("C:\\Temp")

That’s all there’s to it—we now have a troubleshooting pack that is ready for action! One minor thing remaining is to actually sign the troubleshooting pack and then distribute it to your clients, but you can test-run the thing from the designer by clicking the green “Play” button, and voila:

If you look at the output\cab folder under the troubleshooting pack’s root directory (which I chose when creating the project), you’ll find a stand-alone .cab file ready for use.

Double-clicking that file brings us to the troubleshooting pack wizard, first step.

This post was just a brief overview of how easy it is to create a troubleshooting pack. It didn’t feature any sophisticated user interaction (and there are quite a few built-in interactions in the Troubleshooting Platform), so we basically only scratched the surface of this subject.

If there will be interest (and time) I will write more about troubleshooting packs, but in the meantime I suggest that you take a look at the Troubleshooting Pack Designer and learn how to write troubleshooting packs for your own software.

Windows 7 Taskbar: Tabbed Thumbnails and Previews in Native Code

Sasha Goldshtein — Thu, 13 Aug 2009 02:43:45 GMT

A few months ago, we’ve taken a look at how you can extend your MDI or TDI application with an individual thumbnail and live preview for each tab (or document) that will be displayed in the Windows 7 taskbar. We’ve seen the temporary managed wrapper that makes this possible, and in the final 1.0 release of the Windows API Code Pack there is a more polished managed API that does the same thing.

However, in this post I’d like to focus on the underlying details which you will have to deal with if you’re writing your GUI application in C++. There’s a hands-on lab that I wrote for the latest release of the Windows 7 Training Kit that shows how to take a Win32 dialog with a tab control and multiple tab pages, and turn each tab page into a thumbnail with a preview.

You can go ahead and do the hands-on lab—there’s a fairly comprehensive document that tells you everything you need to along the way—or you can read this (more brief) description.

What you need to do to support “tabbed thumbnails” is the following:

If your application process has a high integrity level (e.g. if it’s usually launched as administrator), make sure that the DWM messages can pass through, or else they will be filtered by UIPI. Specifically, call the ChangeWindowMessageFilter API and enable the WM_DWMSENDICONICTHUMBNAIL and the WM_DWMSENDICONICLIVEPREVIEWBITMAP window messages to pass through.
Figure out a way to grab a live bitmap rendering of each individual tab—this bitmap must be 32-bit ARGB. This sounds easy, and it indeed might be easy if you have your own custom rendering code. This isn’t easy, however, if you’re just using standard Win32 controls—if the control is not currently visible, you might have to go through hoops to grab a preview of it (e.g. in a TDI application, you could grab a preview of a tab just before switching to another tab).
For each tab window (which is usually a child window), create a top-level proxy invisible window that will deal with the window messaging required to make the thumbnail work. As far as the taskbar and the DWM are concerned, these top-level proxy windows are the ones showing the tab thumbnails, not your application’s “real” tab windows, so all the API calls below have to be performed with the proxy window handles as the parameters. (The reason for this is a limitation of the DWM, which can’t interact with non-top-level windows.)
As you create your proxy windows:

Call the DwmSetWindowAttribute method to set the DWMWA_FORCE_ICONIC_REPRESENTATION and the DWMWA_HAS_ICONIC_THUMBNAIL window attributes. This instructs the DWM to poll your proxy windows for the taskbar thumbnail and live preview.
Register them to appear in the taskbar by calling the ITaskbarList4::RegisterTab method, and set their relative order with regard to the other tabs by calling the ITaskbarList4::SetTabOrder method. (ITaskbarList4 is a minor extension of ITaskbarList3.)

When a tab becomes active, call the ITaskbarList4::SetTabActive method so that this tab’s thumbnail appears as active.
When the proxy window’s procedure receives the WM_DWMSENDICONICTHUMBNAIL message, call the DwmSetIconicThumbnail method and pass to it the window’s thumbnail bitmap. Note that the dimensions of the thumbnail are specified as the high-word and low-word of the lParam message parameter, and you must adhere to these dimensions.
When the proxy window’s procedure receives the WM_DWMSENDICONICLIVEPREVIEWBITMAP message, call the DwmSetIconicLivePreviewBitmap method and pass to it the window’s live preview bitmap. If the window does not overlap the entire application frame, you can use an additional offset parameter to specify the offset of the provided bitmap from the top-left corner of the application’s window. The rest of the window will be captured by DWM automatically for you. (This means that Internet Explorer, for example, doesn’t have to grab a bitmap of the entire window, only of the tab itself. The menus and toolbars could be taken care of by DWM.)
When the proxy window’s procedure receives the WM_ACTIVATE message, switch to the corresponding tab window in your application UI.
When the proxy window’s procedure receives the WM_SYSCOMMAND message, check wParam for the SC_CLOSE code. Any other codes should be forwarded to the application’s main window; SC_CLOSE should be handled by the proxy window’s window procedure (e.g. you can call DefWindowProc that will send you a WM_CLOSE message).

As you can see, there’s a lot of manual labor in having to implement all of this logic every time you want tabbed thumbnails. Even though it’s obviously your responsibility to obtain the thumbnail bitmap and live preview bitmap, and to calculate their offset from the application frame, at least some of the proxy windowing work can be streamlined. For this purpose, the hands-on lab I’ve mentioned earlier provides a TabWindow class, that I will cover in a subsequent post.

Windows 7 RTM Training Kit Updates

Sasha Goldshtein — Sun, 09 Aug 2009 21:24:55 GMT

Windows 7 RTM is out for a few days now for MSDN and TechNet subscribers, and together with the release of the final bits, Microsoft DPE released the final bits of the Windows 7 Training Kit.

Our team at Sela worked days and nights to meet the RTM deadline. Specifically, Alon wrote new multi touch and Libraries hands-on labs, Dima (with Ariel’s help) wrote new labs for the Sensors and Location platform, and I wrote a pair of new labs for taskbar features, one using the final 1.0 release of the Windows API Code Pack and WPF and another using pure Win32 C and C++ code.

Other materials that made it to the training kit have to do with application compatibility on Windows 7. You might have already heard that are hardly any breaking changes from Vista to Windows 7, but if you never made the move to Vista you might find some compatibility problems when testing your app on Windows 7.

To help you with those, the training kit now includes presentations and labs on High DPI, Installer Detection, Session 0 Isolation, UAC Redirection, UIPI and Version Checking—which are among the most common issues developers and testers encounter on Vista and Windows 7, and most of them have been written by our team at Sela.

If you haven’t done so yet, go ahead and install Windows 7 and its SDK, download the training kit and start going through the multitude of features and the hands-on labs that accompany them!