On Fri, Jun 18, 2010 at 11:37 AM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
If what you want is to add workarounds for Wine in your code, then neither __WINE__ nor the build platform matter. What matters is the platform your code is currently running on, which should be detected at run-time.
Excellent point. After my previous post, I thought some more about this whole issue, and if you detected Wine at compile time and built in different behaviour for that platform (say to work around a Wine issue), then that application could be potentially crippled on Microsoft Windows if you ran it there. I am pretty sure I would have gone on to the idea of run-time detection, but I hadn't done so yet so thanks for that!
Which leads to a Wine newbie question. What is the best way to detect the Wine platform at run time?
Doing so is discouraged. As you pointed out earlier, if you workaround a wine bug in your application on wine, it may break on windows. Similarly, if/when the wine bug is fixed, your application may break similarly. If you do use such workarounds, be sure to give the user a way to workaround it (see, for example, utorrent, which allows enabling/disabling the hacks in its preferences).
To answer your question, though, you could check for wine specific exports in ntdll, e.g., NTDLL_wine_get_version. Keep in mind that doing so is unsupported, may break in the future, etc.