On 2010-06-18 19:26+0200 Roderick Colenbrander wrote:
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
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.
Just to give some background here see http://bugs.winehq.org/show_bug.cgi?id=22286. There cmake got badly burnt on Wine by using a GetShortPathName -> GetLongPathName kludge to get the actual case for a filename. That use of GetShortPathName lead to a hash collision under Wine between two completely different file names used for language support under CMake.
The wine developer response was won't fix since "If you need reliable short names you have to use a vfat filesystem." which seems a reasonable response to me although I don't have enough vfat knowledge to follow the logic completely.
<aside> The assumption here is CMake's choice of language support file name was just unlucky, but an alternative interpretation is that hashing function is poorly implemented on Wine so the probability of hash collisions is substantially higher than it needs to be. Anyhow, I hope the wine developers do follow up by looking carefully at their hash code for this case to make sure it minimizes hash collisions. Of course, making collisions less probable would be great, but even if that is possible and implemented, it appears the statement is still correct that GetShortPathName is always going to be unreliable to a certain (hopefully low) degree under the combination of Wine and Linux filesystems. </aside>
The CMake developers have responded now (CMake-2.8.2 release candidate) to this issue by replacing that kludge for getting the correct case of filenames with something completely reliable that does not use GetShortPathName. However, there are other instances of GetShortPathName in the CMake source code that are used for the
#if defined(WIN32) && !defined(__CYGWIN__)
case. I am not a CMake developer and don't understand all the issues, but I have been told GetShortPathName is used for these other cases because there are certain build tools under Windows that still do not handles spaces in file names correctly. GetShortPathName apparently works perfectly to get around such issues for the Microsoft Windows platform, but because of the above issue it _might_ be subject to hash collions under Wine (especially if the probability of those is much higher than it should be, see <aside> above).
The Wine documentation actively discourages spaces in filenames (probably because of issues with Windows applications similar to those found by the CMake developers for certaint Windows build tools). Thus, it appeared to the CMake developers that the above could be changed to
#if defined(WIN32) && !defined(__CYGWIN__) && !defined(__WINE__)
However, because of the good reason discussed by Alexandre earlier in this thread I am now looking for an equivalent run-time test to recommend to the CMake developers so that GetShortPathName won't be used at all (instead the full pathname will be used just as in all cases other than WIN32 above) when Windows cmake happens to be run on Wine.
Developer life sure is messy and full of compromises, ain't it?
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________