This is something that anyone living with a geek really needs to understand.
I find it interesting that Rands has his set patterns of behaviour for getting into The Zone in the mornings. I’m very much a creature of habit and I actively “grow” new and effective patterns of behaviour as and when I recognise them… I hadn’t really connected the successful completion of the patterns as being an enabling device for getting me into The Zone… Must look into that a little more when I get back.
I just realised that I hadn’t posted to here in two months. As I said a while back, my head is not really in the right space for me to be as effective, or interested, in my technical stuff at present. I’m finding it very hard to get into “The Zone” and do any decent coding in the evenings; though have had the potential to have had so much time alone to do so.
It seems that Vista contains lots of interesting new Win32 API calls and some of these provide built in support for deadlock detection… I guess my deadlock detection tool can operate differently on Vista then…
Joe Duffy has written an interesting piece over on “Generalities & Details: Adventures in the High-tech Underbelly” about problems with the CLR thread pool. Joe’s a program manager on the CLR team at Microsoft, so he knows what he’s talking about!
I find the issues that Joe raises interesting as I spent some time designing a flexible thread pool for my C++ IOCP servers some time go and came across the problems that he’s facing.
Normal service will resume at some point, but right now I have some skiing to do… I’m off to Argentina at the end of July for 2 months ski instructor training, then, when I get back I’m going to head off to Tignes to do some race training with R21, then on to the Ski Club reps course in December and then, who knows…
It’s funny how potential product ideas beget other potential product ideas and the thing that you eventually end up with as a product for sale is often far from the original product idea and the code that you started to write… I’m not even there yet and I’m on my third wave of product idea focus. Right now I’m working towards getting some developer tools out there to help people write better systems.
A few weeks ago I wrote about hijacking threads. The principle was good, the code worked but the reason I needed it was flawed so the exercise was a failure. I assumed that it was likely to be a failure when I set out though, so it’s more a confirmation that I need to do things properly rather than hackily…
The idea was the try and outsmart the Windows program loader.
Jeremy D. Miller talks about how he dislikes the “I” prefix on interface names and how he’d prefer to ditch it in the same way he’s ditched most other hungarian notation. I’m all for ditching hungarian but I actually quite like the “I” prefix; though I no longer read it as “this is an interface” but simply “this is what I do”. In other words my interfaces, called things like IManageUsers simply clearly state what they do, classes that implement the interface manage users; the class definition is saying “I Manage Users”!
My API hooking currently relies on creating a block of memory in the target process to hold the string that you need to pass to LoadLibraryW() and then calling CreateRemoteThread() and passing the address of LoadLibraryW() as the thread start address and the address of our block of memory as the thread parameter. It works well and even allows you to know if the operation worked, by waiting for the remote thread to terminate and then examining its exit code.
Discovering and then fixing the problem that prevented my tools from running on themselves planted a seed of an idea in my mind. My APIHook library and any code that used it died horribly under leak testing tools such as Purify and BoundsChecker. I’d put it down to me trying to be too clever but not being clever enough and ignored it but it’s a pain to have code that you can’t polish.