Geoff Chappell - Software Analyst
The theoretical work behind the Geoff Chappell website is to develop and refine techniques for studying software without its source code, especially as an economical way of getting detailed and reliable answers to questions that might otherwise seem intractable. The practical application is that I direct these techniques at whatever I happen to find interesting about Windows. The commercial application is the solving of your problems of Windows programming.
Look around this website: there are few people anywhere who approach the problem of understanding Windows with such breadth and in such detail. Get that working for you!
To get my attention directed to your particular needs, consider a formal consultation. Perhaps look first at my (negotiable) fees and even at my few terms.
Of course, Windows is very big. I don’t know everything about it. But in my specialties, the systematic application of reverse engineering means that I’m an expert’s expert. Literally: I have had clients who are themselves being consulted for their expertise. Few others anywhere can be as well prepared for questions in these areas of Windows programming. But even where I haven’t yet looked, few others anywhere could make up the ground as quickly and reliably.
That’s because I don’t play with trial and error, hoping to infer what’s needed. Instead, I reverse-engineer and deduce.
Reverse engineering is much too much work for a simple problem, of course. But if the problem is innovative enough to take you outside what’s covered clearly and cleanly in the documentation, then my methods not only give you a robust solution but they deliver faster—in some cases very much faster than you’ll have imagined is possible.
Windows is a huge, sophisticated operating system that is sometimes only vaguely documented and is much too often mis-documented. Interacting with it has in its nature that if what your programmers are attempting is at all tricky then there’s a good chance they spend a lot of time on trial and error, hoping to learn by experiment what does and doesn’t work. Mostly, that does succeed. Computers are intrinsically repetitive. You can go a long way by observing and inducing.
Until you can’t. But even before you hit that brick wall, the effort that you put into trying to infer what to program is not effort that’s going into careful programming. You end up with software that is held together by the proverbial rubber bands and that nobody’s confident of, but which still takes ages to develop. If you’re lucky, the bugs don’t bite you back too hard or too soon.
Like any handicraft, even on a commercial scale, software by nature cannot be perfect, but your software will be better from the start if you secure the close attention of someone with a record of deducing how the code it interacts with really works.
A lot of Windows code has been analysed here as speculative research. This analysis is a sort of debugging in advance.
Before you even imagine a specific problem of programming Windows, let alone before it costs you something in the real world, I may already have done much of the work required for knowing how to solve the problem, if not for its actual solution.
Many questions that you, your programmers or your lawyers may have about Windows can be answered quickly and authoritatively—and if the information needed for the answer is not already known, it may be within relatively easy reach.
For many programming problems, you can get reliable advice on a design that you expect your own programmers to implement or you can get a solution coded efficiently for you.