An application appears to be not working in Windows XP in a weird way: rebar control appeared to fail showing up.

Where the application is expected to look much nicer with rebar control as a container for menu (implemented as command bar WTL control) and toolbar with buttons:

A WTL sample project generated by a Visual Studio wizard would never give such effect, and the bug was a combination of factors:

1. An application built with a newer version of Windows SDK, which includes support for features (Windows Vista+ Common Controls) that are more recent than production environment (Windows XP); the application targets to Windows Vista+ environment too (_WIN32_WINNT >= 0×0600)
2. Compatibility issues of Common Controls library
3. WTL version (7.5), which did not yet include a workaround for the problem

The problem, which caused the bug directly was the REBARBANDINFO structure and its use as an argument with Common Controls API. As MSDN shows, the structure was amended twice with additional fields.

One of the way to support multiple versions of the structure definition, and to resolve compatibility issues, is to embed structure size into structure payload. In fact, REBARBANDINFO::cbSize member is there exactly for this reason.

The application is normally filling cbSize with the maximal known structure size and fills the rest of the fields respectively. The API is expected to be checking cbSize member and be detecting API version compatibility scenarios:

1. cbSize holds exactly the value the API expects (that is, the maximal value known/defined to the API) – the simplest scenario where the API and the application are on the same page, both are using the same versions of the “protocol”/interface.
2. cbSize is smaller than API can support – the API sees that it is dealing with a sort of legacy application which cannot utilize all available features, and the API acts respectively supporting the older part of the protocol, and keeping defaults or “old look” for the rest of implementation. This addresses backward compatibility: the newer API works with apps designed for older version of the API
3. cbSize is greater then API can support – the API sees that the application is already aware of newer version API and is possibly requesting some of the missing features. The API might be ignoring the unsupported part in assumption that API evolution tool place keeping some compatibility in mind, and still do the best it can with the existing implementation. Or, the API might just fail to work.

The latter item #3 is the scenario here with rebar control. The application is using Windows Vista version of REBARBANDINFO structure and Windows XP implementation choses to completely fail.

While it does not seem to be directly a bug, this attitude is definitely not developer friendly: there is no reason for the control to not work in its best and default way. Having API acting this way, each developer using the API needs to take care of the situation explicitly: whenever Windows Vista enabled application needs to be able to run in Windows XP system, the code around REBARBANDINFO would look like this:

REBARBANDINFO BandInformation = { sizeof BandInformation, RBBIM_LPARAM };
#if _WIN32_WINNT >= 0x0600
if(GetOsVersion() < 0x00060000 || GetCommCtrlVersion() < 0x00060000) // pre-Vista, Common Controls pre-6.0
    BandInformation.cbSize = REBARBANDINFO_V6_SIZE;
#endif// _WIN32_WINNT >= 0x0600
const BOOL bGetBandInfoResult = Rebar.GetBandInfo(0, &BandInformation);

If the API was nicer to developers, the code would be plain and simple:

REBARBANDINFO BandInformation = { sizeof BandInformation, RBBIM_LPARAM };
const BOOL bGetBandInfoResult = Rebar.GetBandInfo(0, &BandInformation);

To address this problem, WTL 8.0 comes up with RunTimeHelper namespace and its SizeOf_REBARBANDINFO function. It takes care of details for the developer choosing the proper size of the structure on runtime. The code is being taken back to a simpler shape:

REBARBANDINFO BandInformation = { RunTimeHelper::SizeOf_REBARBANDINFO(), RBBIM_LPARAM };
const BOOL bGetBandInfoResult = Rebar.GetBandInfo(0, &BandInformation);

All in all:

• be aware of compatibility issues (same scenario exists with other SDK structures: LVGROUP, LVTILEINFO, MCHITTESTINFO, NONCLIENTMETRICS and other).
• use latest version of WTL to have things worked around for you where Microsoft developers were not kid enough to provide perfect API
• be aware and take advantage of WTL’s RunTimeHelper class

Windows Vista introduced new synchronization API: slim reader/writer (SRW) locks. Being already armed with critical sections, one perhaps would not desperately need an SRW lock, but still it offers a great option to provide both exclusive (critical section alike) mode and shared mode when 2+ threads can enter protected section simultaneously. Some time earlier, I already touched SRW lock recursion issue.

This time it is more about performance. Let us suppose we have a code fragment:

static const SIZE_T g_nCount = 100000000;
for(SIZE_T nIndex = 0; nIndex < g_nCount; nIndex++)
{
    AcquireSRWLockShared(&m_Lock);
    ReleaseSRWLockShared(&m_Lock);
}

How fast is this? Provided that execution took 1.6 ms on an idle lock variable, how fast it is going to be with another shared “reader” on another thread who acquired once access in shared mode? This part comes up confusing: it appears almost twice as slow: 2.9 ms, with also a number of contentions (and context switches) on the way.

SRW lock is advertised as lightweight and fast API, no recursion, no extra features, no fool proof checks. So it could be assumed to get you top performance, but 50 lines of code class can definitely outperform it.

A perhaps simplest SRW lock can be backed on a LONG (or LONGLONG) volatile variable accessed with interlocked API functions. The rules are simple:

• initial value of zero means idle state
• shared “reader” enters incrementing by one, positive values indicates one ore more readers
• exclusive “writer” enters decrementing by a hundred (well, this needs to be any value big enough to be less than minus maximal amount of simultaneous concurrent readers)
• releasing acquired state the value is decremented (incremented) back
• in case of contention thread yields execution to continue later with possibly better luck with shared resource (option: implement spic count for several attempts in a row, which is better suitable for multi-processor systems)

It is clear that concurrent readers touch value only once with a single increment only, leaving no opportunity to yield execution due to contention. How fast it can be?

static const SIZE_T g_nCount = 100000000;
for(SIZE_T nIndex = 0; nIndex < g_nCount; nIndex++)
{
    while(InterlockedIncrement(&m_nNativeLock) < 0)
    {
        InterlockedDecrement(&m_nNativeLock);
        SwitchToThread();
    }
    InterlockedDecrement(&m_nNativeLock);
}

It is 1.3 ms regardless whether there are any shared readers on concurrent threads. It appears that a simple custom SRW lock class is going to be superior to the API:

• faster due to zero API overhead (inline compiled code versus WINAPI convention functions)
• faster in shared mode due to not being subject to additional overhead and contentions
• flexible spin counts possible to tune performance for specific use
• extensibility:
  • recursion is allowed shared mode
  • easy to implement upgrades and downgrades between shared and exclusive modes

Sample code is Visual Studio 2010 C++ project accessible from SVN repository.

Update: Critical Section Test. This is how SRW lock API performance compares to entry/leaving critical section (provided that critical section is never locked at entry time). Critical section is about 15% slower to enter and leave.

C:\Projects\...\SrwLockTest02\x64\Release>SrwLockTest02.exe
API: 100M iterations, 1575 ms
API: 100M iterations, 2839 ms
Native: 100M iterations, 1311 ms
Native: 100M iterations, 1326 ms
Critical Section: 100M iterations, 1841 ms

Windows Vista added new synchronization API, Slim Reader/Writer (SRW) Locks, which is a powerful alternative to critical sections. The detailed description is, as always on MSDN, and what makes it really cool is simple:

• unlike critical sections, SRW Locks provide reader and writer access synchronization making it possible for 2 and more reader to not block one another
• SRW Locks do not reference any resources and have size of a pointer, which is the simplest possible scenario; as a result, they don’t need a destructor and their initialization is simple zeroing of memory/variable (for which you however should use InitializeSRWLock API

Being lightweight they are efficient. To understand how at all they can work, one can imagine that a reader might be trying to InterlockedIncrement a synchronization variable. If result is positive, then it’s OK to go. Otherwise, reader should decrement it back, wait and retry. A writer, instead, does InterlockedAdd with an argument of -0×1000 and checks that result of the operation is exactly -0×1000.

This post is about a trap one cat enter into by neglecting one of the SRW lock warnings:

… so SRW locks cannot be acquired recursively. In addition, a thread that owns an SRW lock in shared mode cannot upgrade its ownership of the lock to exclusive mode.

SRW locks cannot be acquired recursively, but it is very easy to make a mistake. If you attempt to recursively acquire, you are likely to succeed, without a warning, error code, exception or assertion failure. You pass this point and you can write quite some code before you realize something is wrong.

It can be as simple as this:

SIZE_T GetCount() const throw()
{
    AcquireSRWLockShared(&m_Lock);
    const SIZE_T nCount = ...;
    ReleaseSRWLockShared(&m_Lock);
    return nCount;
}
BOOL IsEmpty() const throw()
{
    AcquireSRWLockShared(&m_Lock);
    const BOOL bResult = GetCount() > 0;
    ReleaseSRWLockShared(&m_Lock);
    return bResult;
}

IsEmpty calls GetCount which again attempts to acquire lock.

In multit-hreaded environment the problem may come up in the following scenario: thread A acquires shared lock, thread B attempts to acquire exclusive lock, thread A attempts to re-acquire (recursively) shared lock again and both threads freeze at this point. Note that without thread B recursive locking succeeds on thread A.

SrwLockTest01 project provides a sample code to reproduce the deadlock around misused SRW Lock. RecursiveSharedLock and ExclusiveLock thread functions keep acquiring lock simultaneously, while main thread is monitoring current worker thread positions.

Shared access only worker thread, which does recursive lock, runs just fine alone, if the other concurrent thread is commented out:

CHandle SharedLockThread, ExclusiveLockThread;
SharedLockThread.Attach(AtlCreateThread<INT_PTR>(&RecursiveSharedLock, 0));
//ExclusiveLockThread.Attach(AtlCreateThread<INT_PTR>(&ExclusiveLock, 0));

g_nRecursiveSharedLockLine 27, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 29, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 31, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 31, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 29, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 25, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 27, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 25, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 29, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 29, g_nExclusiveLockLine 0
g_nRecursiveSharedLockLine 33, g_nExclusiveLockLine 0

Status output captures worker thread at random line, and CPU is maxed out on one of the cores.

With concurrent threads, a deadlock takes place very soon:

g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49
g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49
g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49
g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49
g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49
g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49
g_nRecursiveSharedLockLine 35, g_nExclusiveLockLine 49

CPU consumption for the process is nearly zero – threads are in deadlock: shared access thread is i nAPI call at line 36, exclusive access thread is at line 50.

As soon as the problem is clear, a reasonable safety measures are to be taken to avoid misuse. To use SRW Locks safely, it is suggested to use a wrapper class that asserts on misuse in debug builds (to be continued).

Sample code is Visual Studio 2010 C++ project accessible from SVN repository.

See also:

• Slim Reader/Writer (SRW) Locks
• Synchronization Primitives New To Windows Vista

Given the combo box initialization code:

m_ComboBox.SetRedraw(FALSE);
m_ComboBox.ResetContent();
for(INT nIndex = 0; nIndex < 3; nIndex++)
    m_ComboBox.AddString(AtlFormatString(_T("Item %d"), nIndex + 1));
m_ComboBox.SetCurSel(1);
m_ComboBox.SetRedraw(TRUE)

How the combo box is going to look like?

Here it goes:

Combo box won’t repaint window on SetRedraw(TRUE) AKA WM_SETREDRAW. But once you move a mouse pointer over the control, or tab to focus it, the correct selection will be painted, “Item 2″:

The control ignores the invalidation caused by CB_SETCURSEL message while processing final SetRedraw message. To avoid GUI glitches, for example, a m_ComboBox.Invalidate() or InvalidateRect might be called after SetRedraw(TRUE).

One thing is worth special mentioning in connection with previous post on DirectShow Filter Graph Spy on Microsoft Vista system: ATL’s CSecurityDesc class caused to waste some time.

CRegKey Key;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.Open(HKEY_CLASSES_ROOT, pszKeyName, READ_CONTROL | WRITE_OWNER)));
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
AdministratorsOwnerSecurityDescriptor.SetOwner(Sids::Admins());
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, &AdministratorsOwnerSecurityDescriptor)));

The code compiles fine, but on runtime it gives error 87 (ERROR_INVALID_PARAMETER, E_INVALIDARG) in the last line, returned from RegSetKeySecurity API call. My first guess was that ATL’s CSecurityDesc class for some reason prepared wrong descriptor which resulted in rejecting it as an argument. From the first glance it looks (not sure) that this class deals, to some extent, with structures itself rather than using API functions, so it could be that it results in something looking differently from expected by API calls.

Still the problem is in class itself and its cast from CSecurityDesc& to required SECURITY_DESCRIPTOR* type. The class only implements operator to automatically cast to const SECURITY_DESCRIPTOR* type, so the following line would not be passed by compiler:

Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, AdministratorsOwnerSecurityDescriptor)

However &AdministratorsOwnerSecurityDescriptor is another level of indirection and hence SECURITY_DESCRIPTOR** type, which is passed by compiler, but results in indeed invalid argument.

So in order to correctly convert CSecurityDesc& to SECURITY_DESCRIPTOR* it can be done this way:

CRegKey Key;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.Open(HKEY_CLASSES_ROOT, pszKeyName, READ_CONTROL | WRITE_OWNER)));
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
AdministratorsOwnerSecurityDescriptor.SetOwner(Sids::Admins());
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, const_cast<SECURITY_DESCRIPTOR*>((const SECURITY_DESCRIPTOR*) AdministratorsOwnerSecurityDescriptor))));

I decided to download a beta of Windows 7, so many people shared their positive impressions of. I am not quite sure I will have time to actually evaluate it, but for the case I would feel like, it is always nice to have the .ISO image ready for a try.

There was nothing worth a word until I reached the download screen which opened an extremely awful Java applet that pretended to be a download manager. It seemed to be a new spin of technology and sort of I don’t need a nice download manager anymore because direct HTTP links are out of fashion. It started pumping bytes (actually thanks for that) and I my attempt to copy/paste a direct link into my DownThemAll FireFox plugin was vain.

At some 20% the download froze without a notice. The download did not even ungray the resume buttons before I restarted FireFox process and then any attempt to resume led to weird message boxes. Frankly at this point I almost lost the desire to actually complete the download. But left a last chance to have it completed by IE. Internet Explorer (expectedly!) preferred ActiveX control to Java applet. It’s GUI was a bit less scary and it took over incomplete download and…

An attached debugger showed a call stack (oops, I did not save exact call stack) in Manager.exe process in C runtime module, in a CString class method… It went no further than this crashing at exactly the same point until I manually deleted the incomplete download, when it again repeated a weird message box and then finally restart the download from the start. That was enough for me and found a .torrent with the exactly the same file on thepiratebay.org, which I am quite sure will download without a problem.

Isn’t it incredibly stupid that significant amount of work was invested into unnecessary task, ugly user interface, buggy implementation (freeze, incapable download manager, weird messages, crash) with a solid residual of inability to conveniently download the thing, while the file could be just put onto regular MS download service?

I am sharing a couple of utilities to be able to quick check system settings. TimeZoneInformation prints in a human friendly style TIME_ZONE_INFORMATION structure as reported by Windows through GetTimeZoneInformation API.

TIME_ZONE_INFORMATION:
.Bias: -120
.StandardName: FLE Standard Time
.StandardDate: { .wYear 0, .wMonth 10, .wDay 5, .wDayOfWeek 0, .wHour 4, .wMinute 0, .wSecond 0, .wMilliseconds 0 }
.StandardBias: 0
.DaylightName: FLE Daylight Time
.DaylightDate: { .wYear 0, .wMonth 3, .wDay 5, .wDayOfWeek 0, .wHour 3, .wMinute 0, .wSecond 0, .wMilliseconds 0 }
.DaylightBias: -60
[...]

A Visual C++ .NET 2008 source code is available from SVN, release binary included.

And the second utility is MonitorInformation to print multi-monitor related information again as reported by Windows, GetSystemMetrics and EnumDisplayMonitors APIs.

System Metrics:
  SM_XVIRTUALSCREEN: 0
  SM_YVIRTUALSCREEN: 0
  SM_CXVIRTUALSCREEN: 1680
  SM_CYVIRTUALSCREEN: 1050
  SM_CMONITORS: 1
  SM_SAMEDISPLAYFORMAT: 1

Monitor 0 at (0, 0) - (1680, 1050):
  Coordinates (rcMonitor): (0, 0) - (1680, 1050)
  Work Area (rcWork): (0, 0) - (1680, 1026)
  Flags (dwFlags): 0x1
  Device Name (szDevice): \\.\DISPLAY1

A Visual C++ .NET 2008 source code is available from SVN, release binary included.