Debugging WPS applications can be really tiresome, because you have to restart the WPS for every tiny change you made to the source codes to take effect. And, as with any PM program, you can't just printf() stuff to the screen. Even worse, it's hard to use the PM debugger, because you have to start the whole WPS (PMSHELL.EXE) with it, since XFLDR.DLL is no standalone application.

So I had to look for something else.

To enable the debug build, set XWP_DEBUG in config.in. Again, mind the warnings given there. Of course, you will then have to cause a complete rebuild by deleting the bin\ directory.

Enabling the debug code has a large number of consequences:

  1. Since in debug mode, the __DEBUG__ define is passed on the compiler command line, many other parts of the code can react to that. For example, you will find a few interesting new items in the Desktop's context menu, such as "Crash WPS" to test the exception handlers.

  2. Depending on whether __XWPMEMDEBUG__ is uncommented at the bottom of include\setup.h, all memory management functions will be replaced by debug versions which give you very detailed logs of all memory that was ever allocated. See memdebug.c in the helpers for details. This will also produce an additional Desktop context menu item which will open a PM window with lots of information.

  3. There are a large number of _Pmpf(("xxx")) calls in the code. These are for the magnificent PMPRINTF package by Dennis Bareis.

    Some files from the PMPRINTF package are included so that you can compile. The PM interface which actually displays the messages plus the required DLLs which must be on the LIBPATH are not however. Last time I checked (March 13, 2001), this package was available at http://www.labyrinth.net.au/~dbareis/zips_fw/pmf96179.zip.

    These calls only display anything if the proper DEBUG_xxx #define's are set in include\setup.h (changed with V0.9.0). You can conditionally enable groups of debugging flags in there, but some of them haven't been tested in a long while and might cause compilation errors.

    For the release version of XWorkplace, all these flags have been disabled, so no additional code is produced at all. You thus don't have to remove the commands to speed up XWorkplace, because this wouldn't make any difference.

    _Pmpf(("xxx")) uses regular printf syntax, except for those strange double brackets, which are needed because macros don't accept variable parameter lists otherwise.