On 11/21/06, mengzhuo li [EMAIL PROTECTED] wrote:
Changlog: add wpcap.dll.so in wine, there are some wpcap functions added,
not all.
note: before configure, you should use autoreconf to generate a new
configure file.
Why are you adding this dll? Does it fix some app? I just looked
around
On Tue, Nov 21, 2006 at 07:10:30PM +0800, Dmitry Timoshkov wrote:
You could avoid a call to LeaveCriticalSection by moving
EnterCriticalSection
after the wined3d_fake_gl_context_available check.
This would make this sequence of events (perhaps only in theory)
possible:
release
If this is complete garbage please let me know, so i can stop working on
I think these patches make sense :-) Preferably we should get completely rid
of COM in wined3d. Well ok, the interface can stay, but the refcounting is
pain...
pgpZidc3vkMY9.pgp
Description: PGP signature
Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
Attached is my diff/patch for both an openal winmm driver and an
openal32.dll thunk
I would like to get these into wine -- please comment and stuff...
Hey great, I will test it with Jedi Knight: Jedi Academy, which uses openal
afaik :-)
James Hawkins wrote:
+@ stdcall pcap_setbuff(ptr long) wine_pcap_setbuff
As I said before, you don't need to forward these, just name the APIs
like they are in the spec file and it should work.
You can see that wine_pcap_close() calls pcap_close() which is a
function implemented in the
On 11/22/06, Tomas Carnecky [EMAIL PROTECTED] wrote:
James Hawkins wrote:
+@ stdcall pcap_setbuff(ptr long) wine_pcap_setbuff
As I said before, you don't need to forward these, just name the APIs
like they are in the spec file and it should work.
You can see that wine_pcap_close() calls
Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
Attached is my diff/patch for both an openal winmm driver and an
openal32.dll thunk
Just a question: Are the different openal versions backward compatible, or do
we have to ship a openal thunk for each openal version used by the games?
Good luck
And may the Sound be with you...
- Nick
From: Stefan Dösinger [EMAIL PROTECTED]
To: wine-devel@winehq.org
Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:
OpenALand DirectSound
Date: Wed, 22 Nov 2006 10:08:51 +0100
Am Dienstag 21 November 2006 12:03 schrieb
Hi, I am not so good at programming in C, but I would like to be
perfectly working in Direct3D 9.0c in the Wine. I dont know how much
work is on so if someone cold told me how far is the complementation
of the Direct3D 9.0c support in the Wine?
Here is the offer for everyone:
The aim is
They are backwards compat -- and my thunk is backwards compat too..
(it should compile for openal1.0, 1.1, 1.X -- I have only tested Mac OSX
10.4.8 OpenAL 1.1)
It is NOT efficent to be backwards compatible -- note my impl of AL_1_1,
ALC_1_1, AL_EXTS, ALC_EXTS -- they all check for the
Alex Villacís Lasso [EMAIL PROTECTED] writes:
This patch added the setlocale(LC_ALL, ) line to
dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been
failing since that time on non-English locales. I see now that setting
the locale around calls of sprintfW() is not thread-safe.
Hi,
That being said -- the impls for AL_1_0, ALC_1_0, ALUT (not freealut) --
are as good as they can be. They are straight shots thru to the api
(bouncing
from CDECL(win32) - ???(host???))
Afaik Linux libs are CDECL, if the win32 openal is CDECL too(not WINAPI /
STDCALL), can we pass the
Hi,
On Wed, Nov 22, 2006 at 11:53:22AM +0100, Mirek wrote:
The aim is to prepare all apps below working under the Windows on Nvidia
GF 6XXX series, with at least 50% of speed in WinXP. There is not needed
sound after merging those patches in cvs main head. I offer 1 000 Euro
or 1 200
Hi Henri,
I think you wrote unloadVertexData and unloadNumberedArrays. If I remember
correctly those were needed to deactivate stream sources so they do not make
issues in future draws where they shouldn't be active(3dmark2003 vbo
performance regression).
I noticed that loadVertexData already
Markus Amsler wrote:
@@ -4704,7 +4704,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl
TRACE((%p) : ppDecl=%p\n, This, ppDecl);
*ppDecl = This-stateBlock-vertexDecl;
-if (NULL != *ppDecl) IWineD3DVertexDeclaration_AddRef(*ppDecl);
return WINED3D_OK;
These patches violate
On 11/22/06, Andreas Mohr [EMAIL PROTECTED] wrote:
Hi,
On Wed, Nov 22, 2006 at 11:53:22AM +0100, Mirek wrote:
The aim is to prepare all apps below working under the Windows on Nvidia
GF 6XXX series, with at least 50% of speed in WinXP. There is not needed
sound after merging those patches in
On 22/11/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
I noticed that loadVertexData already disables stream sources that aren't
available in the current draws, while loadNumberedArrays doesn't. Do we need
unloadVertexData at all? Or are non-drawing operations or drawStridedSlow
affected by
On 22/11/06, Robert Shearman [EMAIL PROTECTED] wrote:
Markus Amsler wrote:
@@ -4704,7 +4704,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl
TRACE((%p) : ppDecl=%p\n, This, ppDecl);
*ppDecl = This-stateBlock-vertexDecl;
-if (NULL != *ppDecl)
Count me in for $150 too, as long as it's complete.
On 11/22/06, Chris Morgan [EMAIL PROTECTED] wrote:
On 11/22/06, Andreas Mohr [EMAIL PROTECTED] wrote:
Hi,
On Wed, Nov 22, 2006 at 11:53:22AM +0100, Mirek wrote:
The aim is to prepare all apps below working under the Windows on Nvidia
GF
Andreas Mohr wrote:
Would be nice to have many more people (e.g. those who don't feel like
programming things but still want to contribute somehow) offering
such dedication towards getting their personal goals in various
OSS projects reached.
GNOME has a 'bounties' webpage,
Mirek wrote:
Hi, I am not so good at programming in C, but I would like to be
perfectly working in Direct3D 9.0c in the Wine. I dont know how much
work is on so if someone cold told me how far is the complementation
of the Direct3D 9.0c support in the Wine?
Here is the offer for
From: Tomas Carnecky [EMAIL PROTECTED]
To: Andreas Mohr [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: Looking for programmator to complete Direct3D 9.0c with GLSL
in the Wine
Date: Wed, 22 Nov 2006 18:29:00 +
GNOME has a 'bounties' webpage, http://www.gnome.org/bounties/ - If
Hi!
Please, tell me what's wrong with the patch?
http://www.winehq.org/pipermail/wine-patches/2006-November/032984.html
-- Kirill K. Smirnov
H. Verbeet wrote:
On 22/11/06, Robert Shearman [EMAIL PROTECTED] wrote:
These patches violate COM rules. Is this for performance or other
reasons?
The plan seems to be to not use COM for wined3d anymore, mainly
because the layering of d3d87/8/9 on top of wined3d is causing some
problems
On 22/11/06, Markus Amsler [EMAIL PROTECTED] wrote:
It's about simplifying code, with the side effect of perhaps small
performance gains. It's also the first step to drop COM in wined3d, but
that's not my intention (it seems Stefan likes the idea).
Well, you can't half-remove COM. If you start
H. Verbeet wrote:
On 22/11/06, Markus Amsler [EMAIL PROTECTED] wrote:
It's about simplifying code, with the side effect of perhaps small
performance gains. It's also the first step to drop COM in wined3d, but
that's not my intention (it seems Stefan likes the idea).
Well, you can't half-remove
Hi,
Recently I got a problem that every app crashes on my system, like:
-- begin winedbg output --
[EMAIL PROTECTED]:~$ winedbg ~/bin/win32/mirc/mirc.exe
WineDbg starting on pid 0x12
First chance exception: page fault on read access to 0x in
32-bit code (0x).
Register dump:
Good point in some cases we can just let get proc address pipe the func ptr
directly back to the app..
But..
On Mac OSX -- the stack must be 16 byte aligned (for and lib/sys call) --
this means we need to thunk for the stack on Max OSX -- If Linux or other
plats have similar reqs then the
28 matches
Mail list logo
