An intro to using Taskbar progress bars and overlay icons with your Windows 7 applications
Introduction
One of the major changes to how the Windows 7 Taskbar operates is in an area that Microsoft calls peripheral status. This covers two types of status indicators: progress for long operations, and icons for important notifications. Apps can continue to use progress dialogs during long operations, but the Windows 7 Taskbar lets the app show a progress bar in its Taskbar button as well, so the user can see the progress indicator at a glance, without having to switch to the app.
Many apps also use the notification area to convey important status information. For example, Outlook shows an icon when you have new email. However, in Windows 7, notification area icons are hidden by default, so the notification area is no longer useful for displaying this kind of status. The Taskbar lets an app display a 16×16 icon that is overlaid on the existing icon in its Taskbar button. This prevents the notification area from getting too crowded, and keeps the status icon visually associated with the app that created it.
This article’s sample app is a re-write of the file downloader from my article Using Internet Explorer to download files for you. The app shows the download progress in its Taskbar button, in addition to a traditional progress bar in the dialog. This app didn’t have a notification area icon before, but for the purposes of demonstrating the API calls involved, it has commands for showing a status icon as well.
The sample code for this article was built with Visual Studio 2008, WTL 8.0, and the Windows 7 RC SDK.
Codeproject
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and “fiddle” with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more.
!exploitable Crash Analyzer – MSEC Debugger Extensions – !exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment. The tool first creates hashes to determine the uniqueness of a crash and then assigns an exploitability rating to the crash: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown. There is more detailed information about the tool in the following .pptx file or at http://www.microsoft.com/security/msec. Additonally, see the blog post at http://blogs.technet.com/srd/archive/2009/04/08/the-history-of-the-exploitable-crash-analyzer.aspx, or watch the video at http://channel9.msdn.com/posts/PDCNews/Bang-Exploitable-Security-Analyzer/.
API spying utilities are the most powerful tools for exploring the internal structure of applications and operating systems. They provide tons of information and enable the user to explore the “guts” of the application under test. Unfortunately, most API spying utilities can monitor only one application at a time and also have the tendency to break apart when used with large pieces of code. APISpy32 is a different type of API interceptor which solves most of these problems. It monitors API calls made by ALL active Windows applications and logs the values of input parameters. This version works under Windows 9x/NT/2000 and ME.
Download local version of APISpy32.
Homepage
This utility will continuously track the focus input. It updates itself every second, displaying information about the window, which currently has focus. In a sense it is very similar to the popular SPY++ utility from the Developer Studio package, but it is easier to operate and may give you faster results.
Download local version of FocusFlasher.exe (source code)
Homepage
WinSpy++ is a handy programmer’s utility which can be used to select and view the properties of any window in the system. WinSpy is based around the Spy++ utility that ships with Microsoft Visual Studio.
Download local version of WinSpy++ 1.7 (source code).
Homepage
The desktop composition feature, introduced in Windows Vista, fundamentally changes the way applications display pixels on the screen. When desktop composition is enabled, individual windows no longer draw directly to the screen or primary display device as they did in previous versions of Microsoft Windows. Instead, their drawing is redirected to off-screen surfaces in video memory, which are then rendered into a desktop image and presented on the display.
Desktop composition is performed by the Desktop Window Manager (DWM). Through desktop composition, DWM enables visual effects on the desktop as well as various features such as glass window frames, 3-D window transition animations, Windows Flip and Windows Flip3D , and high resolution support. For more information about the user experience features enabled by the DWM visit the Windows Vista: Features user experience page.
Many of the DWM features can be controlled or accessed by an application through the DWM APIs . The following documentation describes some of the features and requirements of the DWM APIs.
In modern versions of Windows (XP, Vista, and beyond), the API call SetForegroundWindow() will bring the specified window to the foreground only if it’s owned by the calling thread. The following code removes this limitation and provides a workaround:
void NewSetForegroundWindow(HWND hWnd)
{
if (GetForegroundWindow() != hWnd)
{
DWORD dwMyThreadID = GetWindowThreadProcessId(GetForegroundWindow(), NULL);
DWORD dwOtherThreadID = GetWindowThreadProcessId(hWnd, NULL);
if (dwMyThreadID != dwOtherThreadID)
{
AttachThreadInput(dwMyThreadID, dwOtherThreadID, TRUE);
SetForegroundWindow(hWnd);
SetFocus(hWnd);
AttachThreadInput(dwMyThreadID, dwOtherThreadID, FALSE);
}
else
{
SetForegroundWindow(hWnd);
}
if (IsIconic(hWnd))
{
ShowWindow(hWnd, SW_RESTORE);
}
else
{
ShowWindow(hWnd, SW_SHOW);
}
}
}
Another (but more intrusive and restrictive) way to make SetForegroundWindow() behave the same way as it did on Windows 95 and Microsoft Windows NT 4.0 is to change the foreground lock timeout value SPI_SETFOREGROUNDLOCKTIMEOUT, as described in this MSDN document.
Reference
Note: This paper is derived from the book The Security Development Lifecycle, by Michael Howard and Steve Lipner, Microsoft Press, 2006.
Prohibiting the use of banned APIs is a good way to remove a significant number of code vulnerabilities — this practice is reflected in Stage 6 of The Microsoft Security Development Lifecycle: “Establish and Follow Best Practices for Development.” It can also be referenced in Chapter 11 of the Microsoft Press Book The Security Development Lifecycle.
When the C runtime library (CRT) was first created about 25 years ago, the threats to computers were different; machines were not as interconnected as they are today, and attacks were not as prevalent. With this in mind, a subset of the C runtime library must be deprecated for new code and, over time, removed from earlier code. It’s just too easy to get code wrong that uses these outdated functions. Even some of the classic replacement functions are prone to error, too.
This list is the SDL view of what comprises banned APIs; it is derived from experience with real-world security bugs and focuses almost exclusively on functions that can lead to buffer overruns (Howard, LeBlanc, and Viega 2005). Any function in this section’s tables must be replaced with a more secure version. Obviously, you cannot replace a banned API with another banned API. For example, replacing strcpy with strncpy is not valid because strncpy is banned, too.
Also note that some of the function names might be a little different, depending on whether the function takes ASCII, Unicode, _T (ASCII or Unicode), or multibyte chars. Some function names might include A or W at the end of the name. For example, the StrSafe StringCbCatEx function is also available as StringCbCatExW (Unicode) and StringCbCatExA (ASCII).
More info
