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 thun
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:
CS
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-remov
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, 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
> proble
Hi!
Please, tell me what's wrong with the patch?
http://www.winehq.org/pipermail/wine-patches/2006-November/032984.html
-- Kirill K. Smirnov
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/ -
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 everyone:
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, http://ww
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 Nvi
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) IWineD3DVertexDeclaration_Ad
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 arra
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 patche
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 viola
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 d
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 do
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 t
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 threa
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 existenc
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 t
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 Ni
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?
p
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() ca
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
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 :
> 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
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 wined3d_fak
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 a
28 matches
Mail list logo