On Tue, Dec 8, 2009 at 1:01 AM, Maarten Lankhorst
wrote:
> Austin English schreef:
>>
>> Vincent asked me to get add a --with-wine64 option to my build script.
>> I was testing around, and can't seem to get it to work:
>> $ mkdir - p $HOME/wine{32,64}
>> $ cd $HOME/wine64
>> $ ~/wine-git/configure
On 12/08/2009 12:58 AM, Juan Lang wrote:
-ok(ret, "WinHttpSetDefaultProxyConfiguration failed: %d\n",
GetLastError());
+ok(ret || GetLastError() == ERROR_ACCESS_DENIED,
+ "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError());
-set_default_proxy_reg_value( saved_p
Austin English schreef:
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-w
On 12/07/2009 11:38 PM, Detlef Riekenberg wrote:
On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote:
Some test failures are shown on boxes with long printernames, for example:
http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html
http:
Hi Reif,
2009/12/8 Robert Reif :
> Francois Gouget wrote:
>>
>> Also, as far as I know, DirectSound works on top of all our backend
>> drivers.
>>
>>
>
> It works through the WAVE API on most drivers which
> requires software mixing and format conversions. Even
> the direct sound drivers only imp
Peter Kovacs wrote:
> I think Austin is right, stopping Hacks would slow down development.
> And we need people hacking.
I'm not against hacks. I'm against dirty hacks, especially going into bugzilla!
What's a dirty hack? Something that adds commented out code, comments out
original code instead o
On Mon, Dec 7, 2009 at 9:30 PM, Steven Edwards wrote:
> This looks similar to the cross-compile build for mingw where you need
> a checkout with the normal tools built for your host and then another
> checkout for your target. You then run and point the target configure
> at the host wine path to
On Mon, Dec 7, 2009 at 7:44 PM, Austin English wrote:
>> checking for the directory containing the Wine tools... configure: error:
>> could not find Wine tools in ~/wine64/
> ~/wine-git/configure --with-wine64=~/wine64/tools/
> ...
> checking for the directory containing the Wine tools... config
2009/12/8 Peter Kovacs :
> I think Austin is right, stopping Hacks would slow down development.
> And we need people hacking.
Bugzilla is not the right place for hacks. There is a wine-hacks
repository (naturally, completely unsupported by WineHQ). If a hack
developer wants the hack to be consider
Francois Gouget wrote:
Also, as far as I know, DirectSound works on top of all our
backend drivers.
It works through the WAVE API on most drivers which
requires software mixing and format conversions. Even
the direct sound drivers only implement a single
hardware buffer which means that ev
On Mon, 7 Dec 2009, Robert Reif wrote:
[...]
> Can we drop all current audio drivers now that don't have midi?
> Any driver that doesn't implement the complete winmm API and
> direct sound shouldn't be in the current tree anyway.
I don't see why drivers that don't support MIDI should be dropped.
Hi again,
Vitaliy this are great news. I will see if I can read a bit more about XI2. :-D
Keep going. You will crack that Bug. Ill try to help if i can steal Time from
somewhere. But Honestly I am no Hacker. So don't expect to much of me.
I am happy if I can solve the hacks vs. patch problem :P
Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
> check
Maarten Lankhorst wrote:
The lack of an accelerated dsound interface isn't that big, just means
I wish accelerated direct sound had been a big issue. Both OSS and alsa
theoretically could support it under very limited circumstances but
there was no guarantee that it could be supported under
On Sun, Nov 29, 2009 at 11:37 PM, Austin English
wrote:
> On Sun, Nov 29, 2009 at 5:45 AM, Henri Verbeet wrote:
>> 2009/11/20 Austin English :
>>> Been happening for a few days...not sure what triggered it, but when
>>> coming back from work I see my login screen, which explains the lack
>>> of 6
Hello,
2009/12/8 Robert Reif :
...
> Can we drop all current audio drivers now that don't have midi?
> Any driver that doesn't implement the complete winmm API and
> direct sound shouldn't be in the current tree anyway.
I wish, but aj wouldn't even let me delete winenas.drv that has been
obviously
Francois Gouget wrote:
On Sun, 6 Dec 2009, Stefan Dösinger wrote:
[...]
So you mean keeping the existing infrastructure around just for midi
and have something entirely different for the rest of the audio
features?
That might nt be too bad in that we could still drop all the current
On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote:
> Some test failures are shown on boxes with long printernames, for example:
>
> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html
> http://test.winehq.org/data/17b7ee13fb55e872902be
On Mon, Dec 7, 2009 at 11:00 PM, Ken Thomases wrote:
> On Dec 6, 2009, at 10:08 AM, Stefan Dösinger wrote:
>
>> Am 06.12.2009 um 15:32 schrieb Roderick Colenbrander:
>>> This audio engine is quite similar to
>>> pulseaudio and it offers functionality like per stream volume which
>>> normal APIs li
On Dec 6, 2009, at 10:08 AM, Stefan Dösinger wrote:
> Am 06.12.2009 um 15:32 schrieb Roderick Colenbrander:
>> This audio engine is quite similar to
>> pulseaudio and it offers functionality like per stream volume which
>> normal APIs like oss/alsa/openal don't offer, so these APIs would map
>> be
On Mon, Dec 7, 2009 at 10:17 PM, Henri Verbeet wrote:
> 2009/12/7 Roderick Colenbrander :
>> Use this version instead. The last version contained some updates to
>> the wined3d winediag patch.
>>
> Sending this to winediag does mean it won't show up in +wgl traces
> anymore. Do we want that?
>
I
2009/12/7 Roderick Colenbrander :
> Use this version instead. The last version contained some updates to
> the wined3d winediag patch.
>
Sending this to winediag does mean it won't show up in +wgl traces
anymore. Do we want that?
On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen
wrote:
> Peter Kovacs wrote:
>> Now Vitaliy Margolen actively stopped the
>> maintenance of this workarounds (in the bug called dirty hacks.), by
>> marking the patches obsolete and changing title.
> Yes, tried to, of course I can't stop anyone from
On Mon, Dec 7, 2009 at 12:46 PM, Mike Kronenberg
wrote:
> This can be easily done, I've integrated lately similar functionality in
> WineBottler.
> If You already have the png only the sipping part of this little script is
> needed.
>
> createIconsFromExe.sh
Oh sure, we can do it now, but like
On 07.12.2009, at 18:08,
wrote:
> .png are created today in ~/.local/share/icons/ by Wine on Mac and
> Linux. (It used to be .xpm in the past and configure must detect
> libpng). Note that .png is mere *output* from Wine because that's
> what FreeDesktop wants as input (and .xpm).
> Judging
Jacek Caban wrote:
Hi Andrew,
This idea looks bad. What are you trying to fix?
Test case attached. When using
'document.frames.someFrame.someVariable', Wine currently fails looking
up 'someVariable' as FrameElement doesn't have a get_dispid function.
This patch forwards the lookup to some
Hi,
>I still am not sure I understand the problem. Using start /unix should
>not be required
I'm sorry for the confusion. Forget everything about start /unix. I don't
use it and mentioned it because there are some posts in the forum
where somebody is fighting with it and the app's current direct
On Mon, Dec 7, 2009 at 15:41, Vitaliy Margolen wrote:
> Peter Kovacs wrote:
>> So how can we get a proper Fix or point people towards proper fixes?
> Make Wine use Xi2 (I'm already working on it). Hopefully will have something
> available before holidays.
Thank you very much for your work. It ha
Stefan Dösinger wrote:
> A related topic: How do Joysticks connected to the gameport work(which is the
> same hardware connector as MIDI). I think that a joystick already takes an
> entirely different path in the
Linux kernel and it doesn't get anywhere near a sound system, so we
don't have to bo
Peter Kovacs wrote:
> Now Vitaliy Margolen actively stopped the
> maintenance of this workarounds (in the bug called dirty hacks.), by
> marking the patches obsolete and changing title.
Yes, tried to, of course I can't stop anyone from hacking and posting their
work, even on the same bug. All I can
On 12/07/2009 02:45 PM, Henri Verbeet wrote:
How does the attached patch work?
Both don't crash on my Win7-64 VMware box and no problems on my Win7-32
VMware box either.
--
Cheers,
Paul.
How does the attached patch work?
diff --git a/dlls/d3d10/d3d10_main.c b/dlls/d3d10/d3d10_main.c
index 10bf533..65ce1e0 100644
--- a/dlls/d3d10/d3d10_main.c
+++ b/dlls/d3d10/d3d10_main.c
@@ -124,7 +124,7 @@ HRESULT WINAPI D3D10CreateDevice(IDXGIAdapter *adapter,
D3D10_DRIVER_TYPE driver
}
Reece Dunn wrote:
> 2009/12/7 Francois Gouget
>> On Sun, 6 Dec 2009, Reece Dunn wrote:
>> [...]
>>> If Wine is going to go down the Windows 7 audio route, why not
>>> redirect everything to pulseaudio?
>> Is PulseAudio supported on Mac OS X, FreeBSD and Solaris?
>> If not then we'd need an alterna
On Sun, 6 Dec 2009, Stefan Dösinger wrote:
[...]
> So you mean keeping the existing infrastructure around just for midi
> and have something entirely different for the rest of the audio
> features?
That might nt be too bad in that we could still drop all the current
current winmm audio backends
2009/12/7 Paul Vriens :
> If you don't mind creating that patch, be my guest. Do you have a real
> Windows 64-bit box for testing?
>
Ok, I'll write something. I don't have any Win64 boxes at the moment,
real or virtual :-\
> I don't see a crash for D3D10CoreCreateDevice() but if it's stack corrupt
On 12/07/2009 01:51 PM, Henri Verbeet wrote:
2009/12/7 Paul Vriens:
The attached does the trick. Is that what you meant?
Close enough, I meant "void *arg5", but it comes down to the same
thing. Note that if you're going to send a patch for this you'll need
to change the prototypes and spec in
On Mon, 7 Dec 2009, Reece Dunn wrote:
[...]
> > Is PulseAudio supported on Mac OS X, FreeBSD and Solaris?
> > If not then we'd need an alternative for these platforms.
>
> http://www.pulseaudio.org/wiki/AboutPulseAudio#SupportedOperatingSystems:
> * Linux (any modern distribution)
> * Sola
2009/12/7 Paul Vriens :
> The attached does the trick. Is that what you meant?
>
Close enough, I meant "void *arg5", but it comes down to the same
thing. Note that if you're going to send a patch for this you'll need
to change the prototypes and spec in dxgi and d3d10core as well. I can
do that as
On 12/07/2009 12:14 PM, Henri Verbeet wrote:
2009/12/7 Paul Vriens:
When I add the following (first thing):
BOOL is_wow64;
IsWow64Process( GetCurrentProcess(),&is_wow64 );
the tests crashes at DXGID3D10CreateDevice() in create_device().
I added that IsWow64Process() just to see if I was inde
Hi there,
I want to bring this Issue up in Development Mailinglist. This proplem is about
a bug that cant be fixed within wine, and The Bugtracker doesnt help it. I
think this Bug is at the moment an Epic Fail of Open Source Development.
(And needs to be solved so we get a accepted Fix somewhere
Hi Andrew,
This idea looks bad. What are you trying to fix?
Jacek
2009/12/7 Francois Gouget
>
> On Sun, 6 Dec 2009, Reece Dunn wrote:
> [...]
> > If Wine is going to go down the Windows 7 audio route, why not
> > redirect everything to pulseaudio?
>
> Is PulseAudio supported on Mac OS X, FreeBSD and Solaris?
> If not then we'd need an alternative for these platf
On Mon, Dec 7, 2009 at 11:53 AM, Francois Gouget wrote:
> On Sun, 6 Dec 2009, Reece Dunn wrote:
> [...]
>> If Wine is going to go down the Windows 7 audio route, why not
>> redirect everything to pulseaudio?
>
> Is PulseAudio supported on Mac OS X, FreeBSD and Solaris?
> If not then we'd need an a
2009/12/7 Paul Vriens :
> When I add the following (first thing):
>
> BOOL is_wow64;
>
> IsWow64Process( GetCurrentProcess(), &is_wow64 );
>
> the tests crashes at DXGID3D10CreateDevice() in create_device().
>
> I added that IsWow64Process() just to see if I was indeed running the 64bit
> version o
Hi Henri,
I'm trying to fix at least the crashes on X64_64 for this test. The
tests are done on a Windows 7 64bit VMware guest.
The strange thing is that when I crosscompile the tests as is (64bit of
course) the tests don't crash.
When I add the following (first thing):
BOOL is_wow64;
IsW
On Sun, 6 Dec 2009, Reece Dunn wrote:
[...]
> If Wine is going to go down the Windows 7 audio route, why not
> redirect everything to pulseaudio?
Is PulseAudio supported on Mac OS X, FreeBSD and Solaris?
If not then we'd need an alternative for these platforms.
That's also something that worries
46 matches
Mail list logo
