under Wine is unsupported and may break
without warning in the future. Wine should not be treated as a
version of Windows - functionality or performance-tuning is likely
to be different between any two development versions.
Rather than detecting Wine:
* Detect if functionality exists and use it when
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
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
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
Mark W. wrote:
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
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 [EMAIL PROTECTED] wrote:
On Mon, Sep 29, 2008 at 14:55, Juan Lang
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
On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner [EMAIL PROTECTED] 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
On Tue, Sep 30, 2008 at 6:52 AM, Austin English [EMAIL PROTECTED] wrote:
On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner [EMAIL PROTECTED] 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
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
On Mon, Sep 29, 2008 at 5:34 PM, Jeff Zaroyko [EMAIL PROTECTED] 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);
On Mon, Sep 29, 2008 at 4:41 PM, Juan Lang [EMAIL PROTECTED] 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
On Mon, Sep 29, 2008 at 14:41, Juan Lang [EMAIL PROTECTED] 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
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
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
On Mon, Sep 29, 2008 at 4:53 PM, Mark Wagner [EMAIL PROTECTED] wrote:
On Mon, Sep 29, 2008 at 14:41, Juan Lang [EMAIL PROTECTED] 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
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,
On Mon, Sep 29, 2008 at 14:55, Juan Lang [EMAIL PROTECTED] 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,
On Mon, Sep 29, 2008 at 15:15, Guillaume VanderEst [EMAIL PROTECTED] 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
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
I just wanted to add that exactly the same problem exists with graphics
drivers. There, we use approximately this scheme:
- If there's a driver difference, and both driver behaviors are somewhat
sane, then we accept both results. An application couldn't depend on a
specific result either
- If
Maarten Lankhorst wrote:
Hello Robert,
2008/4/29 Robert Reif [EMAIL PROTECTED]:
The returned result of some audio functions on windows may be inconsistent
because a driver may actually supply the returned value.
This presents a problem for the wine regression tests because a buggy
Robert Reif [EMAIL PROTECTED] writes:
The returned result of some audio functions on windows may be
inconsistent because a driver may actually supply the returned value.
This presents a problem for the wine regression tests because a buggy
driver may return an unexpected result which causes
On Wed, 30 Apr 2008, Robert Reif wrote:
[...]
I am suppling a minimal patch to the alsa driver and a single wave test to
illustrate this concept. I hope this allows valid tests to remain in spite of
buggy windows drivers.
I think it should be a more general winetest concept. My idea is that
Francois Gouget wrote:
My idea is that
some platforms (e.g. Wine) could ask for stricter checks, by using
strict_wine a bit like they use todo_wine to request looser checks.
So for instance you would do:
strict_wine ok(expected_cond || buggy(this_is_a_bug), ...);
Then on Windows the
I think that is an excellent idea and I can see it being immediately
useful in rpcrt4, if not other areas.
Indeed, I also think it's an excellent idea. The crypt32 chain tests
are another good candidate for this approach.
--Juan
The returned result of some audio functions on windows may be
inconsistent because a driver may actually supply the returned value.
This presents a problem for the wine regression tests because a buggy
driver may return an unexpected result which causes the test to fail.
One way around this
Robert Reif wrote:
The returned result of some audio functions on windows may be
inconsistent because a driver may actually supply the returned value.
This presents a problem for the wine regression tests because a buggy
driver may return an unexpected result which causes the test to fail.
Hello Robert,
2008/4/29 Robert Reif [EMAIL PROTECTED]:
The returned result of some audio functions on windows may be inconsistent
because a driver may actually supply the returned value.
This presents a problem for the wine regression tests because a buggy
driver may return an unexpected
29 matches
Mail list logo