On Fri, Jun 18, 2010 at 6:43 PM, Austin English austinenglish@gmail.com wrote:
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.
-- -Austin
The best thing you can do is when you discover differences in behavior is to submit a bug report to bugzilla. Even better would be to write a small test case showing the difference that way it might get fixed quickly (even better would be to fix the bug in Wine yourself if it is an easy one).
If you want to detect Wine. An easy way is to check for Wine specific registry keys (not the most reliable one though since someone could have the same keys on Windows though unlikely). Another way is to check for wine specific functions like 'wine_get_unix_file_name' in kernel32.
Roderick