adams.co.tt

madExcept's heinous crimes

17th March 2010

Recently on a project, we have been battling with some failing tests written in Delphi. They rely on a 3rd party library called madExcept. These tests passed on some machines and not others when run through the Delphi IDE, and not at all when run via a command line build. After much searching we worked out why. The machines on which the tests passed had the madExcept plugin installed. This plugin hooked into the compilation process and patched the binary produced.

Once we updated our command line scripts to do the same thing, out tests passed happily. Why madExcept doesn’t expect the user to perform programmatic setup of the library the user has chosen is beyond me. Patching the executable is essentially hacking and does not expose what it is doing to your binary.

madExcept offers the following from its FAQ:

Why does madExcept not work when I use command line compiling?

madExcept needs to patch your binary file. When compiling from inside the IDE, madExcept’s integrated IDE wizard does that patching automatically. When using command line compiling, you need to manually invoke the patching process by starting the tool “madExceptPatch.exe” after having compiled your project. The tool is located in madExcept’s “Tools” folder. Please add the parameter “-gd” to the command line when calling the compiler to make sure that a detailed map file is created.


This is evil.

tags: madexcept, post
blog comments powered by Disqus