The __WINE__ macro does not identify the Wine platform

[Alan W. Irwin]

On 2010-06-18 19:26+0200 Roderick Colenbrander wrote:

> On Fri, Jun 18, 2010 at 6:43 PM, Austin English <austinenglish at 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
__________________________