Detecting Wine

[Mark Wagner]

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.

[Austin English]

On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner  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.

[Jeff Zaroyko]

On Tue, Sep 30, 2008 at 6:52 AM, Austin English  wrote:
> On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner  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@genera:~$ i586-mingw32msvc-gcc detect.c -o detect.exe
jeffz@genera:~$ ~/git/wine/wine detect.exe
Running on Wine... 1.1.5

Jeff

[Zachary Goldberg]

On Mon, Sep 29, 2008 at 5:34 PM, Jeff Zaroyko  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?

[Juan Lang]

> 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

[Steven Edwards]

On Mon, Sep 29, 2008 at 5:58 PM, Juan Lang  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.

[Juan Lang]

> 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

[Austin English]

On Mon, Sep 29, 2008 at 4:41 PM, Juan Lang  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

[Mark Wagner]

On Mon, Sep 29, 2008 at 14:41, Juan Lang  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".

[Juan Lang]

> 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

[Mark Wagner]

On Mon, Sep 29, 2008 at 14:55, Juan Lang  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.

[Juan Lang]

> 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

[Guillaume VanderEst]

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  wrote:
> On Mon, Sep 29, 2008 at 14:55, Juan Lang  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

[Mark Wagner]

On Mon, Sep 29, 2008 at 15:15, Guillaume VanderEst  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.

[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+
2008/9/30 Mark Wagner
> On Mon, Sep 29, 2008 at 14:55, Juan Lang  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

[Markus Hitter]

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/

[Scott Ritchie]

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

[Austin English]

On Mon, Sep 29, 2008 at 4:53 PM, Mark Wagner  wrote:
> On Mon, Sep 29, 2008 at 14:41, Juan Lang  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