Steven Engelhardt

In the Windows XP login screen, the password text box will warn you with a balloon tooltip if you accidentally turn Caps Lock on:

The balloon tooltip appears to be a Windows tooltip common control with the TTS_BALLOON style.

To replicate this functionality, I decided to write a function called ShowMsgBalloon() which, given a control and the various balloon tooltip parameters, creates and shows the balloon tooltip below the control.

The key insight to making ShowMsgBallon() work as intended was to use the TTF_TRACK option to create a tracking tooltip. This will immediately show the tooltip without requiring the user to position the mouse over the control. The main downside to using TTF_TRACK is that the tooltip will not move with the control if the window is moved; you need to manually move the tooltip using TTM_TRACKPOSITION as required. One could probably make this automatic by subclassing the tooltip’s parent control and handling WM_WINDOWPOSCHANGED messages.

Here is the source code to ShowMsgBalloon(). When you are done with the balloon, call DestroyWindow() on the returned HWND. Note: you may want your application to use comctl32.dll version 6 as it will lead to a nicer visual style, including a close button.

Let’s say you have the following function:

What happens if this function is exported as an ordinal function from a DLL (not an inlined piece of code inside a header) and you call it from an EXE?
Read the rest of this entry »

While reading the paper Dynamic Storage Allocation: A Survey and Critical Review, I quickly focused on the claim that one requires actual memory allocation traces, as opposed to simulated data, in order to properly design an optimized memory allocator. After my experience with Win32 LD_PRELOAD, I knew that I could implement a minimally invasive memory trace mechanism for existing Windows binaries. So I did.

My first task was to write a program which would launch the application we wanted to trace and log its calls to the Windows memory allocation functions. As I recommend on my Win32 LD_PRELOAD page, I used Microsoft Research’s Detours, rather than Win32 LD_PRELOAD, for the mechanism to intercept Windows function calls. The only functions I chose to intercept were HeapAlloc and HeapFree; these functions seem to be the workhorses of the Windows memory allocation world.

When my code detects a call to HeapAlloc or HeapFree, it logs basic information about the call to a file and then forwards the call to their real implementations. Reentrancy was an issue; the process of logging could potentially cause another allocation, so I had to guard against that. A more robust application would also consider multithreading scenarios more carefully.

For performance and space considerations, I decided the allocation logger would write log entries as binary records into a file. An allocation log record is 17 bytes long; a free, 13 bytes. However, memory operations are so frequent that a one minute browsing session in Firefox (including a quick visit to Google Reader), generated a 14 megabyte log file. Furthermore, the logger introduced a noticeable, although not drastic, performance hit.

With the Firefox log file in hand, I wrote a few post-processing scripts in Python to calculate some useful data, including total cumulative memory usage and a memory allocation frequency histogram. I then used Gnuplot to graph the results.

Here is the total cumulative memory usage graph for my short Firefox browsing session:

Here is the memory allocation frequency histogram. Note the log-log scale; Firefox (like most applications) is so dominated by very small allocations that the graph is useless without it. The graph has a huge spike of allocations with very small object sizes and, somewhat interestingly, a moderate one with sizes just under 10 KB.

Here is the source code to the memory trace logger.

Like many common controls, the tooltip control supports custom drawing for maximum flexibility. This is a quick tutorial on how to use the tooltip custom draw facility.

Read the rest of this entry »

To convert a HFONT to a LOGFONT, use the GDI function GetObject(), as in:

The code is trivial but the function took me forever to find.

Microsoft has created a new, lightweight C++ XML processing library called XmlLite. It includes a streaming XML writing class patterned after .NET’s System.Xml.XmlWriter.

This library makes the IXmlWriter in Implementing IXmlWriter Series obsolete for Windows developers.

While Windows supports dozens or even hundreds of languages, its localization APIs require quite a bit of getting used to. Below is how I solved some common problems related to formatting and parsing a number for a specific locale.

Formatting a Number for a Locale

The function GetNumberFormat() formats a number for a particular locale. Its simplest usage looks something like:

buf now contains the number 1234567.89 formatted for the user’s default locale. For example, for the English-United States locale, buf will contain “1,234,567.89″; for German-Germany, “1.234.567,89″; for Hindi, “12,34,567.89″.

The format of the lpValue parameter is important. From GetNumberFormat()’s MSDN documentation:

lpValue

[in] Pointer to a null-terminated string containing the number string to format. This string can only contain the following characters. All other characters are invalid. The function returns an error if the string indicated by lpValue deviates from these rules.

• Characters ‘0′ through ‘9′.
• One decimal point (dot) if the number is a floating-point value.
• A minus sign in the first character position if the number is a negative value.

Given these constraints, I’ve found the easiest way to convert, say, a double to a string for use as lpValue is to use StringCchPrintf() (or, equivalently, wnsprintf() or _sntprintf()), as in:

One caveat: GetNumberFormatDbl() does not deal well with very small numbers (below 1e-5 or so).

Parsing a Localized Number String

I spent a lot of time trying to figure out the best way to parse a localized number string until Michael Kaplan mentioned VariantChangeTypeEx(). Once I had that, the rest was (relatively) easy:

Using VarR8FromStr() instead of VariantChangeTypeEx() is also an option.

Customizing of the Output of GetNumberFormat()

If you pass NULL as the lpFormat parameter to GetNumberFormat(), you use the locale’s default number formatting information. I often find this to be unacceptable — for example, many times I want to control the number of fractional digits I display. To do this, you need to provide a filled-in NUMBERFMT structure to GetNumberFormat().

I suggest starting with the locale’s default NUMBERFMT and then change only the members you require. Because Windows does not seem to provide a way to retrieve a locale’s default NUMBERFMT, we’ll have to roll our own.

To populate the members of NUMBERFMT we are going to use the function GetLocaleInfo(). The map between NUMBERFMT members and LCTYPEs to pass to GetLocaleInfo() is as follows:

GetLocaleInfo() always returns strings, but many of these strings need to be converted to UINTs. Furthermore, the conversion between the LOCALE_SGROUPING string and the Grouping member is quite tricky; read How to fill in that number grouping member of NUMBERFMT for more information.

We now have enough information to write the function to retrieve a locale-default NUMBERFMT:

Now that we have these functions, we can use them to better control the output from GetNumberFormat(), as in:

Windows Vista developers beware: Vista does not perform file virtualization on the creation of shell links. Consider the following code:

One might expect that the creation of the file C:\Program Files\sol.lnk would be silently redirected by Vista using file virtualization and CreateLink() would succeed, but it doesn’t — the call to IPersistFile::Save() returns E_ACCESSDENIED.

For more information about developing on Vista, see the document Windows Vista Application Development Requirements for User Account Control Compatibility.

Windows C++ developers remain all too familiar with the standard Windows crash dialog. This post is an attempt to teach developers how to understand the data the crash dialog reports to diagnose difficult issues. A basic understanding of assembly language is assumed; for more background on these topics please read Matt Pietrek’s “Under The Hood” articles in the Microsoft Systems Journal February 1998 and June 1998 issues.

Read the rest of this entry »

In an effort to EOL MSXML 4 and encourage developers to use MSXML 6, the MSXML team is going to kill-bit MSXML4 in Q4 2007. This means that you will no longer be able to create instances of MSXML 4 from within Internet Explorer.

Be sure to update your applications accordingly. For this, the MSXML team’s post Upgrading to MSXML 6.0 may prove quite useful.