Monday, May 8, 2017

GitExtensions And Visual Studio 2017

I just finished installing Visual Studio 2017 and one of my favourite extensions, GitExtensions, For Visual Studio 2017, for now, a temporary version of GitExtensions must be installed, due to the changes in add-in architecture. The direct link for this, for now, is

Upon getting everything installed and configured as desired, I proceeded to try to sync with an existing repo, hosted on a personal, internal Git server. This server is running HTTPS with an internal, Active Directory CA-generated, certificate. Naturally, this certificate is not normally trusted by Git.

Following the excellent guide located here,, I was able to get Git and the GitExtensions application to push/pull as expected from the repo. However, trying a sync in Visual Studio 2017 failed with the message "SSL certificate problem: unable to get local issuer certificate".

After much digging, I was able to find out that in Visual Studio 2017, due to the change in add-in architecture, the GitExtensions add-in is actually running out of the directory C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\. Therefore, any of the path references regarding configs, .crt, and .pem files in the article above need to be adjusted to point to this path, particularly if the internal certificate information will be added to the computer-wide .crt file.

Hopefully, this information will help someone else as well. I was unable to find a direct reference to this new path, as VS2017 is still rather new. I ended up using SysInternals' excellent tool, procmon.exe, to watch all the file activity until I found the reference to the path being used to run the git.exe command from a VS2017 Git Sync operation.

Friday, April 15, 2016

Windows 10 File Explorer Tweaks

If you're anything like me, you may like having things just so. I'm putting the finishing touches to a brand new AD domain (for personal use) and was creating the GPO for all of my commonly-used settings.

Part of those settings involved getting File Explorer tweaked to match all of the common preferences I like to use. Some of those involve Quick Access; namely, turning off the two options highlighted below: Show recently used files in Quick access and Show frequently used folders in Quick access. I go through an extraordinary number of files and folders on any given day (this is a development computer) and these two settings tend to clutter up things.

These can be easily turned off manually, but I was trying to get them turned off via a GPO so that it would apply to all my Windows 10 computer simultaneously. A preliminary search failed to turn up anything of interest, so I took to ProcMon, a tool from SysInternals, and had it watch the registry for any changes while I made the adjustment.

After some sifting through the logs, I finally found both registry paths. I've listed them below. I hope that this helps out someone else who may want to GPO these items.

Show recently used files in Quick access
  1. Open the Registry Editor
  2. Navigate to HKCU\Software\Microsoft\CurrentVersion\Explorer
  3. Create a REG_DWORD value called ShowRecent
  4. Set the value to 0 to uncheck the option and 1 to check the option
Show frequently used folders in Quick access
  1. Open the Registry Editor
  2. Navigate to HKCU\Software\Microsoft\CurrentVersion\Explorer
  3. Create a REG_DWORD value called ShowFrequent
  4. Set the value to 0 to uncheck the option and 1 to check the option

Monday, July 1, 2013

Bughouse Rules

Bughouse is a chess variant that is played with two teams of two players each. The rules of bughouse follow most of the standard rules of chess with the exceptions outlined below:

  1. Each team will have one person playing with the White pieces and one person playing with the Black pieces
  2. Partners are allowed to communicate freely throughout the entire game
  3. Partners will give each other captured pieces (when White captures a Black piece, he or she will give that piece to his or her partner and vice versa)
  4. Players, during their turn, may choose to either move a piece on the board (following regular chess rules), or may place one of the received pieces (from rule 3) on the board (this counts as that player's turn!). When placing pieces, the following rules apply:
    1. The square must be unoccupied
    2. Pawns may not be placed on the first or last ranks (rows)
    3. The placed piece is allowed to put the enemy king in check upon being placed
    4. The placed piece is allowed to put the enemy king in checkmate upon being placed
  5. Upon reaching the last rank, pawns promote as normal. However, the pawn is placed on its side and the new piece is communicated to the opponent. If the promoted pawn gets captured, it reverts back to a pawn (the capturing player's partner will only receive a pawn)
  6. Calling check is not required; if a player fails to see that their king is in check, their opponent can capture the king, thus ending the game
  7. If a player is in checkmate, but would have the opportunity to block if given a piece, they must wait until their partner succeeds in capturing a piece that would be a legal blocking piece
  8. King captures, checkmates, and any illegal move ends the game (if a player notices an illegal move on the part of their opponent, they may declare an illegal move and "capture" the opponent's king, ending the game)
  9. A team wins as soon as one of its players checkmates their opponent, captures their opponent's king, causes the opponent to run out of time, or flags their opponent's move as illegal
General Notes:

Timed Play: bughouse is generally played with chess clocks set to five (5) minutes, or less, for each player. When a player's time runs out, their opponent can call time to win the game. Only the player's opposing team can call time. If the opposing team does not notice, the game continues as normal.

When playing with clocks, the touch move rule is also not in effect. A player's move is final as soon as that player presses their clock.

Stalling: when playing with clocks, it is legal for any player to "stall". Stalling is simply the action of not making a move until a certain condition is met. For example, a player may desire a particular piece and can wait until their partner succeeds in capturing that piece. If a stalling player's clock runs out, they lose on time, if their opponent notices.

Spectators: spectators are not allowed to comment on a game in progress (unless agreed upon by all four players ahead of time).

Tuesday, June 11, 2013

June 2013 Sheboygan, WI Chess Blindfold Simul

June 10, 2013 was a day to remember for the chess-playing community of Sheboygan, WI. The weather was flawless for the Chess-in-park event at Vollrath Park. About 25 chess-players showed up to play chess and for the featured event: a blindfold simultaneous exhibition. More details on the event, pictures, and stories can be found on the website for The Chess Club of the Sheboygan Area.

The games played in the simul were written down and I've put together the complete collection below for everyone's viewing pleasure. Please feel free to pass a link to this page along to any family and friends who are interested in seeing the games.

Board 1

Board 2

Board 3

Board 4

Board 5

Board 6

Board 7

Board 8

Board 9

Board 10

Board 11

Board 12

Board 13

Friday, July 13, 2012

Windows 7 Default Audio Device Changer - Part 2

Sometimes life gets busy and things you intended to do pass you by. I wrote a post nearly a year ago on a utility to programmatically change the default audio device in Windows 7, but forgot to follow through and post the code.

Thanks to a reminder from someone who found this post useful, Deliang Ye, I have put together a small GitHub repository with all the necessary code for this project:

I hope someone else can find this useful as well!

Saturday, July 30, 2011

Windows 7 Default Audio Device Changer

There are a number of posts on the internet regarding programmatically switching the default audio device in Windows Vista and Windows 7. I recently encountered this issues as well. I had purchased a USB headset.

The issue started from there. I did not want to have to plug and unplug the headset every time I wanted to use it, nor did I want to go to the Control Panel and manually change the default playback and recording devices.

Therefore, I started searching online to find a method. It appears that Microsoft does not support this in any way in Windows Vista and 7. I did discover that one of the program managers for Windows might pass this issue along to the developers for consideration, so we may not be out of luck in the next version.

The searches ended up revealing a number of methods to perform the change. I took a number of the suggestions, code snippets, helper DLLs, and came up with a solution of my own. All the source websites are credited in the list below and I am very grateful for their detailed groundwork.

The main points are as follows:
  • Enumerate a list of all rendering (output) and capture (input) audio devices in the system via the registry for easiest access
  • Use the unsupported Microsoft interface IPolicyConfig to actually make the switch
  • Develop a command-line application that can perform all the default audio device switching with a minimum of intervention and callable from AutoHotkey
This forum post on AutoHotkey is what got me started. However, as astutely observed by many others before me, Windows 7 did not support most of the non-UI methods that were described in this post. I first landed on Dave Amenta's site, which contained a full-functional application to do exactly what I wanted, minus the recording devices. Dave definitely has one of the best samples on the usage of IPolicyConfig I could find and I highly recommend his site for additional details.

I continued digging and eventually found an excellent set of references in this Microsoft forum post. In this post, I am deeply indebted to ghoster_e, albain, and EreTIk. albain got me started with his excellent reference on reading the writing the necessary registry entries to get and set the default audio device. However, this method did not notify any running applications that the default changed, necessitating restarting that application for it to recognize the change.

ghoster_e had some great information on the unsupported IPolicyConfig COM interface, along with some snippets of code. EreTIk also maintains a very useful website that includes this full C++ header file for inclusion in a C++ project.

This almost got me to where I needed to be. However, as I was writing this entire project in C#, I did not want to have to make the necessary COM conversions to use those IPolicyConfig interfaces. I searched some more and found Ray Molenkamp's CoreAudio project. This was missing the IPolicyConfig interfaces, but was almost feature-complete.

One more search landed me at MixerProNET; a full .NET-based library (CoreAudio.dll), with all the necessary functions to set the default audio device (both playback and recording) via the IPolicyConfig COM interface that sends out notifications to running applications notifying them of the change.

Once I had this, I was at last in position to finish off my project. I made the last tweaks, setup the necessary command-line parameters for the front-end command-line application and started testing. To my great and lasting enjoyment, all the tests worked. I now had the ability to setup AutoHotkey to trap any necessary keys and fire off my application with parameters indicating which devices I wanted to use as default.

I've included a reference of the application below and will be posting it in a few days.


Allows a command-line method of switching system default audio devices. Tested and found working on Windows 7 x64. Should also work on Windows 7 x86. In both cases, this program must be run as an administrator or with UAC disabled.


        /?                      Brings up this help message
        /list                   Display a list of currently enabled audio devices and the defaults
        /cro                    Returns the ID of the current default output audio device
        /cri                    Returns the ID of the current default input audio device
        /so {guid}              Sets the default output audio device based on a GUID
        /so devicename busname  Sets the default output audio device based on the device
                                name and device bus name (like Speakers, Creative SB X-Fi)
        /si {guid}              Sets the default input audio device based on a GUID
        /si devicename busname  Sets the default input audio device based on the device
                                name and device bus name (like Speakers, Creative SB X-Fi)
        /so devicename busname [devicename] [busname] ...       Switches between default output audio devices in the list of pairs; once it reaches the last one, it cycles back to the first item
        /si devicename busname [devicename] [busname] ...       Switches between default input audio devices in the list of pairs; once it reaches the last one, it cycles back to the first item

This project could not have been realized without the work of all those I've already mentioned in this post. However, to ensure that credit be given where credit is due, I've recapped all the people who've provided the groundwork (in no particular order):