I built a new PC a few years ago using the Intel 8086K that I won in the Intel 40th Anniversary Sweepstakes. It's been a good machine that I've only really used for games. Over the last year or so I've used it for some more hobby projects and I finally got annoyed with the Downloads special folder always opening up with the contents being grouped by date.

I wasn't terribly surprised to find that this was a common thing people complained about. In the Microsoft Community thread I found about the problem the solution was to basically forcibly set all folder view settings. This is a reasonably straight forward answer and what I believe I'd done on my previous Windows installs. After all, details view is the only right answer, right? :) In the Super User question on the topic it seemed that there was a nicer solution that preserved the existing folder view settings. It also required taking ownership of the key from regedit.exe. But then:

> reg query 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes\{885a186e-a440-4ada-812b-db871b942259}\TopViews\{00000000-0000-0000-0000-000000000000}' /v GroupBy

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes\{885a186e-a440-4ada-812b-db871b942259}\TopViews\{00000000-0000-0000-0000-000000000000}
    GroupBy    REG_SZ    System.DateModified

> reg add 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes\{885a186e-a440-4ada-812b-db871b942259}\TopViews\{00000000-0000-0000-0000-000000000000}' /v GroupBy /t REG_SZ /d System.Null /f
The operation completed successfully.

> reg query 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes\{885a186e-a440-4ada-812b-db871b942259}\TopViews\{00000000-0000-0000-0000-000000000000}' /v GroupBy

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderTypes\{885a186e-a440-4ada-812b-db871b942259}\TopViews\{00000000-0000-0000-0000-000000000000}
    GroupBy    REG_SZ    System.Null

However, even after restarting explorer.exe my Downloads folder was still showing up grouped.

The solution came from another forum thread on the topic which explained the way view settings for special folders are stored in the registry and presented a PowerShell snippet to remove them for the Downloads special folder:

$Bags = 'HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags'
$DLID = '{885A186E-A440-4ADA-812B-DB871B942259}'
(Get-ChildItem $bags -recurse | ? PSChildName -eq $DLID ) | Remove-Item
gps explorer | spps

This also restarted explorer.exe which may not be a surprise, but I don't use PowerShell enough to know gps is Get-Process and spps is Stop-Process. But finally my Downloads folder was showing up in details view sorted by modified like I wanted!

Recently there has been news of Google deploying advertisements more invasive than content banners in their Google TV launcher. Upon experiencing this directly it seemed like a good idea to dig into replacing the launcher.

The first step was testing out alternative launchers. I tried Projectivy Launcher and FLauncher and ended up preferring FLauncher, it is very simple and it's open source which is an added nicety.

The next step was figuring out how to set the default launcher. The most conservative approach was to do some button remapping which led me to Button Mapper which didn't actually work on my Chromecast since it, at least with the free version, didn't even list the Home button as a remappable key. I could add it as a custom button but testing was going to require the paid upgrade. That, coupled with the extra step at every start up of going from the default launcher to the preferred launcher, made more investigation seem like the right answer.

Eventually I came across a guide to disabling the Google TV Launcher which also covered choosing a new default! It basically boils down to using adb commands to disable 2 apps:

pm disable-user --user 0 com.google.android.apps.tv.launcherx
pm disable-user --user 0 com.google.android.tungsten.setupwraith

and then choosing a new default once you press the Home button.

I've only ever used adb with a USB connection. Another guide I came across made mention of ADB TV which is an app that allows running adb commands from the Android environment running on the Google TV. This made it easy to disable the two apps listed.

However, I only disabled the launcherx app. I then exited ADB TV and landed at a black screen. This was rather nerve-racking and after rebooting and pushing various buttons the only response I could get was from the dedicated YouTube and Netflix buttons launching their respective apps. However, pressing back a few times from that put me back in FLauncher for a reason I can't explain. Then, I could re-open ADB TV and disable the setupwraith app which allowed me to choose a new default launcher by pressing the Home button. All told following the guide would have been much easier. Oops.

Everything is working nicely now though!

Additional links:

• https://www.reddit.com/r/AndroidTV/comments/1aefuo6/new_ad_hell_carls_jr_homescreen_ad_with_auto_play/
• https://www.reddit.com/r/Chromecast/comments/1ae37sa/full_screen_video_ads_wtf/
• https://www.reddit.com/r/AndroidTV/comments/154dqd1/ive_had_enough_of_google_chromecast_w_google_tv/

This week at work I was faced with a bug that manifested as Windows XP clients being slower to access parts of a web interface than Windows 7 or 10. This was strange because in Wireshark the requests looked basically the same.

It turned out that the embedded system hosting the web interface was rejecting Ethernet frames larger than 1500 bytes. This was most likely because of a misinterpretation of the MTU as referring to the frame size (at layer 2) instead of the payload size (at layer 3).

The strangest part about this issue was just how consistent the effect was across all browsers tested given a version of Windows. Windows XP took nearly 22 seconds to complete a request that took just over 2 seconds in Windows 7. The core of this behavior ended up being a side-effect of the TCP retransmission timeout.

The default retransmission timeout for Windows XP is stored in the TCPInitialRTT registry value for a given network adapter. The default value when the registry value does not exist is 3000ms. This aligned with the observation under XP that the first retransmission occurred after 3 seconds with subsequent retransmissions occurring at 6 and 12 seconds. The first retransmission was sent unfragmented while the second and third retransmissions were a fragmented version of the original frame, which was ultimately accepted. The fragmented payloads were at most 576 bytes which seemed like an interesting size but I did not investigate.

Windows 7 on the other hand appears to retry after 300 milliseconds, with subsequent retries at 600ms and 1200ms. But the same basic behavior was followed: the first retry was the full payload while the subsequent retries were fragmented into at most 576 byte payloads. The key difference appearing to be the retransmission timeout. This masked the underlying issue for Windows 7 clients.

While I did not search extensively, I did not find an explanation for either the doubling back-off of the retransmissions or the 576 byte payload size.

The rather quick fix was to change the Linux driver to accept frames up to the actual size that could be handled. And introducing an error message if a frame is rejected for length reasons.

A friend asked several people on irc about NameSilo's API and dynamic DNS entries. He found a PowerShell script to update a subdomain with the current IP address of the system running the script. The subdomain detail was the crux of the question: how to get it to update a "naked" domain. Several of us read through the API reference but the dnsUpdateRecord function didn't explain how to update the base domain's A record.

It turned out that simply leaving off the rrhost parameter was sufficient to get the job done.

After we were done iterating on it, we had a PowerShell function to update any record. Including enough intelligence to handle the base domain case. I don't believe non-A records were tested, but it met the need of updating the base domain and a sub-domain or two from a scheduled task.

# NameSilo API Dynamic DNS
# Variables
$APIkey = ""
$domain = ""

function NameSilo-dnsUpdateRecord {
    param ([string]$APIKey, [string]$Domain, [string]$Record, [string]$Type)

    # Retrieve the DNS entries in the domain.
    $listdomains = Invoke-RestMethod -Uri "https://www.namesilo.com/api/dnsListRecords?version=1&type=xml&key=$APIkey&domain=$domain"
    $Records = $listdomains.namesilo.reply.resource_record | where { $_.type -eq $Type }

    $UpdateRecord = $null
    $IsNaked = $False
    foreach ($r in $Records ) {
        if ([string]::IsNullOrEmpty($Record) -and $r.host -eq $Domain) {
            $UpdateRecord = $r
            $IsNaked = $True
            break
        } elseif ($r.host -eq "$($Record).$($Domain)") {
            $UpdateRecord = $r
            break
        }
    }
    if ($UpdateRecord -eq $null) {
        echo "Error: Could not find requested record: $($Record).$($Domain)"
        Exit
    }

    $CurrentIP = $listdomains.namesilo.request.ip
    $RecordIP = $UpdateRecord.value
    $RecordID = $UpdateRecord.record_id

    # Only update the record if necessary.
    if ($CurrentIP -ne $RecordIP){
        $url = "https://www.namesilo.com/api/dnsUpdateRecord?version=1&type=xml&key=$APIkey&domain=$Domain&rrid=$RecordID"
        if ($IsNaked -eq $False) {
            $url += "&rrhost=$record"
        }
        $url += "&rrvalue=$CurrentIP&rrttl=3600"
        $update = Invoke-RestMethod -Uri $url
    } else {
        echo "IP Address has not changed."
    }
}

# Invocations:
NameSilo-dnsUpdateRecord -APIKey $APIkey -Domain $domain -Record "" -Type "A"
NameSilo-dnsUpdateRecord -APIKey $APIkey -Domain $domain -Record "*" -Type "A"
NameSilo-dnsUpdateRecord -APIKey $APIkey -Domain $domain -Record "test" -Type "A"

Since I don't do hardly anything in PowerShell, aside from trying to use it more than cmd.exe on Windows because it is a resizable window, I did a little more reading after this was written and concluded that it is not likely representative of PowerShell best practices.

But it is posted here just in case it might be useful to someone.

In playing with Bitcoin, in this case specifically with the bitcoin-qt client, I found myself wanting to more granularly control which of my coins I spent. This probably isn't something most people care about, or maybe even solve by using multiple wallets, but I thought that it would be nice to choose which addresses were used for transactions. I found that I was not alone in that desire. But sadly, the patch has yet to be merged despite going through a number of iterations.

Enter contrib/spendfrom/spendfrom.py. This Python script purported to solve the problem to some extent. But it wasn't quite as easy as I had hoped to get working. There is a README.md that highlights a dependency on "jsonrpc." That seemed easy enough, since I run Windows on this particular machine, I tried using C:\Python27\Scripts\easy_install.exe jsonrpc which indeed installed jsonrpc just not the one linked in the documentation, which I overlooked.

Once I got the right jsonrpc checked out from Bazaar, and copied to my site-packages directory, I thought I was good to go. However, I ran into a problem that spendfrom.py tests for:

def check_json_precision():
    """Make sure json library being used does not lose precision converting BTC values"""
    n = Decimal("20000000.00000003")
    satoshis = int(json.loads(json.dumps(float(n)))*1.0e8)
    if satoshis != 2000000000000003:
        raise RuntimeError("JSON encode/decode loses precision")

So I started digging, and found that the json object that jsonrpc comes with did some serialization by using unicode() that showed a loss of precision with the given value. This was pretty easy to verify, and I pushed a change to a github hosted version of the json-rpc.org bzr repository, thanks to git-remote-bzr. The change inserts a call to repr() before passing that string to unicode().

Finally, to get everything to work, I replaced all of the uses of Decimal() in the spendfrom.py script to just use float() and have not seen any issues. Granted I have not done a huge number of transactions, nor have I done any that were more than four decimal places. Hopefully I didn't introduce some insidious bug.