therning.org/ magnus

I’m not too surprised by this actually…

Which Programming Language are You?

I just finished listening to How to Disappear Completely. The last few episodes being almost too gripping, I ended it much too late last night. This is, by far, the best audio book I’ve listened to since I heard Ernst-Hugo JäregÃ¥rd reading H.P. Lovecraft in my early teens.

Go ahead, try the first chapter. I don’t think you’ll regret it!

The PaiMei page says that you need Python 2.4, which turns out to be true due to it shipping with a compiled for Python 2.4 version of pydasm. Of course it’s possible to compile pydasm yourself, it’s even fairly easy just as long as you have the correct version of Visual Studio installed. You could also use the utterly unofficial build I’ve made available here. Not even I know if I’m to be trusted though ;-). Use at own risk, and all that.

So, the steps are:

1. Install Python 2.5 off python.org
2. Install pydasm
3. Install PaiMei
4. Remove PaiMei’s version of pydasm (c:\python25\site-packages\paimei\pydasm.pyd) to be sure the correct one is used.

Oh, I probably should say that I’ve only been using the core functionality of PaiMei (pydbg and pydbg_core). There may be other dependencies on Python 2.4 in PaiMei that I haven’t stumbled upon!

I’ve finally found some time to play with c2hs again. This time I had a quick look at passing pointers to C functions. Here’s what I found, in a rather short format:

{# fun foo { alloca- `Int' peekIntConv* } -> `()' #} => foo :: IO Int
{# fun foo { `Int' peekIntConv* } -> `()' #} => foo :: Int -> IO Int

That is, the former is an out argumentⁱ while the latter is an inout argument.

A C function like this:

int foo(int *);

which is defined like this in haskell

{# fun foo { `Int' peekIntConv* } -> `Int' #}

will return a tuple of two integers, the first one is the returned value from foo the other is the inout argument to foo.

This means that it’s fairly simple to deal with APIs that follow the convention that functions return an error code and that the last argument is the actual result of the function.

1. It seems it always receives a pointer to an integer instance containing the value 0.[back]

Yesterday I received my GNOME SVN account, and today I made my first two commits for epilicious, 1499 and 1500.

I was disappointed to find the Debugging Tools for Windows contains precious few code examples that helps in understanding how to use the API. Especially if one is interested in using a symbol server to get symbols. Here are my findings:

1. Make sure to use the correct version of dbhelp.{dll,h}. The ones that ship with Visual Studio or the Platform SDK aren’t the same as the one in the Debugging Tools (they lack quite a few functions).

2. SymSetSearchPath doesn’t seem to accept the same syntax as _NT_SYMBOL_PATH. I gave up on using the former and resigned to having to set the latter in the environment.

3. You want to use SymSrvGetFileIndexes to find id, two and three that you pass to SymFindFileInPath.

4. Microsoft’s public symbol server only offers public symbols, what this means is that your SymEnumSymbolsProc will recieve SYMBOL_INFO structs with Tag set to SymTagPublicSymbol and Flags set to 0. Not very helpful if you want to find all functions in a DLL.

Added 2007-04-17 / 09:13

You also want to use the following little snippet to include dbghelp.h:

#define __out_xcount(x)
#define _NO_CVCONST_H
#include <dbghelp.h> 

I always find myself going through the same motions when trying to programming on Windows: excitement, bewilderedness, frustration, relief. It’s exciting to find new libraries and frameworks that seem to deliver exactly the functionality I require. I feel bewildered because I don’t think I’ve ever come across a Windows C/C++ API that immediately makes sense to me. Then follows a time of frustration, often a rather long period too, when I try to use the library/framework to solve the problem I have. At some point I hit that stage where my little project is debugged into behaving properlyⁱ and a sense of relief comes over me.

One thing that never ceases to amaze me is how many small surprising things there are lurking just under the hood in Windows:

1. Want to print an error message? GetLastError gives you an error value and FormatMessage whips it into a nice printable string. Take a good long look at FormatMessage. Where is the convenience function a lá strerror?

2. Another thing is the surprising order of paths that is searched for DLLs. By putting PATH so far down the list and completely leaving out an equivalent of LD_LIBRARY_PATH they actively encourage developers to copy DLLs into the home dirs of executables. I suspect this is inevitable given the DLL-hell phenomenon on Windows. It’s nonetheless extremely irritating when developing against a non-standard DLL (i.e. one that isn’t installed in \windows\system32).

3. The utter confusion I experience when trying to figure out just where to find the correct framework to use. There is considerable overlap between Visual Studio and the Windows Platform SDK. To add more confusion there are sometimes other frameworks that overlap the both of them, e.g. Debugging Tools for Windows provides dbghelp.{dll,h}, both of which are provided in slightly different versions in the other placesⁱⁱ.

4. The lack of fixes for known issues, e.g. the version of dbghelp.h included in Debugging Tools for Windows can’t be included as is because it lacks the definition of a macro. The webpage announcing version 6.6.7.5 was updated 18 July, 2006. One would think that gives Microsoft ample time to address the issue, but no such luck.

Well, that’s enough of ranting for one night…

1. Through experience I’ve come to the conclusion that it isn’t worth the time and effort to try to fit Microsoft solutions into some logical framework. I’d argue that’s true for most closed-source solutions.[back]
2. A tip, make sure to use the ones that comes from Debugging Tools for Windows![back]

I think it’d be better if Microsoft’s security specialists concentrated on improving security in their products (and possibly write about how they do it) rather than trying to make the rest of the world feel sorry for them. I’m sorry, but full disclosure is the fairest we have at the moment.

Microsoft sits on a reported vulnerability for months, releases patch when it becomes a 0-day. As I write this Microsoft is sitting on a few publically known vulnerabilities in Office (0-days as well) that have been known for a while now.

So, until companies start behaving I think full disclosure is fair. It seems to be the only way of forcing delivery of security to paying customers at the moment. When there’s a sign that the business as a whole can function without FD I’ll be the first to argue against it; at the moment though it seems to be our only hope.

FD ⇒ bad PR ⇒ declining share price and sales ⇒ security fixes

Some companies seem to be on the verge of understanding this and taking it to heart. (Microsoft has understood it, but doesn’t seem to have found its heart just yet.)

Funny how this things just seem to happen if you keep on turning up for practice.

I doubt anyone really noticed but a few weeks ago I retired Jendela due to inactivity in GNOME bug 344521. Without those changes I just couldn’t write the tool I imagined. Since I raised that bug on version 2.14 of Metacity and both 2.16 and 2.18 passed by without the patch applied I didn’t hold much hope of it ever getting anywhere. Lo and behold, the bug is closed, the patch is applied. Excellent news! I’m reviving Jendela