Re: dlls: add wpcap
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 and wpcap.dll is a third-party library used for packet
capturing. This does not need to be implemented in Wine if that's the
case, but I've added comments below for future reference.
diff -uNr wine.orig/configure.ac wine/configure.ac
--- wine.orig/configure.ac 2006-11-21 16:28:25.0 +0800
+++ wine/configure.ac 2006-11-21 16:30:51.0 +0800
@@ -1669,6 +1669,7 @@
dlls/ntdsapi/Makefile
dlls/objsel/Makefile
dlls/odbc32/Makefile
+dlls/wpcap/Makefile
dlls/odbccp32/Makefile
dlls/ole32/Makefile
dlls/ole32/tests/Makefile
diff -uNr wine.orig/dlls/Makefile.in wine/dlls/Makefile.in
--- wine.orig/dlls/Makefile.in 2006-11-21 16:27:59.0 +0800
+++ wine/dlls/Makefile.in 2006-11-21 16:30:51.0 +0800
@@ -125,6 +125,7 @@
ntdsapi \
objsel \
odbc32 \
+ wpcap \
odbccp32 \
ole32 \
oleacc \
@@ -559,6 +560,7 @@
ntdll/libntdll.$(IMPLIBEXT) \
ntdsapi/libntdsapi.$(IMPLIBEXT) \
odbc32/libodbc32.$(IMPLIBEXT) \
+ wpcap/libwpcap.$(IMPLIBEXT) \
odbccp32/libodbccp32.$(IMPLIBEXT) \
ole32/libole32.$(IMPLIBEXT) \
oleacc/liboleacc.$(IMPLIBEXT) \
@@ -820,6 +822,9 @@
odbc32/libodbc32.$(IMPLIBEXT): odbc32/odbc32.spec $(WINEBUILD)
@cd odbc32 $(MAKE) libodbc32.$(IMPLIBEXT)
+wpcap/libwpcap.$(IMPLIBEXT): wpcap/wpcap.spec $(WINEBUILD)
+ @cd wpcap $(MAKE) libwpcap.$(IMPLIBEXT)
+
odbccp32/libodbccp32.$(IMPLIBEXT): odbccp32/odbccp32.spec $(WINEBUILD)
@cd odbccp32 $(MAKE) libodbccp32.$(IMPLIBEXT)
diff -uNr wine.orig/dlls/wpcap/Makefile.in wine/dlls/wpcap/Makefile.in
--- wine.orig/dlls/wpcap/Makefile.in1970-01-01 08:00:00.0 +0800
+++ wine/dlls/wpcap/Makefile.in 2006-11-21 16:30:51.0 +0800
@@ -0,0 +1,16 @@
+TOPSRCDIR = @top_srcdir@
+TOPOBJDIR = ../..
+SRCDIR= @srcdir@
+VPATH = @srcdir@
+MODULE= wpcap.dll
+IMPORTLIB = libwpcap.$(IMPLIBEXT)
+IMPORTS = kernel32 ntdll
+EXTRAINCL = @X_CFLAGS@
+EXTRALIBS = @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@ @OPENGL_LIBS@ -lpcap
+
I'm not a Makefile pro by any means, but why do you need all thse
EXTRALIBS? Also, you're going to have to add a configure check for
-lpcap.
+C_SRCS = \
+ wpcap.c
+
[EMAIL PROTECTED]@
+
+### Dependencies:
diff -uNr wine.orig/dlls/wpcap/wpcap.c wine/dlls/wpcap/wpcap.c
--- wine.orig/dlls/wpcap/wpcap.c1970-01-01 08:00:00.0 +0800
+++ wine/dlls/wpcap/wpcap.c 2006-11-21 16:30:51.0 +0800
@@ -0,0 +1,73 @@
+#ifdef WIN32
+#undef WIN32
+#endif
+#include pcap.h
You need to add the GPL license to the top of every source file.
Check out any other source file in the code base for examples.
+void wine_pcap_close(pcap_t * a)
+{
+ pcap_close(a);
+}
+
Assuming the name of the API is pcap_close, you'll have to define it like this:
void WINAPI pcap_close(pcap_t *a)
WINAPI is needed, but the wine_ prefix is not.
+pcap_t * wine_pcap_open_live(const char * a, int b, int c , int d , char * e )
+{
+ return pcap_open_live(a,b,c,d,e);
+}
+
+int wine_pcap_findalldevs(pcap_if_t ** a, char * b)
+{
+ return pcap_findalldevs(a,b);
+}
+
+void wine_pcap_freealldevs(pcap_if_t * a)
+{
+ pcap_freealldevs(a);
+}
+
+int wine_pcap_compile(pcap_t * a, struct bpf_program * b, char * c,
int d, bpf_u_int32 e )
+{
+ return pcap_compile(a,b,c,d,e);
+}
+
+int wine_pcap_setfilter(pcap_t * a, struct bpf_program * b)
+{
+ return pcap_setfilter(a,b);
+}
+
+int wine_pcap_datalink(pcap_t * a)
+{
+ return pcap_datalink(a);
+}
+
+const u_char* wine_pcap_next(pcap_t * a, struct pcap_pkthdr * b)
+{
+ return pcap_next(a,b);
+}
+
+int wine_pcap_setbuff(pcap_t * p, int dim)
+{
+ //return pcap_setbuff(p ,dim);
+ return 0;
+#if 0
+#ifdef HAVE_REMOTE
+if (p-rmt_clientside)
+{
+/* Currently, this is a bug: the capture buffer
cannot be set with remote capture */
+return 0;
+}
+#endif /* HAVE_REMOTE */
+
+if (p-adapter==NULL)
+{
+snprintf(p-errbuf, PCAP_ERRBUF_SIZE, The kernel
buffer size cannot be set while reading from a file);
+return -1;
+}
+
+if(PacketSetBuff(p-adapter,dim)==FALSE)
+{
+snprintf(p-errbuf, PCAP_ERRBUF_SIZE, driver error:
not enough memory to allocate the kernel buffer);
+return -1;
+}
+return 0;
+#endif
+}
+
+
diff -uNr wine.orig/dlls/wpcap/wpcap.spec wine/dlls/wpcap/wpcap.spec
--- wine.orig/dlls/wpcap/wpcap.spec 1970-01-01 08:00:00.0 +0800
+++ wine/dlls/wpcap/wpcap.spec 2006-11-21 16:30:51.0 +0800
@@ -0,0 +1,9 @@
+@ stdcall
Re: [5/6] wined3d: Make CreateFakeGLContext thread safe.
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_fake_gl_context_available==FALSE create enter lock create wined3d_fake_gl_context_available=TRUE create leave lock release TRACE_(d3d_caps)(context not available\n); release return Though this is not realy a race condition, the trace doesn't realy tell the whole truth in this sequence of events, either. I think it's easier to see that the original code has correct locking (compared to your suggestion) and as this part of the code is not realy time critical, I prefer to leave it that way. Jan PS: Please try to honor Mail-Followup-To .
Re: wined3d: Don't refcount in getter functions.
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
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound
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 :-) pgpzH8QC8CRLO.pgp Description: PGP signature
Re: dlls: add wpcap
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 pcap library (see www.tcpdump.org), so naming the functions pcap_?? is not possible. tom
Re: dlls: add wpcap
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 pcap_close() which is a function implemented in the pcap library (see www.tcpdump.org), so naming the functions pcap_?? is not possible. Yea, saw that later :) -- James Hawkins
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound
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? pgpJ2I6LzDwSq.pgp Description: PGP signature
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound
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 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 :-) attach4
Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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 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 dollars for this work. 3DMark 2003 3DMark 2005 3DMark 2006 CoD 2 NFS MW NFS Carbon ES IV Oblivion Please, contact me or send this to another person you would think could do it. Mirek Slugen Czech Republic
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound
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 existence of their functions ALL the time -- this is braindead and can be fixed with something similar to what we use for ogl -- the big func table -- and only update on context change -- maybe even cache per context function tables... 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???)) As it is (on this list) it should be correct -- barring oddities between deprecated ALUT functions... - 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:25:10 +0100 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? attach4
Re: kernel32: (locale) Restore C locale for LC_NUMERIC (was: Re: oleaut32: use setlocale() around sprintfW to force use of period as decimal separator)
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. However, I think there is no big problem on going through a string in order to convert a floating-point number into a DECIMAL, since otherwise, we would need to implement our own bit-splicer for floating-point numbers. As long as the starting locale for sprintfW() is known to be the LC_NUMERIC=C, all other parsing should work as before the MacOS patch. Therefore I propose the attached patch. This patch simply sets setlocale(LC_NUMERIC, C) at the end of LOCALE_Init() in dlls/kernel32/locale.c in order to guarantee that sprintfW will always use periods as decimal separators. I put this in for now, but oleaut32 should really be fixed, we can't force the whole process to format number in English just because oleaut32 is broken. It doesn't matter too much for Wine itself, but any Unix library that we load should be able to behave properly according to the locale that the user has selected. -- Alexandre Julliard [EMAIL PROTECTED]
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenALand DirectSound
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 Linux function pointers directly to the apps? Wasn't there some .so loading in the wine library loader some time ago? pgpcHIbFkXPzF.pgp Description: PGP signature
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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 dollars for this work. WOW. Now that's a remarkable amount of personal involvement. 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. Thanks, and let's hope someone knowledgeable will follow up on this offer, Andreas Mohr
Question about unloadVertexData
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 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 arrays? Background is that I'm atm working on using dirtification to manage stream sources. So far the state management is progressing nicely, what is missing atm are Shaders, re-enabling register combiners and fixing regressions which slipped in(hl2 and bf1942). Then optimizations :-) Stefan pgpbFXPjcxMzK.pgp Description: PGP signature
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
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 COM rules. Is this for performance or other reasons? -- Rob Shearman
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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 cvs main head. I offer 1 000 Euro or 1 200 dollars for this work. WOW. Now that's a remarkable amount of personal involvement. 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. Thanks, and let's hope someone knowledgeable will follow up on this offer, Andreas Mohr I'll pitch in 150 USD to this bounty. Chris
Re: Question about unloadVertexData
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 arrays? Well, the issue is when you switch between fixed function and shader based drawing. Eg, if an array from a previous fixed function draw primitive call is still active while drawing with a shader, you can potentially access the fixed function array beyond its bounds. That was the actual issue that prompted me to write the patch, and it turned out to also fix the 3DMark03 VBO performance regression. Another issue which you might run into with you state management work is that at least on nVidia hardware the fixed function and shader arrays are aliases for eachother. Background is that I'm atm working on using dirtification to manage stream sources. So far the state management is progressing nicely, what is missing atm are Shaders, re-enabling register combiners and fixing regressions which slipped in(hl2 and bf1942). Then optimizations :-) Something that occured to me yesterday after we talked on IRC is that we should probably use glPushClientAttrib / glPopClientAttrib to do the disabling after we're done drawing.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
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_AddRef(*ppDecl); return WINED3D_OK; 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 with reference counts. Those could probably be solved by using eg aggregation, but I think the general feeling is that COM only makes things harder in wined3d.
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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 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 dollars for this work. WOW. Now that's a remarkable amount of personal involvement. 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. Thanks, and let's hope someone knowledgeable will follow up on this offer, Andreas Mohr I'll pitch in 150 USD to this bounty. Chris
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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://www.gnome.org/bounties/ - If we start with these 'bounties', wouldn't it be nice to have such a page too? tom
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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: 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 dollars for this work. 3DMark 2003 3DMark 2005 3DMark 2006 CoD 2 NFS MW NFS Carbon ES IV Oblivion Please, contact me or send this to another person you would think could do it. Mirek Slugen Czech Republic There are some companies that are specialized into these kind of collective payements. I haven't used any so I can't comment about the quality of their services. Some links... http://www.rentacoder.com/RentACoder/default.asp http://fundable.org/ I am sure there are more... .bill
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
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 we start with these 'bounties', wouldn't it be nice to have such a page too? tom A pledges page would be good. Are we going to have a link to contribute to this through paypal? I'd be willing to pay a bounty for Copy protection or punkbuster support.
Re: [Try2] winhelp: add preliminary *.cnt file support (parser) - what's wrong?
Hi! Please, tell me what's wrong with the patch? http://www.winehq.org/pipermail/wine-patches/2006-November/032984.html -- Kirill K. Smirnov
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
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 with reference counts. Those could probably be solved by using eg aggregation, but I think the general feeling is that COM only makes things harder in wined3d. 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). Wined3d refcounting is not causing refcount problems in d3dx, they are completly different. It just makes things easier.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
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 removing refcounts like this you have to follow it all the way through, imo.
Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
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 COM. If you start removing refcounts like this you have to follow it all the way through, imo. I'm not half removing COM (at most 3% :-) ). lpVtble, IUnknown, IID_*, ... is still in place. I just simplified some refcount behaviour in wined3d, which happens to make wined3d less dependandt on the refcount COM feature. Which in turn makes it easier to remove COM. I dont' dare even trying to remove COM. That would be far over my skills.
wine crashes on every win32 application (null ptr access early); winedbg adventures
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:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP: ESP:0034eb18 EBP:0034ec3c EFLAGS:00210216( - 00 -RIAP1) EAX: EBX: ECX: EDX:00c8 ESI:7c165cd0 EDI: Stack dump: 0x0034eb18: 7dcd7ffc 7c165cd0 7c16a430 7c16a430 0x0034eb28: 7c165cd0 7c167564 0034ec3c 0x0034eb38: 7deaf7d4 7c165cd0 005c 0x0034eb48: 7dcd778f 7c165cd0 7dcd7700 0x0034eb58: 0001 7dcba235 7c165cd0 7c165cd0 0x0034eb68: 7c165cd0 7c066498 7c0f23c0 7d8d Backtrace: =1 0x (0x0034ec3c) 2 0x0040 (0x0002) 3 0x (0x) 0x: addb%al,0x0(%eax) Wine-dbg -- end of winedbg -- I tried to remove wine configs, then recompile it from git, still the same. As a separate issue while trying to debug, I find winedbg not acting according to the man page (either that or I'm a dork). Would like to try to digest the stack frames: -- begin winedbg output -- Wine-dbgl * 7dcd7ffc syntax error Wine-dbglist * 7dcd7ffc syntax error Wine-dbglist * 0x7dcd7ffc syntax error Wine-dbgwatch * 7dcd7ffc Watchpoint 1 at 0x0007 syntax error Wine-dbg -- end winedbg output -- So the watch * addr is working (kinda) properly, but list * doesn't. Am I missing something? Thanks
Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:OpenALand DirectSound
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 thunking is required. Personally I would rather have the layer as it gives us control on how windows talks with the system. - 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 12:38:46 +0100 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 Linux function pointers directly to the apps? Wasn't there some .so loading in the wine library loader some time ago? attach4
