od to detect running 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 functi
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 volum
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 Lan
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 the
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 p
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
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
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 t
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 b
> 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 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 dis
> 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
> 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 t
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, a
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,
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
> #include
> int main(void)
> {
> static const char * (CDECL *pwine_get_version)(void);
> HMODULE hntdll = GetModuleHandle("ntdll.dll");
>
> 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 ab
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 pro
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
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
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
-> I
> 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
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 Wind
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
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 c
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
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 unexpec
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 f
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 i
29 matches
Mail list logo
