words

Problem

Running the retail/release version of Windows 10, every time I got a UAC prompt or 'toast' notification, the notification sound would be at full volume. I'd go into the Volume Mixer, run it down to around 5%, and sure enough, the next notification ding would be ear-piercing again.

I've found one other person reporting the same bug on a pre-release version.

Workaround

I've found that leaving the Volume Mixer window open prevents the issue from occurring. Then again, after a few test cycles, I stopped getting ANY System Sounds at all...

Other Details

I use a Creative USB Sound Blaster HD and have all other audio output devices disabled. I don't know if this affects the issue.

My Kinesis Classic doesn't have a Windows key (well, technically it does, but it's embedded in the 'keypad' map Print Screen). I like to remap the Insert key to the Windows key. Here's how to do it:

1. Press the Keypad key
2. Press Program + F12
3. Press Print Screen
4. Press the Keypad key
5. Press the Insert key
6. Press Program + F12

If you omit step 4, then the Insert key will only be mapped to the Windows key when they Keypad map is active (where "Keypad map" means the alternative keymap that becomes active when you hit 'Keypad'. By default it turns the right half of the keyboard into a numeric keypad).

Apparently you now have to run the Windows App Certification Kit (WACK) on the software executables you publish in order to avoid a moderately scary warning from Windows SmartScreen.

Upon running WACK, you're presented with four options:

• Validate Windows Store App

• Validate Windows Phone App

• Validate Desktop App

• Validate Desktop Device App

All of them seem pretty self-explanatory, except for the last one, "Validate Desktop Device App". It's described as "Test a desktop device app for compliance with value-added software requirements". Huh?

Searching Microsoft and MSDN for the phrase "value-added software requirements" turns up zero results. Searching for just "value-added software" (isn't all software value-added?) led me to this post on Raymond Chen's The Old New Thing blog which indicates that "value-added software" is the crapware/shovelware that's pre-installed on computers bought at, say, Best Buy.

I really wish Microsoft would focus less on consistent branding and more on actually explaining things. Incidentally, I gagged a little bit when I read the phrase "Validate Desktop App".

Here are the minimum steps required to self-sign an executable for development and testing:

makecert -sv mykey.pvk -n "CN=MyCompany" -len 2048 mycert.cer -r
pvk2pfx -pvk mykey.pvk -spc mycert.cer -pfx mycert.pfx -po mypassword

Note: You'll be prompted to create a certificate password and it must match whatever you supply to pvk2pfx with the -po switch.

To sign an executable, use:

signtool sign /f mycert.pfx /t http://timestamp.comodoca.com/authenticode /v executable.exe

Note: once you have a real code signing certificate, you'll use whatever timestamp server your provider gives you. Comodo works fine for self-signing testing purposes.

To automatically sign a binary at build-time in Visual Studio, add go to your Project Settings | Build Events | Post-Build Event, and add something like this to the Command Line setting:

signtool sign /f MyCertificatePath\mycert.pfx /p mypassword /t http://timestamp.comodoca.com/authenticode /v $(TargetPath)

Explanation of makecert command:

-sv Specifies the private key file.

-n Specifies the certificate name.

-len Generated key length, in bits. This StackOverflow answer indicates that Microsoft released an update blocking certificates with keys under 1024 bits long.

-r Specifies self-signed, i.e. not a root certificate.

The Windows Console doesn't support Unicode. It does, however, support Double Byte Character Sets using Code Pages. By changing the system locale, the Console can display Japanese, Korean, and Chinese text:

Terminology

UTF-8 and UTF-16 are types of Unicode. However, it's common on Windows to refer to UTF-16 as Unicode, and UTF-8 as UTF-8. I will follow this convention. DBCS (Double Byte Character Set) is the only type of MBCS (Multi Byte Character Set) supported by legacy (i.e. non-Unicode) Windows applications. Japanese, Chinese, and Korean are supported via DBCS encodings. None of these DBCS encodings are Unicode, and all of them are proprietary Microsoft implementations of other standards.

Code Pages Supported by Windows

Windows supports four Double Byte Character Set code pages:

• 932 (Japanese Shift-JIS)
• 936 (Simplified Chinese GBK)
• 949 (Korean)
• 950 (Traditional Chinese Big5)

The available code pages are determined by your System Locale. If your System Locale is set to "English (United States)", then these code pages will be unavailable to you. In this post, I will only be covering Japanese, since it's the only language with which I have any familiarity. The steps and results would be similar for the other languages.

How to Change System Locale

To change your system locale, go into "Change date, time, or number formats":

Select the Administrative tab, and click on "Change system locale". Select the new system locale, click OK, and reboot. The system must be rebooted to change the system locale:

Windows Console Font and Code Page

The font typically recommended for Japanese output is MS Gothic. I have, however, found that Japanese text displays with the Terminal font selected, but it's entirely possible that the UI is lying to me.

To change the Windows Console code page, use the chcp command. chcp with no arguments will display the active code page.

Code Page 932 (Japanese Shift-JIS)

With the code page set to 932 (Japanese Shift-JIS), the path separator character will change into the Yen symbol (because only the backslash and tilde characters differ from ASCII in the lower 7-bits of Shift-JIS). Japanese file names will display in Japanese, as will text saved as Unicode. Japanese text saved as UTF-8 will display as gibberish:

Code Page 65001 (UTF-8)

I have found that it will sometimes work to set the code page to 65001 (UTF-8). Japanese filenames, Japanese Unicode file content, and Japanese UTF-8 content will all three display, as shown below. However, when I experimented with this it stopped working after changing fonts and code pages a few times. My final impression is that it should work, but that the Console has some bugs in this regard.

Here's a screen shot of the Console after code page 65001 stopped working as expected:

References

• Code Pages Supported by Windows (MSDN)
• Encodings of Japanese (sci.lang.japan FAQ)