On Feb 13, 2012, at 7:09 PM, Dan Kegel wrote:
> On Mon, Feb 13, 2012 at 4:36 PM, Charles Davis
> wrote:
>>
>> ...our implementation can be written purely in C the same way all our COM
>> DLLs are.
>
> Or, come to think of it, we could write in Mono.
True, but do we really want a hard depende
On Mon, Feb 13, 2012 at 4:36 PM, Charles Davis wrote:
>> If it takes off, and someone feels like supporting it in Wine,
>> they would probably have to start by implementing the first
>> bits in C like wine's msvcp support.
> ...our implementation can be written purely in C the same way all our COM
On Feb 13, 2012, at 3:20 PM, Dan Kegel wrote:
> According to
> http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windows/19840
> Microsoft is not letting developers use win32 on arm (although
> Microsoft is probably using it themselves for Office on arm).
> Instead, native ap
On Mon, Feb 13, 2012 at 2:38 PM, Vincent Povirk wrote:
> I don't know where you're getting the idea that C++ is the primary way
> of accessing WinRT APIs.
? I was talking about implementing WinRT, not using it.
But it's true, if all apps talk to it via COM, the language
it's implemented in shoul
On 13 February 2012 22:20, Dan Kegel wrote:
> According to
> http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windows/19840
> Microsoft is not letting developers use win32 on arm (although
> Microsoft is probably using it themselves for Office on arm).
> Instead, native apps
I think it's way too early for this sort of speculation.
I don't know where you're getting the idea that C++ is the primary way
of accessing WinRT APIs. It's apparently a way of doing so, but that
doesn't mean it'll be the way most developers choose.
We also don't know whether the distribution mo
According to
http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windows/19840
Microsoft is not letting developers use win32 on arm (although
Microsoft is probably using it themselves for Office on arm).
Instead, native apps have to use WinRT, a C++-based class library.
Accordin
On Monday, February 13, 2012 10:31:06 PM Нискородов Серёжа wrote:
> Ok, I agree, many "junk devices", bad enumeration methods, okay. But
> why you are against a registry parameter? I'm a power user, I know
> WHAT I do, I want to see all ALSA devices, even "junk". Why I can't do
> that?
Mainly beca
2012/2/13 Chris Robinson :
> On Monday, February 13, 2012 8:37:42 PM Нискородов Серёжа wrote:
>> Chris Robinson wrote:
>> > It's not something normal users do, but for "power users" I don't see a
>> > problem with asking them to tell Wine about it.
>>
>> I'm a power user, but for what I have to wro
On Monday, February 13, 2012 8:37:42 PM Нискородов Серёжа wrote:
> Chris Robinson wrote:
> > It's not something normal users do, but for "power users" I don't see a
> > problem with asking them to tell Wine about it.
>
> I'm a power user, but for what I have to wrote device name in regedit,
> if I
>>Because if tomorrow I will add a new device to .asoundrc, I will also
>>have to add it to the WINE registry?
> Registry or winecfg, is there such a difference?
Difference is that I have to describe the device in wine while this
device is already described in .asoundrc.
> Elaborated approach:
>
On Monday, February 13, 2012 6:12:00 PM Нискородов Серёжа wrote:
> >> Here is another trouble with snd_ctl_open. Not all devices in alsa
> >> configuration files have a predefined ctl. Especially defined by user,
> >> for example I don't always define a ctls for all my devices in
> >> .asoundconf
>
Hi,
Нискородов Серёжа wrote:
>I really don't understand you. Why to write "plug:dmix" in wine,
>while you can configure ALSA devices natively via .asoundrc ?
plug:dmix is 9 characters, .asoundrc not well documented, with
features that even people who've been writing them for long can
learn any da
On Monday, February 13, 2012 2:17:13 PM joerg-cyril.hoe...@t-systems.com
wrote:
> Chris Robinson wrote:
> >Plain mmdevapi can't do rate conversions
> You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
Interestingly, this flag seems to only have an effect for already-initialized
streams. ALSA wo
On Monday, February 13, 2012 10:07:45 AM Andrew Eikum wrote:
> On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
> > Hmm, actually it seems winealsa already does this enumerating. Except it
> > hardcodes the plughw: prefix for the device string, uses the card index
> > instead of the
> Here's a stupid registry entry patch. The paths are:
> HKCU\Software\Wine\Drivers\winealsa.drv\ALSAOutputDevice
> HKCU\Software\Wine\Drivers\winealsa.drv\ALSAInputDevice
>
> If we can't reach a sensible consensus about device enumeration
> sometime this week, I'll submit this to fix 1.4.
I do no
> snd_ctl_name_hint() and friends:
> +Includes user-specified, non-hw devices as well as true hw devices, but:
> -Misses devices without 'hint' configs (Arch had this problem until a few
> weeks ago, other distros?)
In my Ubuntu 11.04 snd_ctl_name_hint() lists all my devices, that I
described in
>> Here is another trouble with snd_ctl_open. Not all devices in alsa
>> configuration files have a predefined ctl. Especially defined by user,
>> for example I don't always define a ctls for all my devices in
>> .asoundconf
>
> You can use the "hw:" prefix for snd_ctl_open. All you need it for is
On Mon, Feb 13, 2012 at 02:12:02PM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Bottom line IMHO:
> 1. Wine-1.4 MUST have a means to select something
>other than "default" without recompiling.
> 2. Via registry or winecfg, I don't mind.
>
> A stupid registry entry would be fine with me.
On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
> On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
> > Here is another trouble with snd_ctl_open. Not all devices in alsa
> > configuration files have a predefined ctl. Especially defined by user,
> > for example I do
> Bottom line IMHO:
> 1. Wine-1.4 MUST have a means to select something
> other than "default" without recompiling.
> 2. Via registry or winecfg, I don't mind.
>
> A stupid registry entry would be fine with me. At least, winecfg
> would remain void of GUI logic that's valid for winealsa only. U
Aric Stewart writes:
> Our registry or settings may have changed since initial start,
> especially on prefix creation, so rebuilg the internal system link
> each time.
I don't think you can do that. Other processes may be reading or writing
the keys at the same time.
--
Alexandre Julliard
jull
Hi,
Нискородов Серёжа wrote:
>Do you can play wav mono 11025Hz directly to your dmix51 device?
>Without "plug:" wrapper? With my soundcard I can't.
>So I can enumerate dmix*: devices to, I even can enumerate all
>devices, but I see almost no sence in this.
My Ubuntu dmix can't either.
All it acce
Hi,
Chris Robinson wrote:
>All but "dmix51:CARD=NVidia,DEV=0" is completely useless, and except for
>iec958, null, and the very bottom one, they all describe the same device
Now we've done a full circle. My feeling past bug #28723 comment #110
http://bugs.winehq.org/show_bug.cgi?id=28723#c110
w
Nikolay Sivov writes:
> This fixes printf overflow in error callback that I get sometimes with
> Outlook 2010, patch also changes a couple of similar cases.
>
> That's safe enough to include now.
Apparently not...
../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p
msxml3_test.exe.s
On 9 February 2012 14:04, wrote:
> did anyone else notice that since a few weeks, window titles are
> somehow not refreshed and/or half transparent?
> I'm typically using virtual desktop mode in Ubuntu Linux.
>
Yes, but afaik title bar redrawing has always been somewhat broken in
virtual desktop,
26 matches
Mail list logo
