Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS

[Simo]

On 03/04/2013 04:19 PM, J. Bruce Fields wrote:

On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote:

[possible resend -- sorry]

On 02/28/2013 07:25 AM, Pavel Shilovsky wrote:

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can 
be used by any application that needs share reservations to organize a file 
access. VFS already has some sort of this capability - now it's done through 
flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build 
new capabilities on top of the existing one but doesn't bring any changes into 
the flock call semantic.

These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and 
Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This 
will help when e.g. Samba and NFS server share the same directory for Windows 
and Linux users or Wine applications use Samba/NFS share to access the same 
data from different clients.

According to the previous discussions the most problematic question is how to 
prevent situations like DoS attacks where e.g /lib/liba.so file can be open 
with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is 
added. It indicates to underlying layer that an application want to use O_DENY* 
flags semantic. It allows us not affect native Linux applications (that don't 
use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that 
they bring) are used only for those applications that really want it proccessed 
that way.

So, we have four new flags:
O_DENYREAD - to prevent other opens with read access,
O_DENYWRITE - to prevent other opens with write access,
O_DENYDELETE - to prevent delete operations (this flag is not implemented in 
VFS and NFS part and only suitable for CIFS module),
O_DENYMAND - to switch on/off three flags above.

O_DENYMAND doesn't deny anything.  Would a name like O_RESPECT_DENY be
better?

Other than that, this seems like a sensible mechanism.

I'm a little more worried: these are mandatory locks, and applications
that use them are used to the locks being enforced correctly.  Are we
sure that an application that opens a file O_DENYWRITE won't crash if it
sees the file data change while it holds the open?


The redirector may simply assume it has full control of that part of the 
file and not read nor send data until the lock is released too, so you 
get conflicting views of the file contents between different clients if 
you let a mandatory lock not be mandatory.



In general the idea of making a mandatory lock opt-in makes me nervous.
I'd prefer something like a mount option, so that we know that everyone
on that one filesystem is playing by the same rules, but we can still
mount filesystems like / without the option.


+1


But I'll admit I'm definitely not an expert on Windows locking and may
be missing something about how these locks are meant to work.


Mandatory locks really are mandatory in Windows.
That may not be nice to a Unix system but what can you do ?

Simo.

Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS

[J. Bruce Fields]

On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote:
> [possible resend -- sorry]
> 
> On 02/28/2013 07:25 AM, Pavel Shilovsky wrote:
> > This patchset adds support of O_DENY* flags for Linux fs layer. These flags 
> > can be used by any application that needs share reservations to organize a 
> > file access. VFS already has some sort of this capability - now it's done 
> > through flock/LOCK_MAND mechanis, but that approach is non-atomic. This 
> > patchset build new capabilities on top of the existing one but doesn't 
> > bring any changes into the flock call semantic.
> > 
> > These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers 
> > and Wine applications through VFS (for local filesystems) or CIFS/NFS 
> > modules. This will help when e.g. Samba and NFS server share the same 
> > directory for Windows and Linux users or Wine applications use Samba/NFS 
> > share to access the same data from different clients.
> > 
> > According to the previous discussions the most problematic question is how 
> > to prevent situations like DoS attacks where e.g /lib/liba.so file can be 
> > open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND 
> > is added. It indicates to underlying layer that an application want to use 
> > O_DENY* flags semantic. It allows us not affect native Linux applications 
> > (that don't use O_DENYMAND flag) - so, these flags (and the semantic of 
> > open syscall that they bring) are used only for those applications that 
> > really want it proccessed that way.
> > 
> > So, we have four new flags:
> > O_DENYREAD - to prevent other opens with read access,
> > O_DENYWRITE - to prevent other opens with write access,
> > O_DENYDELETE - to prevent delete operations (this flag is not implemented 
> > in VFS and NFS part and only suitable for CIFS module),
> > O_DENYMAND - to switch on/off three flags above.
> 
> O_DENYMAND doesn't deny anything.  Would a name like O_RESPECT_DENY be
> better?
> 
> Other than that, this seems like a sensible mechanism.

I'm a little more worried: these are mandatory locks, and applications
that use them are used to the locks being enforced correctly.  Are we
sure that an application that opens a file O_DENYWRITE won't crash if it
sees the file data change while it holds the open?

In general the idea of making a mandatory lock opt-in makes me nervous.
I'd prefer something like a mount option, so that we know that everyone
on that one filesystem is playing by the same rules, but we can still
mount filesystems like / without the option.

But I'll admit I'm definitely not an expert on Windows locking and may
be missing something about how these locks are meant to work.

--b.

Re: Making wine default to the Mac Driver on OS X

[Alexandre Julliard]

Ken Thomases  writes:

> My feeling (like Josh's and Per's) is that the Mac driver should be
> what you get by default, in most cases, without taking any special
> steps.

I think we all agree on that.  My point is that you shouldn't have to
take special steps even when the Mac driver is not appropriate (like
with remote logins).

> If the concern is what you get when you're ssh'd into a remote system,
> then it's probably possible for the Mac driver to detect when it
> doesn't have GUI console access and fail.  Then, Wine could fall back
> to X11.

If that can be made to work, it would certainly be a nice solution.

-- 
Alexandre Julliard
julli...@winehq.org

Re: Making wine default to the Mac Driver on OS X

[Ken Thomases]

My feeling (like Josh's and Per's) is that the Mac driver should be what you 
get by default, in most cases, without taking any special steps.

If the concern is what you get when you're ssh'd into a remote system, then 
it's probably possible for the Mac driver to detect when it doesn't have GUI 
console access and fail.  Then, Wine could fall back to X11.

We can't rely on DISPLAY being unset.  It's set by default.  That's true on 
Snow Leopard and Lion.  I believe it's also true on stock Mountain Lion 
(whether or not XQuartz has been installed).

(The question of when to make this switch so that the Mac driver is the default 
is separate.  OpenGL is my next major patch set.  I hoped to submit it 
yesterday, but got tripped up by some changes in Wine since the CrossOver 12 
base.)

-Ken

Re: Making wine default to the Mac Driver on OS X

[Alexandre Julliard]

Josh DuBois  writes:

> On 3/4/13 4:28 AM, Per Johansson wrote:
>> I agree that the default on mac should be mac,x11, but I don't
>> really see the reason an override can't be set in registry. Is it
>> just because registry is considered too complicated to modify?
> I think one concern is not forcing people to mod the registry in order
> to run remote X.  It's true that if you're in a situation where one
> display driver flatly won't work, a requirement that one change the
> registry to switch to another is onerous because you can't run any
> graphical utility (winecfg, regedit) to change the setting in that
> case.  That's why an environment variable is useful.  Of course, if we
> have ENVVAR --> registry --> hardcoded default, you have the ability
> to control things via the registry or the environment, depending what
> you want to do.

The goal should be to automatically do the right thing, as far as
possible. Adding an environment variable that the user needs to know
about isn't going in the right direction.

-- 
Alexandre Julliard
julli...@winehq.org

Re: wanted: testbot w9x machines

[fgouget]

On Mon, 4 Mar 2013, joerg-cyril.hoe...@t-systems.com wrote:
[...]
> All that I can remember when that issue was raised last time was:
> 1. It's good not to test incoming patches against w9x behavior,
>   because the time spent adding broken() for those is better
>   invested adding code and more tests for w2k-w7 machines.  Agreed.
> 
> 1' test.winehq.org need no more display w9x test results.  I don't care much.

That's mostly what I meant by "the Wine community is not interested in 
these anymore" (especially in the context of running WineTest daily: 
there's no point since I cannot even submit the results).


> Please, PLEASE give me a (new)testbot with some w9x machines such that I can
> investigate the winmm&mci behavior that the apps written in that era 
> encountered.
> 
> It really slows down development on my side *not* to have an easily
> checked w9x system (nor a system for 16 bit tests, BTW).

I'm not opposed to it but that would mean buying new known legit 
licenses as we cannot reuse the ones of the old TestBot (they don't 
belong to us). So I'm not sure it will happen.


[...]
> Currently, (new)testbot doesn't even offer an option to run tests on 
> w9x machines. I'm not asking for that option to be on by default, I'm 
> just begging for it to be present!

I can confirm that the Win9x VMs have been removed from the old testbot 
at some point: I don't see them in the VM table.


-- 
Francois Gouget 

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Francois Gouget]

On Tue, 5 Mar 2013, Dmitry Timoshkov wrote:

> Francois Gouget  wrote:
> 
> > > > The goal of the Wine tests is to document the Windows behavior that 
> > > > Windows applications expect.
> > > 
> > > Skipping a test because your VM is broken doesn't qualify as a 
> > > documentation
> > > of Windows behaviour.
> > 
> > The VM is not broken so the skip is ok (thanks for not bringing anything 
> > new to the table: it means I don't have to update my answer which makes 
> > this simpler).
> 
> A test is supposed to pass on a not broken Windows XP configuration,
> otherwise there wouldn't much point in creating the test.

Sure, let's camp.
That's good because the VM is not broken so the skip is ok.


> > > I don't think that you have resources and intention to have Windows VMs 
> > > with
> > > all possible pre/post SP/hotfixes configurations.
> > 
> > I certainly intend to make it possible for Wine developers to run their 
> > tests on most significant Windows configurations and that includes each 
> > service pack and Internet Explorer version. It's not as resource 
> > intensive as you seem to think (*). Now that's different from the set of 
> > Windows configurations that every Wine patch will be run on. That will 
> > be a subset decided by the community.
> 
> My concern is not about computer resources, I'm sure you have plenty of
> spare CPU cycles to burn. The concern is about how far are you planning
> to go, and time it takes to manage. Microsoft releases hotfixes 1-2 times
> in a month, are you inteding to have VMs for every possible state of
> SPs+hotfixes?

Don't be silly, theer are hundred of hotfixes. As I already said, I 
intend to cover Service Packs, and Internet Explorer versions. I don't 
intend to provide arbitrary combinations of these either. What intend to 
do is follow a Windows machine's normal upgrade path. For instance for 
Windows XP my personal VM covers SP1 (+IE 6+WMP 8+DirectX 8), then adds 
SP2 (+.Net 1.0+WMP 9+DirectX 9.0c), then upgrades that to IE 7 (+.Net 
1.1+WMP 10), then adds SP3 (+.Net 3.5+WMP 11) progression, then upgrades 
to IE 8 (+Silverlight) and finally has a last configuration with the 
more recent updates. Note that this last configuration is the only one 
that requires maintenance.


> There are already some distinct things in each Windows VM to worry 
> about (video, sound, locale, CD, etc.), so it becomes pretty critical 
> to make wise decisions about what configurations you consider as 
> major, and which of them you really want to manage.

Yes, each VM needs a good reliable foundation to build on. So particular 
attention must be given to the initial video, sound and it turns out 
network (with QEmu) hardware and driver configuraion. But that's 
independent of the number of test configurations you then add to the VM.

I consider the locale, CD and other variations to be independent from 
Windows version tests. So for instance all locale tests will likely be 
done on Windows 7 SP1 until that configuration is obsolete, which I 
expect will not be before a couple of years at least. I also intend to 
combine some tests to reduce the number of test configurations. For 
instance I don't think it would be an issue if the only configuration 
that has an Joliet+Rockridge CD is also the one that has two network 
cards and no sound card.

-- 
Francois Gouget 

wanted: testbot w9x machines

[Joerg-Cyril.Hoehle]

Hi,

Francois Gouget wrote in another thread:
>Not so long ago that machine was also running the tests on 5 additional 
>NT4 configurations, Windows 95, Windows 98 and Windows Millenium. It no 
>longer does, not because of lack of 'resources' or 'intention', but 
>because the Wine community is not interested in these.
Huh? What?

Please, PLEASE give me a (new)testbot with some w9x machines such that I can
investigate the winmm&mci behavior that the apps written in that era 
encountered.

It really slows down development on my side *not* to have an easily
checked w9x system (nor a system for 16 bit tests, BTW).

All that I can remember when that issue was raised last time was:
1. It's good not to test incoming patches against w9x behavior,
  because the time spent adding broken() for those is better
  invested adding code and more tests for w2k-w7 machines.  Agreed.

1' test.winehq.org need no more display w9x test results.  I don't care much.

2. Some technical aspects, such as not being able to find Greg's old w95
  VM image, or producing a VM image with some soundcard not hanging randomly.

But I can't remember an argument saying like "nobody was interested
in those w95/w98/w98SE/wME machines, so we dumped them".

Currently, (new)testbot doesn't even offer an option to run tests on w9x 
machines.
I'm not asking for that option to be on by default, I'm just begging for it to 
be present!

Thank you,
Jörg Höhle

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Dmitry Timoshkov]

Francois Gouget  wrote:

> > > The goal of the Wine tests is to document the Windows behavior that 
> > > Windows applications expect.
> > 
> > Skipping a test because your VM is broken doesn't qualify as a documentation
> > of Windows behaviour.
> 
> The VM is not broken so the skip is ok (thanks for not bringing anything 
> new to the table: it means I don't have to update my answer which makes 
> this simpler).

A test is supposed to pass on a not broken Windows XP configuration,
otherwise there wouldn't much point in creating the test.

> > I don't think that you have resources and intention to have Windows VMs with
> > all possible pre/post SP/hotfixes configurations.
> 
> I certainly intend to make it possible for Wine developers to run their 
> tests on most significant Windows configurations and that includes each 
> service pack and Internet Explorer version. It's not as resource 
> intensive as you seem to think (*). Now that's different from the set of 
> Windows configurations that every Wine patch will be run on. That will 
> be a subset decided by the community.

My concern is not about computer resources, I'm sure you have plenty of
spare CPU cycles to burn. The concern is about how far are you planning
to go, and time it takes to manage. Microsoft releases hotfixes 1-2 times
in a month, are you inteding to have VMs for every possible state of
SPs+hotfixes? There are already some distinct things in each Windows VM
to warry about (video, sound, locale, CD, etc.), so it becomes pretty
critical to make wise decisions about what configurations you consider
as major, and which of them you really want to manage.

-- 
Dmitry.

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Francois Gouget]

On Tue, 5 Mar 2013, Dmitry Timoshkov wrote:

> Francois Gouget  wrote:
> 
> > The goal of the Wine tests is to document the Windows behavior that 
> > Windows applications expect.
> 
> Skipping a test because your VM is broken doesn't qualify as a documentation
> of Windows behaviour.

The VM is not broken so the skip is ok (thanks for not bringing anything 
new to the table: it means I don't have to update my answer which makes 
this simpler).


> I don't think that you have resources and intention to have Windows VMs with
> all possible pre/post SP/hotfixes configurations.

I certainly intend to make it possible for Wine developers to run their 
tests on most significant Windows configurations and that includes each 
service pack and Internet Explorer version. It's not as resource 
intensive as you seem to think (*). Now that's different from the set of 
Windows configurations that every Wine patch will be run on. That will 
be a subset decided by the community.

By the way, you should really check out test.winehq.org one of these 
days. You'd see that I already run WineTest on 25 different Windows 
configurations, *every day*, on my desktop. These range from NT4 to 
Windows 7 (64-bit) and cover most service packs, Internet Explorer 
versions, and even some language / locale variations. I would really 
find it disappointing if the WineTestBot could not offer that kind of 
coverage to Wine developers.

Not so long ago that machine was also running the tests on 5 additional 
NT4 configurations, Windows 95, Windows 98 and Windows Millenium. It no 
longer does, not because of lack of 'resources' or 'intention', but 
because the Wine community is not interested in these.

Additionally that same desktop still runs WineTest on Linux (4 
configurations), FreeBSD (2 VMs) and Solaris (3 VMs) daily. That should 
give you a better perspective on what's possible.


(*) http://bugs.winehq.org/show_bug.cgi?id=31784

-- 
Francois Gouget , 

Re: Making wine default to the Mac Driver on OS X

[Josh DuBois]

On 3/4/13 4:28 AM, Per Johansson wrote:
I agree that the default on mac should be mac,x11, but I don't really 
see the reason an override can't be set in registry. Is it just 
because registry is considered too complicated to modify?
I think one concern is not forcing people to mod the registry in order 
to run remote X.  It's true that if you're in a situation where one 
display driver flatly won't work, a requirement that one change the 
registry to switch to another is onerous because you can't run any 
graphical utility (winecfg, regedit) to change the setting in that 
case.  That's why an environment variable is useful.  Of course, if we 
have ENVVAR --> registry --> hardcoded default, you have the ability to 
control things via the registry or the environment, depending what you 
want to do.

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Dmitry Timoshkov]

Nikolay Sivov  wrote:

> >> The goal of the Wine tests is to document the Windows behavior that
> >> Windows applications expect.
> > Skipping a test because your VM is broken doesn't qualify as a documentation
> > of Windows behaviour.
> Why is that broken?

It's broken because the test is supposed to pass.

> Tests results could be submitted by anyone running 
> Windows with or without updates.

Sending broken results doesn't mean that the tests need to be fixed.

> Currently test just returns, with this patch it prints a possible 
> reason. What's a problem?

If that's supposed to be a way how a failing (under official Wine testbot)
test will be "fixed" in future that's not acceptable.

-- 
Dmitry.

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Nikolay Sivov]

On 3/4/2013 19:30, Dmitry Timoshkov wrote:

Francois Gouget  wrote:


The goal of the Wine tests is to document the Windows behavior that
Windows applications expect.

Skipping a test because your VM is broken doesn't qualify as a documentation
of Windows behaviour.
Why is that broken? Tests results could be submitted by anyone running 
Windows with or without updates.
Currently test just returns, with this patch it prints a possible 
reason. What's a problem?


I don't think that you have resources and intention to have Windows VMs with
all possible pre/post SP/hotfixes configurations. Having just one regualrly
updated one should be more than enough.

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Dmitry Timoshkov]

Francois Gouget  wrote:

> The goal of the Wine tests is to document the Windows behavior that 
> Windows applications expect.

Skipping a test because your VM is broken doesn't qualify as a documentation
of Windows behaviour.

I don't think that you have resources and intention to have Windows VMs with
all possible pre/post SP/hotfixes configurations. Having just one regualrly
updated one should be more than enough.

-- 
Dmitry.

Re: [1/3] Revert "gdiplus: Add support for StringFormatFlagsNoClip."

[Vincent Povirk]

Yay, thanks for fixing this. +1 :D

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Francois Gouget]

On Mon, 4 Mar 2013, Dmitry Timoshkov wrote:

> Francois Gouget  wrote:
> 
> > On Windows XP most versions of gdiplus (i.e. older than 5.2) do not support 
> > TIFF.
> 
> I'd suggest to upgrade the VM instead.

I intend to upgrade the VM. However I don't consider upgrading it and 
fixing the test as being mutually exclusive.


> Ideally each VM should represent a Windows version with newest service 
> pack installed it's supposed to run the tests on, otherwise that VM is 
> useless. IMHO there is no point in changing the tests to workaround a 
> broken VM state.

I disagree with your 'ideal' and I don't regard a Windows system that is 
not running the very latest updates as broken. Also note that installing 
Windows XP's latest service pack is not sufficient to fix this (you need 
unidentified post-SP3 updates).

The goal of the Wine tests is to document the Windows behavior that 
Windows applications expect. For a long time people held off on 
installing Windows XP's SP2 and then SP3 for various reasons so that 
most applications could not depend on them being installed. Of course a 
lot has happened since so our standards on the applications expectations 
must evolve. It also depends about how much we care about old Windows 
applications.

As far as the WineTestBot is concerned I expect the community, rather 
than me, to set the policy on this. So far the consensus seems to be 
that for XP and older we don't care about running the tests on versions 
that don't have the latest service pack. So that's what I'm working on. 
For Windows 7 however I believe the goal is to run the tests in both 
pre-SP1 and post-SP1 environments. (I'm not sure about the consensus for 
those in between).


That said I also consider that the tests should not fail for no good 
reason. That only leads to situations where winetest only succeeds on 
Alexandre's machine. Lack of TIFF support seems easy to deal with and 
since it's normal for slightly out of date systems I think a win_skip() 
is appropriate.


-- 
Francois Gouget 

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.

[Dmitry Timoshkov]

Francois Gouget  wrote:

> On Windows XP most versions of gdiplus (i.e. older than 5.2) do not support 
> TIFF.

I'd suggest to upgrade the VM instead. Ideally each VM should represent
a Windows version with newest service pack installed it's supposed to run
the tests on, otherwise that VM is useless. IMHO there is no point in
changing the tests to workaround a broken VM state.

-- 
Dmitry.

Re: Use accented letters in their names.

[Frédéric Delanoy]

On Fri, Mar 1, 2013 at 5:01 PM, Tae Wong  wrote:
> The authors file is outdated and you want this updated with the
> missing authors. Andrej Znidarsic should have Slovenian accented
> letters for his last name.
>
> On 2/4/13, Tae Wong  wrote:
>> You will want to use accented letters in their authors names.
>>
>> Caolan McNamara
>> Ferenc Wagner
>> Marko Nikolic
>>
>> Every once and a while the GNOME Live website is down with an error on
>> Netscape called “The operation timed out when attempting to contact .”
>> - This paragraph should have a website name. You want to be unbanned
>> in Amaterasu Translations and the DOS ain’t dead forums.

Feel free to send a patch to wine-patches fixing those issues.

Frédéric

Re: comctl32/imagelist: use DDB instead of 16-color bitmaps

[Alexandre Julliard]

Daniel Jelinski  writes:

> Subject: [PATCH 1/2] comctl32/imagelist: use DDB instead of 16-color bitmaps
>
> I don't know if DDB is a good option here, but 32bit color resulted in
> invisible images, and anything is better than the current 16 colors

Some test cases would be a good idea.

-- 
Alexandre Julliard
julli...@winehq.org

Re: Making wine default to the Mac Driver on OS X

[Per Johansson]

On Sat, Mar 2, 2013 at 7:20 PM, Josh DuBois  wrote:
> With Friday's release, I am interested in making the Mac Driver wine's
> default on OS X.  My own immediate motivation is largely so we at
> CodeWeavers can start testing it as a default internally (which obviously we
> can do on our own, regardless, if needed), but I figured I'd ask the wider
> community to see whether it's time in winehq also.

Is it really ready yet? As far as I can tell, the OpenGL fixes are not
yet committed.

>
> My question is how it should be configured from a user perspective. Right
> now one can set a registry key in
>
> HKCU/Software/Wine/Drivers/Graphics
>
> with a comma-separated list specifying the driver load order, and the first
> one successfully loaded will be used.  Absent the key, there is a hardcoded
> load order in user32/driver.c.  Right now that is just "x11."
>
> Discussing with Alexandre the other day I believe his thought is to make the
> hardcoded default "x11,mac" in all cases (including Linux).  I believe (and
> I don't mean to put words in his mouth) that his thought is that a user
> should never have to edit the registry to switch between drivers.  The
> thought would be that in order to switch between drivers, a user must
> instead create an environment in which all drivers which are ahead of the
> desired driver in the hardcoded load order will fail to load.  I think that
> in the specific case of "x11,mac" on an OS X box, the thought was to unset
> DISPLAY if you want to run with the Mac Driver on, forcing X11 to fail and
> therefore getting the fallback.

I don't think this is a good idea. Consider this case:

User is happily using wine with mac driver.
User installs XQuartz for reasons unrelated to wine.
Suddenly wine is using X11 driver instead of mac driver.
User is now unhappy (maybe).

> I propose an environment variable, WINEDRIVERLOADORDER.  I would think we
> would first use the registry value, then the value of WINEDRIVERLOADORDER,
> then the hardcoded fallback.  I would also propose making the hardcoded
> fallback differ on OS X and linux, so that a user who does nothing on OS X
> can have the Mac Driver, but someone who wants X11 can set
> WINEDRIVERLOADORDER and switch to that without editing the registry.
>
> Is that an acceptable approach?

I agree that the default on mac should be mac,x11, but I don't really
see the reason an override can't be set in registry. Is it just
because registry is considered too complicated to modify? I'd suggest
making a setting in winecfg in that case. Virtual desktop is already
there and has a similarly large impact.

Environment variables feel a bit too volatile to be depended upon.
Launching from terminal or through desktop very well might have
different variables set. If global configuration is needed, it should
be through a configuration file, IMO. wine.inf could handle it, except
it's overwritten when upgrading.

Regards,
-- 
Per Johansson

Re: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) test failure

[GOUJON Alexandre]

Hi Detlef,

On 03/03/2013 10:23 PM, Detlef Riekenberg wrote:

Hi Alexandre.

I have a test failure on my win7 Machine, while a valid cd was in the 
dvd drive.
volume.c:785 
: 
Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, 
last error = 1785


Example result:
http://test.winehq.org/data/209b58c64e6181c9bf448cb4f3130d3ba705c5d2/win7_dr-w7sp1-wow-p6100/kernel32:volume.html
(The same failure is present, when running the 64bit test)

Other machines are also affected.
Example:
http://test.winehq.org/data/4a685ebea343efdcb433f8d710b0c9f902e471fa/win7_matt/kernel32:volume.html
Error 1785 is ERROR_UNRECOGNIZED_MEDIA wich means "The disk media is not 
recognized. It may not be formatted."
All I can do is to add a skip() or maybe a broken() call to continue the 
test.



You wrote the tests, which where comitted on 12. July 2012:
http://source.winehq.org/git/wine.git/commitdiff/a3b5dd2dff0d04fe317f00282ccb0488e4803015

What media did you use, to test your code?
Data-DVD, Video-DVD, Empty DVD, Data-CD, Video-CD, Audio-CD, Empty CD, 
No Disc in Drive

What results did you get on Windows and Unix?

As many developpers, I tried with things I had at home.
I tested on a XP or 7 (I don't recall, maybe both) VM with a (Video) 
DVD, a computer game (The Sims 3) DVD, a Ubuntu DVD version and I also 
toyed with mkisofs to generate some ISO for me.

And yes, I tested my patch on linux before sending it upstream.


On Linux, mounting the example CD works perfect, but your test fails:
volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE 
(DvdPhysicalDescriptor) failed, last error = 87
Error 87 is ERROR_INVALID_PARAMETER wich is probably returned from 
http://source.winehq.org/source/dlls/ntdll/cdrom.c#L2546 meaning the 
ioctl() call failed for some reason.


You know, this function is essentially a wrapper of ioctl() so if you 
see a failure, you should have a look at /var/log/messages.
You may also add a TRACE with strerror() to know exactly what happens 
but I fear you would only get something like "Device not supported" or 
"not ready" or something like that.



Your test only read the DVD descriptor.

To fix your test, I suggest, that you add a trace to dump the
*_READ_STRUCTURE IoControl result and add similar tests
for the other media formats.

I also tested with a different Data-CD and got the same failure on 
linux (last error = 87).


You can check the image yourself:
http://www.memtest86.com/downloads/memtest86-4.1.0-iso.zip
(Burned on a CD)

That all winetest vm are missing optical media is a different issue:
http://bugs.winehq.org/show_bug.cgi?id=31780


--
By by ... Detlef

Dumping may help you but as we only take the result of ioctl() to feed 
the different fields of a structure, I don't really see what we can do 
.. except modifying the code in the kernel to return what we expect.

Re: Raise the minimum version of FreeBSD to 8.0.

[Tijl Coosemans]

On 04-03-2013 01:54, Frédéric Delanoy wrote:
> On Sun, Mar 3, 2013 at 12:22 AM, Gerald Pfeifer  wrote:
>> We've had this as a requirement in the FreeBSD ports for quite a
>> while (and the Wiki describes some background).
>>
>> Gerald
>> ---
>> -  FreeBSD 7.0 or later
>> +  FreeBSD 8.0 or later
>> ...
>>  FreeBSD info:
>> -  Wine will generally not work properly on versions before FreeBSD 7.0.
>> +  Wine will generally not work properly on versions before FreeBSD 8.0.

Maybe just remove this sentence since it's redundant.