Faux' Blog

I have a set of tiny utilities that I use on a daily basis but have never bothered to release.

All are in the tinies v001 archive, in both x64 and legacy format. Symbols, source and signatures are available. No installer is available; just drop them into your All Programs -> Startup folder.

shiftfocus.exe adds an extra set of hotkeys for focusing windows. Ctrl+win+arrow focuses the window to that side of the current window.

This makes the most sense with Aero’s Snap turned on. If you have two windows “half-maximised” on a screen (i.e. one has been win+left‘d, and the other win+right‘d), then you can switch between them using ctrl+win+left and ctrl+win+right.

topkey.exe adds win+w to toggle a windows’ always-on-top flag, and win+return to create a new command prompt “in the current directory”. (This works for Explorer windows, and things that have the directory at the start of the title, i.e. Notepad++.)

mousex.exe allows you to use an xbox360 controller as a mouse. Different analogue sticks are different sensitivity. A/B for left/right click. Shoulder analogue controls for the scrollwheel.

And, for more niche users:

powerstatustray.exe shows which drives are spun-up, and notifies you when a drive spins up or down. (Yes, actually, this one was released before.)

keydump.exe shows what you can keylog by binding globally to DirectInput. Most keylogging preventers/detectors completely ignore this, and/or only work through blacklisting, which is laughably pointless. It doesn’t bother translating numbers into keycaps, but it’s obvious whether it’s working and whether it’s been detected.

Others, to date:

• aukiller: Legacy XP application.
• foobar2000-loader.exe: Demo of pre-loading a dll into an application via the debug api.
• keytoputty.exe: Take input and send it to a running instance of putty, i.e. to allow input during full-screen applications.
• loaddlls.exe just calls LoadLibrary on all it’s arguments.
• noelev.exe: Legacy implementation of setting __COMPAT_LAYER=RunAsInvoker.
• quickkey.exe: Legacy XP application.
• unrequireadmin.exe: An even less healthy implementation of noelev.exe.

No Comments yet »

Late last year we were playing TrickyTrucks.

TrickyTrucks is okay fun single-player, but what really makes it fun is the competition. For this, it has built in scoreboards, per track. Attempting to beat certain people’s times on tracks is the fun.

What it lacks is a cross-track scoreboard, i.e. some kind of championship, and/or notifications of people beating your scores. Even Audiosurf, one of the… most entertainingly engineered indie games recently, got this right.

I implemented one.

After some initial beta testing (and ensuring I was near the top of the championship), I messaged the TrickyTrucks author with the source of the scraper and of the web interface, asking for permission to link to the website on the official forum, so others could join us in competing for the championship title.

An aside, on licensing: Both of these components were released under the BSD. That allows anyone, including the TrickyTrucks author, to use the code for any purpose, including incorporating it into his official website. The component split was done such that there was a neat interface for him to implement on a non-scraper backend. The best result for me would be for there to be an official API and an officially hosted version of the site, such that I never had to do anything ever again to continue appreciating it.

An aside, on development costs: Reverse engineering binary protocols is a nightmare. Especially so with only access to a read client (with no source). Especially so when there’s no way to get the server to return things consistently or with user-specified plaintext. Especially when the protocol has (what you believe to be) NIH compression. Don’t ever, ever try and pay someone to do this unless they really, really want to.

He replied that this would be fine, but only if I removed the link from the website to the source. I, grudgingly (given it was already in the wild), did so and posted on the forum.

His response? Delete the post, and change the server to have some additional, weak protection against 3rd-party clients.

What. The. Hell.

(Eventually he sent me details of an API to use, but I’d lost interest by then.)

This post brought to you by libspotify being incompatible with most 3rd party DLLs, probably due to the copy protection on their DLL. Copy protection. On something that requires a paid account, verified against their server. Please tell them what you think about this on my GetSatisfaction thread (apparently this is what passes as a bug tracker these days).

This prompted me to waste ALL WEEKEND porting foo_input_spotify to libdespotify. foo_input_spotify will increase the value of their product. Why are they making my life miserable? Perhaps it’s unintentional. Time will tell.

No Comments yet »

This post is for documentation only. It was going to be a rebuttal to jwh’s Mercurial fanboyism but I realised while writing it and re-reading his post that I have absolutely no idea what he’s talking about, nor can I work out how to get hg to tell me.

Given a repo of:

My proposals for alternatives to this simple workflow are as follows. These all result in the same order of code going into the master branch, but have different histories. (Actually, I think there’s still mistakes in there but I’m tired of staring at the horrible procedural script that generates it, so it’ll do).

1. A flat history, made by rebasing everything on top of master instead of merging:

2. Only merges on master, giving you the illusion of a neat history…

…but, underneath, loads of ugly information available:

3. A hybrid, supercommits, whereby you keep a flat history but you maintain where branches were:

…or, with the history information visible:

Thoughts:

Serious concurrent projects like git itself use the ‘only merges on master’ approach. I strongly agree that they shouldn’t be flattening the history; it’s nice to be able to see groups of patches as they go into master, and to navigate the history of “feature commits”, instead of the history of “developer changes”.

The flat model seems to work much more like how I think about software development:

• You start working on something.
• You do your normal develop, commit, developer-test, commit cycle.
• Master moves on a bit while you’re messing around. The fact that you happened to start developing before a specific commit on master, instead of just after it (so it would be the root of your branch) is reasonably irrelevant; you may as well move the branch-root (or branch point) up to the top of master.
• Additionally, if you do a real merge, you need to test your changes. This leads to more developer testing, and possibly more commits.
• What do you do with these commits? Assuming your merge with master is still local you can fix it (this is git, you can fix anything), but it’s inconvenient.
• When you’ve rebased, you can continue committing on your rebased branch like normal, with confidence that when you merge it’ll all be fine (as it’ll be a fast-forward merge).

‘Supercommits’ is a hybrid of these two; you can use the rebase-onto-master workflow from ‘flat’, but you can logically group your set of commits into a… family? I like this idea, but haven’t really implemented it in practice so can’t really comment.

(Apologies for screenshots of text; I’m lazy, ansifilter was NOT WORKING and it’s prettier than gitk.)

1 Comment »