It probably makes sense to marking old one as broken, as E_NOTIMPL sounds
better in this case. This could potentially break things of course if
application checks for strict equality of the error code.
On Thu, Dec 13, 2012 at 8:02 AM, Detlef Riekenberg wrote:
> winetestbot crash sometimes in co
Detlef Riekenberg wrote:
> -ok(hr == E_FAIL, "got 0x%08x.\n", hr);
> +/* win8: E_NOTIMPL */
> +ok(hr == E_FAIL || hr == E_NOTIMPL, "got 0x%08x.\n", hr);
A usual form for such comparisons is
ok(hr == E_FAIL || hr == E_NOTIMPL /* win8 */, "got 0x%08x.\n", hr);
that helps
On 12/11/2012 08:46 AM, Henri Verbeet wrote:
On 11 December 2012 16:05, wrote:
Cost to users:
Users with a working ALSA device "default" should experience no
drawback, only benefits. I believe this is the vast majority of users.
Users that edit their ~/.asoundrc to define other devices with
Has there been any further decision about this? I'll be at FOSDEM on behalf
of Razor and would love to sit in at the Wine talks.
J. Leclanche
On Thu, Nov 29, 2012 at 1:43 AM, Scott Ritchie wrote:
> On 11/12/12 11:59 AM, Jeremy White wrote:
>
>> We should stay in the same hotel if possible to
--- On Wed, 12/12/12, André Hentschel wrote:
> Am 12.12.2012 23:35, schrieb Hin-Tak
> Leung:
> > --- On Wed, 12/12/12, Josh DuBois
> wrote:
> >> wine-mono.
> >>
> >> On 12/12/12 4:27 PM, Hin-Tak Leung wrote:
> >>> I am somewhat curious about the tar ball - why
> is the
> >> version 12 source (12
> Thank you. That makes sense - that's the size of mono thereabouts. I guess my
> next question is, does it also have codeweaver-specific bits? Sorry this
> sounds rather lazy, but I am sure more than one person wants to know :-).
There are no CrossOver-specific changes to wine-mono. It's even t
Am 12.12.2012 23:35, schrieb Hin-Tak Leung:
> --- On Wed, 12/12/12, Josh DuBois wrote:
>> wine-mono.
>>
>> On 12/12/12 4:27 PM, Hin-Tak Leung wrote:
>>> I am somewhat curious about the tar ball - why is the
>> version 12 source (120MB) and so much bigger than the
>> previous (44MB)? I can probably
--- On Wed, 12/12/12, Josh DuBois wrote:
> wine-mono.
>
> On 12/12/12 4:27 PM, Hin-Tak Leung wrote:
> > I am somewhat curious about the tar ball - why is the
> version 12 source (120MB) and so much bigger than the
> previous (44MB)? I can probably work it out by downloading
> and unpacking both,
wine-mono.
On 12/12/12 4:27 PM, Hin-Tak Leung wrote:
I am somewhat curious about the tar ball - why is the version 12
source (120MB) and so much bigger than the previous (44MB)? I can
probably work it out by downloading and unpacking both, but I am
feeling lazy... Hin-Tak
--- On Wed, 12/12/12, Ken Thomases wrote:
> Greetings Wine community,
>
> As many of you may be aware, CodeWeavers just released
> CrossOver 12. We're pleased to announce that CrossOver
> 12 includes the long-awaited Mac driver. If you're not
> familiar with it, the Mac driver is an alternativ
Hi list,
Can someone help me get through the wineserver code for passing data
through a buffer in response to an ioctl?
Our (slightly out of date 1.3.24 version of) Wine is getting
INVALID_HANDLE_VALUE returned for FindFirstVolume. The problem is that
the FindNextVolume call inside FindFirst
Greetings Wine community,
As many of you may be aware, CodeWeavers just released CrossOver 12. We're
pleased to announce that CrossOver 12 includes the long-awaited Mac driver. If
you're not familiar with it, the Mac driver is an alternative to Wine's X11
driver for use on Mac OS X. It allow
On Wed, Dec 12, 2012 at 12:32 AM, Hans Leidekker wrote:
> On Tue, 2012-12-11 at 12:59 -0800, Juan Lang wrote:
> > Getting the client to trust the server cert can be as easy as ignoring
> untrusted
> > root errors, if you don't think this impacts the revocation results.
> >
> > Returning revocation
On Wed, Dec 12, 2012 at 04:45:11PM +0100, Henri Verbeet wrote:
> On 12 December 2012 16:31, Andrew Eikum wrote:
> > Even ignoring the Pulse case, we don't have an acceptable enumeration
> > API.
> Yes, I know. I just don't think it would be unreasonable to try to
> work with ALSA upstream to fix t
On 12 December 2012 16:31, Andrew Eikum wrote:
> Even ignoring the Pulse case, we don't have an acceptable enumeration
> API.
Yes, I know. I just don't think it would be unreasonable to try to
work with ALSA upstream to fix that.
On Wed, Dec 12, 2012 at 03:57:40PM +0100, Henri Verbeet wrote:
> On 12 December 2012 15:28, Andrew Eikum wrote:
> > It's tricky because ALSA and PulseAudio have different theories about
> > where device selection should occur -- in the application or in the
> > audio mixer. In the ALSA case, we wa
On Wed, Dec 12, 2012 at 04:23:52PM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Max TenEyck Woodbury objected:
> >Replacing the ability to use a drop box in the app to select the audio
> >device with a 'regedit' session is not an improvement.
> My proposal intentionaly was silent about GUI cha
On 12 December 2012 16:23, wrote:
> Henri Verbeet suggested:
>>But supposedly we'll have a winepulse driver eventually, so winealsa
>>would only need to care about actual ALSA devices.
> Alas, it's only after you opened the device that you can discover that
> it's PulseAudio, at which time it is
Hi,
Henri Verbeet suggested:
>But supposedly we'll have a winepulse driver eventually, so winealsa
>would only need to care about actual ALSA devices.
Alas, it's only after you opened the device that you can discover that
it's PulseAudio, at which time it is too late.
Also, I don't know if PA is t
On 12 December 2012 15:28, Andrew Eikum wrote:
> It's tricky because ALSA and PulseAudio have different theories about
> where device selection should occur -- in the application or in the
> audio mixer. In the ALSA case, we want to list devices. In the Pulse
> case, we want to list only "default"
On Tue, Dec 11, 2012 at 04:46:34PM +0100, Henri Verbeet wrote:
> On 11 December 2012 16:05, wrote:
My first reaction is that this is a good idea. We've had some
discussion about device enumeration before. The final conclusion was
it's basically impossible to do usefully with ALSA. I can't think
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23356
Your paranoid android
On 12/11/2012 02:11 PM, Austin English wrote:
On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury
wrote:
On 12/11/2012 10:46 AM, Henri Verbeet wrote:
It will also pretty much just remove device selection on setup with
multiple audio devices, which is actually fairly common these days
with U
On Tue, 2012-12-11 at 12:59 -0800, Juan Lang wrote:
> Getting the client to trust the server cert can be as easy as ignoring
> untrusted
> root errors, if you don't think this impacts the revocation results.
>
> Returning revocation is straightforward enough, assuming you have a server
> under
>
On Sat, Dec 08, 2012 at 12:43:14AM +0400, Pavel Shilovsky wrote:
>
> The problem is the possibility of denial-of-service attacks here. We
> can try to prevent them by:
FWIW I already see a DoS 'attack'.
I have some filestore shared using NFS (to Linux and Solaris) and
using samba (to Windows).
25 matches
Mail list logo
