§ ¶Fixing the 3D highlight color in Windows 7

One of the things that's been bugging me about Windows 7 is the washed out look of 3D elements in the composited Aero schemes. The main problem is that the 3D face color is far too hot (240, 240, 240), which is easily fixed in the theme color settings to the Classic value of (212, 208, 200). However, attempting to do so reveals another problem:

The highlight color is too dim, (234, 232, 227). It seems that the Window Color and Appearance dialog doesn't let you edit this color directly, but instead computes it (badly) from the 3D color. I was surprised to discover that this same behavior exists in Windows XP; I probably never noticed it because I could always start from the original scheme. That doesn't work if you have to adjust the 3D face color, though.

A bit of digging in the Win32 API reveals that the problematic system color is COLOR_BTNHIGHLIGHT / COLOR_3DHIGHLIGHT, and there is a function SetSysColor() to change it. Unfortunately, while this does fix the colors, it doesn't save them to the Registry. Fortunately, the themes that you save from the Personalization control panel are text files in the AppData\Local\Microsoft\Windows\Themes directory of the user profile, and there is a simple solution:

ButtonHilight=255 255 255

After making this change and reloading the theme, the 3D element contrast is fixed:

Victory!

The other thing that's been bugging me about the composited themes is the apparent bass-ackward colors for inactive and active windows, where the inactive windows always seem to be brighter than the active window regardless of any fiddling with the color settings... but I haven't found a solution for that yet.

§ ¶VirtualDub 1.9.11 and 1.10.0 released

There are two new versions of VirtualDub now available through SourceForge on the download page.

The first release is a new stable release, 1.9.11. This release contains only one new change over 1.9.10, which is the addition of a filter compatibility mode. When I rewrote parts of the filter system early in the 1.9.x series to support more powerful filters, I hadn't realized that I had broken some filters that relied on the source and output buffer addresses being static (which I think was stated in early filter SDKs). Originally I only knew about two filters that had this issue, but after a few more were discovered I decided a backwards compatibility flag had to be added. In 1.9.11, you can now flag a filter instance as needing static buffers, in which case the filter system will allocate additional bounce buffers and copy frames in and out. This fixes filters that had frame glitch issues, at the cost of a slight amount of overhead.

1.10.0 is the new experimental version and is, for lack of a better description, flushing out everything I had in my dev branch. (The version number is a bit goofy, but I couldn't bring myself to call it 2.0.) It contains all fixes in the stable branch through 1.9.11, as well as new features:

• Multithreaded filter system. This is enabled via Options | Preferences | Threading, and it allows multiple filters in the same chain to execute concurrently. For API reasons it isn't possible to run the same instance in parallel, so this won't help if you only have one filter, but if you have more than one, they can run in parallel and make use of multiple cores. This can work with any filter, but it may break some filters that were relying on back channels to pass data (thus the option).
• Multithreaded video compression. Similarly to filters, codecs also generally can't be run in parallel without special support from the codec. However, a special case is codecs that produce a format with only key frames, such as Huffyuv. 1.10.0 now allows the codec thread count to be raised above 1 for this case to use multiple CPU cores for compression.
• Raw video support. 1.10.0 now includes input and output modules for video streams written as a stream of raw frames. Almost any format supported by the internal blitter library can be read or written, and thus encoding, color space, scan line alignment, and orientation can all be specified.
• Enhanced color space support. The internal blitter library now supports a wider variety of formats, including full-range YCbCr and planar Rec. 709 encodings. Support for these is limited but will be expanded over time; the "alias format" filter allows some types of mistagged formats to be corrected such that conversions for display or encoding can work properly. The Direct3D9 display driver has also been updated to directly support these formats without an intermediate conversion.
• External encoder support. 1.10.0 can now use external programs for encoding and multiplexing through command-line templates and stdin/stdout data transfer, without requiring support for a VirtualDub-specific plugin API. With appropriate encoding programs, this allows encoding to formats that aren't internally supported, such as H.264. This also makes it easier to encode to custom formats, as all that is required is a CLI program that accepts raw data through stdin.

Full change lists for the two versions after the jump. Happy holidays, everyone!

§ ¶Altirra 1.8 released

Version 1.8 of Altirra, my 8-bit Atari emulator, is now available on its home page. Highlights are: 5200 support, many debugger improvements, DirectSound support, more cartridge mapper modes, R: emulation, a cheat finder, and many bug fixes. In addition, you'll also find a link on that page to Acid800, an 8-bit Atari emulator test suite. Enjoy!

§ ¶You forgot to mention a small detail

Hmm, looks like someone says my program crashed, and sent me the minidump. Excellent! Let's load it in WinDbg, my favorite tool for post-mortem debugging (since it offers more control than Visual Studio):

(8.9): Unknown exception - code 80000101 (first/second chance not available)
eax=00000000 ebx=00004120 ecx=00004120 edx=00000006 esi=f75d5079 edi=f75f4ff4
eip=f779d430 esp=0033e818 ebp=0033e830 iopl=0         nv up ei ng nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0063  gs=006b             efl=00200296

I don't recognize that exception code. The PC value is a bit weird, too -- that's in kernel address space for 32-bit Windows, even with /3GB. Well, let's set up symbols and dump the stack.

0:003> .sympath e:alt17
Symbol search path is: e:alt17
0:003> .symfix+ f:symbols
0:003> .reload
.................................
0:003> k
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll

That's weird, the symbols for this system's ntdll.dll aren't on the Microsoft public symbol server? What's loaded on this system?