words

I’m running Windows 7 Home Premium 64-bit on my Toshiba A505 Satellite, which has a Firewire port. If I connected my Sony camcorder (DCR-HC40) I would just get either an endless connect/disconnect cycle, or simply nothing at all. Firewire just did not appear to work.

The solution was to roll the IEEE 1394 (“Firewire”) Bus Host Controller driver back to the legacy version. It’s detailed in this Technet post. The important steps are:

1. Click the Start Button, type devmgmt.msc in the “Start Search” box and press Enter.
2. Expand the “IEEE 1394 Bus Host Controllers” node in the device tree on the right hand pane
3. Right click the host controller node select “Update driver software …”
4. Select “Browse my computer for driver software”
5. Select “let me pick from a list of device driver on my computer …” and Check the box before “Show compatible hardware”.
6. Choose the second option—1394 OHCI Compliant Host Controller (Legacy), and click next to update the driver.

I wanted to change the behavior of the Microsoft IME bar using AutoHotkeys, a utility which can be used to create macros, remap keys, or do any of a variety of other related tasks.

This led me to ime_func.ahk, which appears to be an AutoHotkeys script which uses DllCall to access Imm32.dll, the Input Method Manager library. I believe that this script was intended to manipulate the state of the IME language bar.

As near as I can tell, this AutoHotkeys script targets an older implementation of the IMM library. Some of the methods used are now only listed for Windows Mobile platforms.

I began experimenting with ImmGetContext and ImmGetConversionStatus. ImmGetContext always returned a hIMC value of NULL.

On the Developing IME-Aware Multiple-thread Applications MSDN page, the following is stated (bold highlight added):

The IMM includes thread identification checking that determines if a calling thread is the creator of a specified input method context handle (HIMC type) or window handle (HWND type). If the thread is not the creator of the handle, the called IMM function fails and a subsequent call to GetLastError returns ERROR_INVALID_ACCESS.

Additionally:

• A thread should not access the input context created by another thread.
• A thread should not associate an input context with a window created by another thread, and vice versa.

So, it appears that cross-process IME manipulation is forbidden.

I was having trouble using the GnuPG plugin for vim under Cygwin. The GnuPG plugin allows seamlessly integrated decryption, editing, and re-encryption of GPG-encrypted content within vim. However, on my Windows 7 box, it just showed gibberish. Attempting to edit my encrypted password file resulted in a rather vague error message:

$ vim Documents/passwords.gpg

"Documents/passwords.gpg" [Incomplete last line][converted] 7 lines,
2547 characters
Press ENTER or type command to continue

Pressing enter simply resulted in gibberish, likely the raw data of the encrypted file.

The solution was to turn on vim’s filetype plugin processing:

:filetype plugin on

To make this setting persistent, add it to your ~/.vimrc file.