29 Sep
2008
29 Sep
'08
8:39 p.m.
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
29 Sep
29 Sep
8:52 p.m.
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.
9:34 p.m.
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:
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@genera:~$ i586-mingw32msvc-gcc detect.c -o detect.exe
jeffz@genera:~$ ~/git/wine/wine detect.exe
Running on Wine... 1.1.5
Jeff
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.
9:44 p.m.
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@genera:~$ i586-mingw32msvc-gcc detect.c -o detect.exe
jeffz@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?
9:58 p.m.
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
30 Sep
30 Sep
1:27 a.m.
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
29 Sep
29 Sep
9:41 p.m.
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
9:52 p.m.
On Mon, Sep 29, 2008 at 4:41 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
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
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
9:53 p.m.
On Mon, Sep 29, 2008 at 14:41, 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".
--
Mark Wagner
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.
9:55 p.m.
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
10:06 p.m.
On Mon, Sep 29, 2008 at 14:55, Juan Lang <juan.lang(a)gmail.com> wrote:
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
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.
10:10 p.m.
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
10:15 p.m.
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:
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
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.
10:24 p.m.
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
30 Sep
30 Sep
10:55 a.m.
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:
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
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. 
11:14 a.m.
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/
2 Oct
2 Oct
8:17 p.m.
Markus Hitter wrote:
Am 30.09.2008 um 12:55 schrieb Eric Pouech:
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
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
29 Sep
29 Sep
10:07 p.m.
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:
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
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.
5711
days inactive
5714
days old
17 comments
10 participants
participants (10)
-
Austin English -
Eric Pouech -
Guillaume VanderEst -
Jeff Zaroyko -
Juan Lang -
Mark Wagner -
Markus Hitter -
Scott Ritchie -
Steven Edwards -
Zachary Goldberg