Wine is an Open Source application for Linux which will help you to run Windows applications in Linux. It acts like an abstarct layer for windows so that you can run your favorite windows games and application. But not all applications are compatible with Wine. Wine provides both a development toolkit for porting Windows source code to Unix as well as a program loader, allowing many unmodified Windows programs to run on x86-based Unixes, including Linux, FreeBSD, Mac OS X, and Solaris. Here are some Basic debugging tips for Wine developers.
* If a program is displaying a message box when it fails, and you don’t know what is causing the problem, try performing a +relay,+msgbox trace. Then load up the log in your favourite editor or text viewer (less is quite good) and search for trace:msgbox. Now look at the relay data just before the MessageBox API call. In particular, look for failing API calls. The problem may not be caused by a call that happens immediately before the error! Also remember that there’s little consistency in the Windows API as to what return codes mean, you just have to get used to what they use. Many APIs return non-zero for success and zero for fail, but for some it’s the opposite.
* If a program is failing at startup, and you don’t know why, you can use a +all trace. If it seems to be failing a long way from an API call, disassemble it and see if it’s accessing some of the parameters passed in to WinMain (for instance, Dungeon Keeper crashes if you run it without an absolute path for argv[0]).
* If you’re finding the logs too big to work with try applying the debug delay patch which is available in the wine-patches archives. It lets you toggle logging on and off using the F12 key. You can also control the debug channels from within the source by using the libwine APIs.
* Visual glitches are best debugged by looking at the styles given by the application to the offending control then simply reading the widget code by hand. There are no fancy tricks you can use here, you just have to play with the drawing code and see if you can figure out where the problem is. Fortunately, native Windows 98 comctl32 works well, so you can always use that as a reference.
* Don’t be afraid to write a test case for a particular API if you have doubts about its implementation. Even if you don’t have the tools on hand to compile a test EXE, somebody else will. Often writing a test is the best way to check that a bug is real (and not simply a symptom of a problem elsewhere) as well as proving to Alexandre that your change is correct.
* The source tree is being cleaned up, but all code outside of loader/, tools/, libs/ and programs/ is built by Makefiles inside the dlls/ directory.
* If a program is complaining about a debugger being present, you need to find out why it thinks that and fix it. Wine does not report a debugger by default, but unfortunately as IsDebuggerPresent() is so easy to work around many programs, especially games, use more devious techniques. Some contain anti-disassembly code. You can find common anti-debugger techniques by reading blackhat/warez cracking sites: just don’t do it at work. If you see attempts to load SICE.VXD or NTICE.VXD then you’re seeing a check for the popular SoftIce debugger, you can ignore this.
* If you have a Windows license (ie, if you ever bought a PC from a high street store) you can go grab native DLLs from dll-files.com. This can also be handy if you’re missing various runtime DLLs smaller apps often assume are present. Using native DLLs is a good way to check how an API behaves without doing a full blown crosscompile.
