What's the best way for an application to detect that it's running under Wine? As part of the installation process, under Windows our program does a full-disk search of all local hard drives, but ignoring network drives and removable media. Under Wine, this doesn't work too well, as there's not a one-to-one mapping between disks and drive letters, and there's usually at least one way to access the entire *nix filesystem. If someone's got a few network drives mounted, the installer could spend hours searching them. -- Mark Wagner
On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner <carnildo(a)gmail.com> wrote:
What's the best way for an application to detect that it's running under Wine?
As part of the installation process, under Windows our program does a full-disk search of all local hard drives, but ignoring network drives and removable media. Under Wine, this doesn't work too well, as there's not a one-to-one mapping between disks and drive letters, and there's usually at least one way to access the entire *nix filesystem. If someone's got a few network drives mounted, the installer could spend hours searching them.
-- Mark Wagner
Easiest way is probably searching for wine specific registry keys.
On Tue, Sep 30, 2008 at 6:52 AM, Austin English <austinenglish(a)gmail.com> wrote:
On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner <carnildo(a)gmail.com> wrote:
What's the best way for an application to detect that it's running under Wine?
As part of the installation process, under Windows our program does a full-disk search of all local hard drives, but ignoring network drives and removable media. Under Wine, this doesn't work too well, as there's not a one-to-one mapping between disks and drive letters, and there's usually at least one way to access the entire *nix filesystem. If someone's got a few network drives mounted, the installer could spend hours searching them.
-- Mark Wagner
Easiest way is probably searching for wine specific registry keys.
Easier still would be checking for wine_get_version in ntdll... #include <windows.h> #include <stdio.h> int main(void) { static const char * (CDECL *pwine_get_version)(void); HMODULE hntdll = GetModuleHandle("ntdll.dll"); if(!hntdll) { puts("Not running on NT."); return 1; } pwine_get_version = (void *)GetProcAddress(hntdll, "wine_get_version"); if(pwine_get_version) { printf("Running on Wine... %s\n",pwine_get_version()); } else { puts("did not detect Wine."); } return 0; } jeffz(a)genera:~$ i586-mingw32msvc-gcc detect.c -o detect.exe jeffz(a)genera:~$ ~/git/wine/wine detect.exe Running on Wine... 1.1.5 Jeff
On Mon, Sep 29, 2008 at 5:34 PM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote:
Easier still would be checking for wine_get_version in ntdll...
#include <windows.h> #include <stdio.h> int main(void) { static const char * (CDECL *pwine_get_version)(void); HMODULE hntdll = GetModuleHandle("ntdll.dll"); if(!hntdll) { puts("Not running on NT."); return 1; } pwine_get_version = (void *)GetProcAddress(hntdll, "wine_get_version"); if(pwine_get_version) { printf("Running on Wine... %s\n",pwine_get_version()); } else { puts("did not detect Wine."); } return 0; }
jeffz(a)genera:~$ i586-mingw32msvc-gcc detect.c -o detect.exe jeffz(a)genera:~$ ~/git/wine/wine detect.exe Running on Wine... 1.1.5
Jeff
I'de like to nominate this bit of code (if approved as an 'acceptable practice') for the wiki. It seems Wine-devel gets this question at least once a month. Thoughts?
I'de like to nominate this bit of code (if approved as an 'acceptable practice') for the wiki. It seems Wine-devel gets this question at least once a month. Thoughts?
Not acceptable practice. See e.g. the old faq entry: http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE --Juan
On Mon, Sep 29, 2008 at 5:58 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
Not acceptable practice. See e.g. the old faq entry: http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE
I don't understand why this should still be the case. We have a stable Wine now and Alexadre exported this symbol for some good reason. I understand detecting Wine and having your application depend on certain behaviors would be wrong with unstable versions but in a post 1.0 would this seems acceptable. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
What's the best way for an application to detect that it's running under Wine?
Some people have given suggestions, but please note that we discourage doing this. It's better to fix Wine than to work around its bugs, and working around bugs removes incentive to fix them. So please, log a bug about the problem you're seeing at bugs.winehq.org, how to reproduce it, and so on. --Juan
On Mon, Sep 29, 2008 at 4:41 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
What's the best way for an application to detect that it's running under Wine?
Some people have given suggestions, but please note that we discourage doing this. It's better to fix Wine than to work around its bugs, and working around bugs removes incentive to fix them. So please, log a bug about the problem you're seeing at bugs.winehq.org, how to reproduce it, and so on. --Juan
The problem seems to be that he doesn't want to scan / (root), as it will take a _long_ time. There are already several bugs on this in bugzilla, I believe resolved as WONTFIX. As such, it doesn't seem to be a behavior Wine can/should fix. -Austin
On Mon, Sep 29, 2008 at 14:41, Juan Lang <juan.lang(a)gmail.com> wrote:
What's the best way for an application to detect that it's running under Wine?
Some people have given suggestions, but please note that we discourage doing this. It's better to fix Wine than to work around its bugs, and working around bugs removes incentive to fix them. So please, log a bug about the problem you're seeing at bugs.winehq.org, how to reproduce it, and so on.
Did you read the second paragraph of my original email? I'm not working around a bug in Wine, unless it's a bug that a user can map "/" to "C:" and call it a "fixed disk". -- Mark Wagner
Did you read the second paragraph of my original email? I'm not working around a bug in Wine, unless it's a bug that a user can map "/" to "C:" and call it a "fixed disk".
Yes, I read it. And scanning "/" shouldn't be a problem, unless you've also mapped network drives there. That seems to be the root of the problem. --Juan
On Mon, Sep 29, 2008 at 14:55, Juan Lang <juan.lang(a)gmail.com> wrote:
Did you read the second paragraph of my original email? I'm not working around a bug in Wine, unless it's a bug that a user can map "/" to "C:" and call it a "fixed disk".
Yes, I read it. And scanning "/" shouldn't be a problem, unless you've also mapped network drives there. That seems to be the root of the problem.
Yes, that's the root of the problem. I can't prevent the end-user from mounting network drives -- in fact, in the expected installation environment, the average user will have several very large network drives mounted. Under Windows, installation takes about five minutes, and the full-disk search provides a nicer user experience if they're upgrading from an ancient copy of the software. Under Wine, I need to either skip the full-disk search, or warn the user that it may take several hours. -- Mark
Yes, that's the root of the problem. I can't prevent the end-user from mounting network drives -- in fact, in the expected installation environment, the average user will have several very large network drives mounted.
I believe you.
Under Windows, installation takes about five minutes, and the full-disk search provides a nicer user experience if they're upgrading from an ancient copy of the software. Under Wine, I need to either skip the full-disk search, or warn the user that it may take several hours.
Again, I believe you. You've already gotten a couple suggestions on how to detect Wine, which you may use. We just don't recommend that, as the methods may not be supported in the future. Whether you choose to heed my recommendation is up to you ;-) Still, it'd help if you could log a bug about it. Include which software it is, whether and where a copy is available, how network drives are mapped, and so on. Without a good bug report, we're rather less likely to fix it. Out of curiosity, is the previous installation likely to be found under Z: ("/") rather than under C:? --Juan
Based on the current information, wouldn't it be smartest to ask the users which drive(s) they would like included in the search, or is it actually required that all disks be scanned? On Mon, Sep 29, 2008 at 3:06 PM, Mark Wagner <carnildo(a)gmail.com> wrote:
On Mon, Sep 29, 2008 at 14:55, Juan Lang <juan.lang(a)gmail.com> wrote:
Did you read the second paragraph of my original email? I'm not working around a bug in Wine, unless it's a bug that a user can map "/" to "C:" and call it a "fixed disk".
Yes, I read it. And scanning "/" shouldn't be a problem, unless you've also mapped network drives there. That seems to be the root of the problem.
Yes, that's the root of the problem. I can't prevent the end-user from mounting network drives -- in fact, in the expected installation environment, the average user will have several very large network drives mounted.
Under Windows, installation takes about five minutes, and the full-disk search provides a nicer user experience if they're upgrading from an ancient copy of the software. Under Wine, I need to either skip the full-disk search, or warn the user that it may take several hours.
-- Mark
On Mon, Sep 29, 2008 at 15:15, Guillaume VanderEst <me(a)gn0.me> wrote:
Based on the current information, wouldn't it be smartest to ask the users which drive(s) they would like included in the search, or is it actually required that all disks be scanned?
The average non-Wine user of this software has only a vague idea of what's going on inside the box on their desk. Asking the user what disks should be scanned will get blank stares and wrong answers 99% of the time. -- Mark Wagner
Your design is wrong IMO. You don't handle reparse points at all; you only rely on the nature of a drive, which isn't sufficient in most cases. See mounting volumes for example where you can mount a whole volume anywhere in an NTFS partition. The correct fix would be to: - ensure your code handles those cases correctly (which it doesn't) - ensure that wine returns the correct relevant information for remote mounted FS (which I'm pretty sure sure it's not done today) A+ 2008/9/30 Mark Wagner <carnildo(a)gmail.com>
On Mon, Sep 29, 2008 at 14:55, Juan Lang <juan.lang(a)gmail.com> wrote:
Did you read the second paragraph of my original email? I'm not working around a bug in Wine, unless it's a bug that a user can map "/" to "C:" and call it a "fixed disk".
Yes, I read it. And scanning "/" shouldn't be a problem, unless you've also mapped network drives there. That seems to be the root of the problem.
Yes, that's the root of the problem. I can't prevent the end-user from mounting network drives -- in fact, in the expected installation environment, the average user will have several very large network drives mounted.
Under Windows, installation takes about five minutes, and the full-disk search provides a nicer user experience if they're upgrading from an ancient copy of the software. Under Wine, I need to either skip the full-disk search, or warn the user that it may take several hours.
-- Mark
-- -- Eric Pouech
Am 30.09.2008 um 12:55 schrieb Eric Pouech:
Your design is wrong IMO. You don't handle reparse points at all; you only rely on the nature of a drive, which isn't sufficient in most cases. See mounting volumes for example where you can mount a whole volume anywhere in an NTFS partition.
The correct fix would be to: - ensure your code handles those cases correctly (which it doesn't) - ensure that wine returns the correct relevant information for remote mounted FS (which I'm pretty sure sure it's not done today)
A reasonable 99% shortcut would probably be to parse C: only. This should be sufficient for almost all users, especially the clueless ones, on Wine as well as on Windows. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Markus Hitter wrote:
Am 30.09.2008 um 12:55 schrieb Eric Pouech:
Your design is wrong IMO. You don't handle reparse points at all; you only rely on the nature of a drive, which isn't sufficient in most cases. See mounting volumes for example where you can mount a whole volume anywhere in an NTFS partition.
The correct fix would be to: - ensure your code handles those cases correctly (which it doesn't) - ensure that wine returns the correct relevant information for remote mounted FS (which I'm pretty sure sure it's not done today)
A reasonable 99% shortcut would probably be to parse C: only. This should be sufficient for almost all users, especially the clueless ones, on Wine as well as on Windows.
MarKus
As long as the scan can be canceled, that should cover just about every use case. Clueless users let it work, clueful users know to cancel it because it's looping with their reparse points in C:\ and never getting to D:\ Thanks, Scott Ritchie
On Mon, Sep 29, 2008 at 4:53 PM, Mark Wagner <carnildo(a)gmail.com> wrote:
On Mon, Sep 29, 2008 at 14:41, Juan Lang <juan.lang(a)gmail.com> wrote:
What's the best way for an application to detect that it's running under Wine?
Some people have given suggestions, but please note that we discourage doing this. It's better to fix Wine than to work around its bugs, and working around bugs removes incentive to fix them. So please, log a bug about the problem you're seeing at bugs.winehq.org, how to reproduce it, and so on.
Did you read the second paragraph of my original email? I'm not working around a bug in Wine, unless it's a bug that a user can map "/" to "C:" and call it a "fixed disk".
-- Mark Wagner
Is the problem with scanning / that it's too many files/takes too long, or that it's not a 'local hard drive'? -Austin
participants (10)
-
Austin English -
Eric Pouech -
Guillaume VanderEst -
Jeff Zaroyko -
Juan Lang -
Mark Wagner -
Markus Hitter -
Scott Ritchie -
Steven Edwards -
Zachary Goldberg