The __WINE__ macro does not identify the Wine platform
According to some old discussion (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on wine-devel it appears that __WINE__ was going to be the macro used to identify the Wine platform, However, that doesn't appear to work for Windows native MinGW on wine. To show this, I attach results from running wine gcc -E -dM foo.c >| /tmp/wine_gcc_dM.out where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 version. The equivalent command under Linux gcc shows several macros, (e.g., __linux__) are defined to identify that platform, but I cannot find anything in the attached file that similarly identifies the Wine platform. Furthermore, I have compiled and run a simple test code under Wine that shows that __WINE__ is not available (see previous post on wine-users for details). An excellent general motivation for such an identifying macro for wine is given in the above older wine-devel discussion, and I understand the CMake developers have an immediate use for such a macro within the CMake code itself. Is the lack of a macro to identify the wine platform a bug I should report or am I missing something? 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 __________________________
On Thu, Jun 17, 2010 at 4:56 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
According to some old discussion (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on wine-devel it appears that __WINE__ was going to be the macro used to identify the Wine platform,
However, that doesn't appear to work for Windows native MinGW on wine.
To show this, I attach results from running
wine gcc -E -dM foo.c >| /tmp/wine_gcc_dM.out
where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 version. The equivalent command under Linux gcc shows several macros, (e.g., __linux__) are defined to identify that platform, but I cannot find anything in the attached file that similarly identifies the Wine platform. Furthermore, I have compiled and run a simple test code under Wine that shows that __WINE__ is not available (see previous post on wine-users for details).
An excellent general motivation for such an identifying macro for wine is given in the above older wine-devel discussion, and I understand the CMake developers have an immediate use for such a macro within the CMake code itself.
Is the lack of a macro to identify the wine platform a bug I should report or am I missing something?
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 __________________________
You're compiling _under_ wine, and since wine attempts to be windows, gcc will think you're on windows. If you want to compile a winelib program/dll (i.e. a dll built specifically for wine and not windows) you use winegcc which defines __WINE__. winegcc -E -dM foo.c should contain #define __WINE__ 1. Mike.
On 2010-06-17 17:13-0400 Mike Kaplinskiy wrote:
On Thu, Jun 17, 2010 at 4:56 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
According to some old discussion (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on wine-devel it appears that __WINE__ was going to be the macro used to identify the Wine platform, [...] Is the lack of a macro to identify the wine platform a bug I should report or am I missing something?
You're compiling _under_ wine, and since wine attempts to be windows, gcc will think you're on windows. If you want to compile a winelib program/dll (i.e. a dll built specifically for wine and not windows) you use winegcc which defines __WINE__. winegcc -E -dM foo.c should contain #define __WINE__ 1.
On 2010-06-17 21:30-0000 Hin-Tak Leung wrote:
You seems to have made one mistake - it is "winegcc", (without space) not "wine gcc". winegcc does define __WINE__ .
To Mike and Hin-Tak: As alluded to by Mike, what I am doing is building software under wine using the Windows versions of MinGW, CMake, and MinGW make. I was aware of __WINE__ being defined for winegcc, but from the man page it appears to me that winegcc is a cross-compiler which is a technique I want to avoid. Note, that cmake configures MinGW make not only to build applications but also to test them. You cannot do the test part with just a cross compiler, and although I think it may be technically possible with CMake, it appears somewhat complicated to me to cross-compile from Linux to wine using Linux CMake, and then switch to the Wine platform for testing of the result using Windows CMake. Anyhow, to keep my build and test life simple, I just want to do everything on Wine. Furthermore, I would like to be free to choose any of the large variety of different versions of MinGW compilers. These considerations appear to rule out winegcc as a _general_ solution to the platform identification issue for those building software on Wine. I take Mike's point that currently Wine mimics Microsoft Windows so well that MinGW gcc thinks it is building on Microsoft Windows. In fact, that is an excellent statement of the problem. Because it is so useful to distinguish platforms when building software (the excellent motivation for this, e.g., to work around Wine bugs, is discussed in the mailing-list thread referenced above), I hope a general solution can be found for this problem. I am not familiar at all with run-time configuration of compilers, but my understanding is that compilers must be quite flexible about such configuration. Thus, is there not some standard means that could be used for wine to tell the various MinGW compilers built on Microsoft Windows but run under wine to always #define __WINE__? 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 __________________________
Alan W. Irwin wrote:
Thus, is there not some standard means that could be used for wine to tell the various MinGW compilers built on Microsoft Windows but run under wine to always #define __WINE__?
I am quite sure AJ will object to any such things - as far as the various compilers (and windows applications in general) are concerned, they should just believe they are running under windows. If a compiler (or a windows application) behaves differently under Microsoft Windows vs under wine, it is a bug for wine. AFAIK, the only "recommended/supported" way for an application to tell that it is running under wine vs under windows is by querying the presence of one of wine-specific registry entries. It is quite "evil" for a compiler to query the registry. Microsoft compilers probably try to probe the host about which versions of windows it is running in to work around "silently" various bugs in different/older versions of OSes which are fixed later, but I doubt any mingw people or GNU people for that matter, want to go down that path. In other words, don't even think about it.
On 2010-06-18 01:23+0100 Hin-Tak Leung wrote:
Alan W. Irwin wrote:
Thus, is there not some standard means that could be used for wine to tell the various MinGW compilers built on Microsoft Windows but run under wine to always #define __WINE__?
I am quite sure AJ will object to any such things - as far as the various compilers (and windows applications in general) are concerned, they should just believe they are running under windows. If a compiler (or a windows application) behaves differently under Microsoft Windows vs under wine, it is a bug for wine.
I recommend you read the complete thread at http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html where your point of view was expressed, but was eloquently answered to the point where the rest of the thread (including AJ) consisted of discussing implementation details. Of course it is quite possible AJ's views back then have changed now (or I misunderstood that thread). In that case I will just live with it, but let's let AJ speak for himself on this issue. Note also, my whole argument is based on the assumption that some standard means already exists for telling compilers running on Wine to #define __WINE__ at run time. However, if such standard means do not already exist there is no way I would want to ask for changes in any compilers (as you incorrectly imply later in your post), and again I would just live with 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 __________________________
"Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> writes:
Note also, my whole argument is based on the assumption that some standard means already exists for telling compilers running on Wine to #define __WINE__ at run time. However, if such standard means do not already exist there is no way I would want to ask for changes in any compilers (as you incorrectly imply later in your post), and again I would just live with it.
It sounds like you are confusing compile time and run time. The __WINE__ define can be used at compile time to detect the Wine build environment. If you are using a Windows compiler you have a Windows build environment, not a Wine one, so __WINE__ is not defined. That the Windows compiler is currently running under Wine is completely irrelevant. 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. -- Alexandre Julliard julliard(a)winehq.org
On 2010-06-18 11:44+0200 Alexandre Julliard wrote:
"Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> writes:
Note also, my whole argument is based on the assumption that some standard means already exists for telling compilers running on Wine to #define __WINE__ at run time. However, if such standard means do not already exist there is no way I would want to ask for changes in any compilers (as you incorrectly imply later in your post), and again I would just live with it.
It sounds like you are confusing compile time and run time. The __WINE__ define can be used at compile time to detect the Wine build environment. If you are using a Windows compiler you have a Windows build environment, not a Wine one, so __WINE__ is not defined. That the Windows compiler is currently running under Wine is completely irrelevant.
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? Finally, someone else in this thread mentioned this question has come up again and again to educate those like me who were making some incorrect assumptions about Wine platform identification. So perhaps a FAQ item on this subject would be appropriate? 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 __________________________
On Fri, Jun 18, 2010 at 11:37 AM, Alan W. Irwin <irwin(a)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
On Fri, Jun 18, 2010 at 6:43 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Fri, Jun 18, 2010 at 11:37 AM, Alan W. Irwin <irwin(a)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
On 2010-06-18 19:26+0200 Roderick Colenbrander wrote:
On Fri, Jun 18, 2010 at 6:43 PM, Austin English <austinenglish(a)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 __________________________
You seems to have made one mistake - it is "winegcc", (without space) not "wine gcc". winegcc does define __WINE__ . --- On Thu, 17/6/10, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote:
According to some old discussion (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on wine-devel it appears that __WINE__ was going to be the macro used to identify the Wine platform,
However, that doesn't appear to work for Windows native MinGW on wine.
To show this, I attach results from running
wine gcc -E -dM foo.c >| /tmp/wine_gcc_dM.out
where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 version. The equivalent command under Linux gcc shows several macros, (e.g., __linux__) are defined to identify that platform, but I cannot find anything in the attached file that similarly identifies the Wine platform. Furthermore, I have compiled and run a simple test code under Wine that shows that __WINE__ is not available (see previous post on wine-users for details).
An excellent general motivation for such an identifying macro for wine is given in the above older wine-devel discussion, and I understand the CMake developers have an immediate use for such a macro within the CMake code itself.
Is the lack of a macro to identify the wine platform a bug I should report or am I missing something?
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 __________________________
On 06/17/2010 02:56 PM, Alan W. Irwin wrote:
However, that doesn't appear to work for Windows native MinGW on wine. Correct. Programs running under Wine should not and are not aware of the fact they are running on Wine and not the real Windows. This aspect 100% analogous to a software running under virtual machine.
The whole notion of "Wine detectability" was brought up multiple times and all conversions concluded with the answer "No, Wine will not provide a specific "blessed" mechanism of detecting Wine". However such means do exist.
I was aware of __WINE__ being defined for winegcc, but from the man page it appears to me that winegcc is a cross-compiler which is a technique I want to avoid. Winegcc is not a "cross-compiler". It's nothing more then a thin wrapper around system's compiler (be it gcc or something else). Winegcc can not create WinPE binaries, but only ELF winelib binaries, that can only run under Wine. I'm sure that's not what you are looking for.
Vitaliy
participants (7)
-
Alan W. Irwin -
Alexandre Julliard -
Austin English -
Hin-Tak Leung -
Mike Kaplinskiy -
Roderick Colenbrander -
Vitaliy Margolen