The other day I was mildly bothered that Mac OS X doesn’t implement some built-in way of moving and resizing windows like most Linux WMs do - by allowing shortcut keys and mouse presses in combination to move and resize from and point on the window, instead of the title bar and resize handles. My first stop was iusethis, where I found remnants of a pre-Intel program called GeekBind. Curious, I hit up its SourceForge page and downloaded the code. It was in an Xcode project, so I loaded up Xcode and tried a compile. Unsurprisingly, it failed, due to some errors in a set of files I later learned was part of the mach_inject project. The code in question involved calls to initialize a ‘ppc_thread_state_t’ - clearly a reference to PowerPC, which explained the failed build on my Intel iMac.

To the Apple-mobile, I cried, slamming developer.apple.com into my browser. A search for ‘ppc_thread_state_t’ was - less than helpful. A few references to it, but no actual useful documentation. Google was the next stop, where someone trying to get another older program working on Intel received a comment about the new ‘i386_thread_state_t’ — something I could have guessed but was useless without the new register names provided by the comment. Plugged that in, and the program built without error - but would not run.

Confused, I hit up developer.apple.com and searched for ‘i386_thread_state_t’ - and Apple returned no results. I googled around some more for ‘mach_inject intel’, finding that one of the developers of iCal had produced a port of mach_inject. Replacing this with my hacking around produced another clean build, and a failure with an explicit error - what GeekBind was trying to do involved being part of the procmon group.

It was at this point I figured I could do one of three things:

1. Do one of the arbitrary and unsafe methods recommended to make the running user part of procmon
2. Learn about the complexities of user elevation in Mac OS and see if that was applicable to GeekBind
3. Find another program that did what I wanted GeekBind to do.

So I did step 3. Window Dragon does what I want, for the most part, and only required the install of some hefty Application Extension Management System that deposited itself in my System Preferences and god knows where else on my system. It doesn’t work with applications started through X11, which is nearly a dealbreaker. But it’s what works for now.

Why do I write about this? Several things.

1. There’s always an alternate program. Someone on iusethis recommended paying 8 dolllars for a program with similar functionality - and the idea made me balk. Eight dollars for something that should be built-in? I’m not horrifically poor but I know when to shop around.
2. developer.apple.com’s search sucks something horrible. Maybe I don’t understand what it does, but looking up two object names returned absolutely nothing for me. I may be too used to MSDN, I guess, and should be checking the documentation that came installed with Xcode.
3. even knowing nothing about Xcode, Objective-C, Cocoa, or any part of the Mac development process, I was nearly able to port a PPC source code project to an Intel Mac binary. A little more work and I’d have what I want working on my system, and the source code to give to other people under GPL. This is a powerful incentive.

And that was my Apple Excursion.