- Wine-Devel - list.winehq.org

Re: Accept -g3 stabs info (sketchy?)
by Eric Pouech Sept. 29, 2002

Sept. 29, 2002

> + case 'k': /* 'const' modifier */ > + case 'B': /* 'volatile' modifier */ > + /* just kinda ignore the modifier, I guess -gmt */ > + if (DEBUG_PTS_ReadTypedef(ptd, NULL, &ref_dt) == -1) return -1; > + new_dt = DEBUG_NewDataType(DEBUG_GetType(ref_dt), NULL); > + /* I don't get this.. but I figure this is kind of like "r" > + so I cut and pasted from there ... -gmt */ > + assert(!*DEBUG_FileSubNr2StabEnum(filenr1, subnr1)); > + *DEBUG_FileSubNr2StabEnum(filenr1, subnr1) = new_dt; > break; > case '(': > ptd->ptr--; this should rather be: + break; + case 'k': /* 'const' modifier */ + case 'B': /* 'volatile' modifier */ + /* just kinda ignore the modifier, I guess -gmt */ + if (DEBUG_PTS_ReadTypedef(ptd, NULL, &new_dt) == -1) return -1; patch is untested anyway (gcc 2.95 doesn't emit those, even in -g3 mode) however, it's strange that your gdb like debuggers crash in -gstabs2 mode IMO, we should keep (as of today) wine in -gstabs2 mode and not jump to level 3 A+

2 2

Call for feeback
by Thomas Wickline Sept. 29, 2002

Sept. 29, 2002

Hello , When I started the ToDo's I was unsure about what section to place some Tasks under so I just made... 1) Tools: 2) Instructions: 3) Aspect or Component: And placed items under those three sections and ask for feedback about where they belong. I have moved alot of the Tasks from my original list to there proper place. This is the remaing list .. If it looks alright can someone just say everything looks fine ? If something is out of place and you know where it goes can you * please * let me know where it goes. I dont feel comfortable making changes that im not totally sure about . I just want the page to have up to date and ACCURATE information on it ... Should there be a compile/build section ?? Tom --- Remaing list Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Add DWARF2 support * Speed up PDB support * Create replacement of browser component (Internet Explorer/I

1 0

Unable to compile current CVS
by Ann and Jason Edmeades Sept. 29, 2002

Sept. 29, 2002

No, we should be able to compile withiout mesa if we did before my patch. Unfortunately I dont know how to do this (I did warn alongside my patch) - Is there any chance you could work out how dlls/ddraw handles this issue so we can do the same. I suspect for non-gl enabled machines (until we go via a HAL) we should hava a d3d8.dll which just returns an error on the Direct3DCreate8 call. Jason

1 0

ToDo's
by Thomas Wickline Sept. 29, 2002

Sept. 29, 2002

Hello, Here is the changes to ( National Language Support ) Does it look alright with everyone ? If not let me know and ill patch it again . Everything else is the same I removed BiDi from Aspect or Component: as well. Tom ---- Wine ToDo's as of 9/29/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * Make sure ASCII functions call the Unicode one and not the other way around. * BiDi support * Add support for Hebrew and Arabic * Add support for more keyboard layouts to x11drv * Figure out what should be done for better support of Chinese, Korean, Japanese -- snip

1 0

Re: wineoss patch
by Eric Pouech Sept. 29, 2002

Sept. 29, 2002

Ove Kaaven a écrit : > > I can imagine Eric has a better patch for the following problem: > OSS/Commercial does not allow an open device to continue operation after a > SNDCTL_DSP_RESET, the device must be reopened (which is what their API > docs recommend). The following patch is what we have in WineX to get > around the issue, but it will only compile on ReWind and Wine if the > #define FULL_DUPLEX is enabled. But perhaps it's good enough if Eric > doesn't have a better one. And I have some fullduplex patches that I can > only submit after this issue is resolved. I think the best way is to store device parameters in all cases (full duplex or not) and then make use of them (transform the reset in close/open pair) moreover, full duplex infra has been around for a while, and didn't generate much complains... so I think we can remove now the support for the non FULLDUPLEX part finally, wine now as a notion of OSSDEVICE (shared by wavein and waveout) which could make some function defs a bit simpler I'll try to whip something out from Ove's first patch A+

1 0

Re: Implement {G|S}etWindowLongPtr
by Eric Pouech Sept. 29, 2002

Sept. 29, 2002

György 'Nog' Jeney a écrit : > > Apply this patch and observe nearly the whole wine recompile :) > > ChangLog: > * include/winuser.h > * win/win.c > Implement {G|S}etWindowLongPtr I don't want to see a whole wine recompilation every day, so I think those defs #define SetWindowLong WINELIB_NAME_AW(SetWindowLong) +LONG_PTR WINAPI SetWindowLongA(HWND,INT,LONG_PTR); +LONG_PTR WINAPI SetWindowLongW(HWND,INT,LONG_PTR); +#define SetWindowLongPtr WINELIB_NAME_AW(SetWindowLongPtr) should be instead #define SetWindowLong WINELIB_NAME_AW(SetWindowLong) +LONG_PTR WINAPI SetWindowLongPtrA(HWND,INT,LONG_PTR); +LONG_PTR WINAPI SetWindowLongPtrW(HWND,INT,LONG_PTR); +#define SetWindowLongPtr WINELIB_NAME_AW(SetWindowLongPtr) A+

1 0

Exception while trying to install winace 2.2
by György 'Nog' Jeney Sept. 29, 2002

Sept. 29, 2002

While trying to get the winace 2.2 installer to run on wine, I got the following exception without any messages on the console: First chance exception: page fault on read access to 0x23c94fed in 32-bit code (0x23c94fed). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:23c94fed ESP:40682e52 EBP:00400000 EFLAGS:00010646( R- 00 DI Z- -P1 ) EAX:00000000 EBX:40682e66 ECX:0000038b EDX:00420654 ESI:00000001 EDI:0044efb5 Stack dump: 0x40682e52 (_end+0x32cc32): 004209e2 40682e98 00420658 00000000 0x40682e62 (_end+0x32cc42): 00000000 00463047 0042066b 40682f44 0x40682e72 (_end+0x32cc52): 00463000 401111c0 00000001 40682f38 0x40682e82 (_end+0x32cc62): 40682e96 400fd024 00463042 00000600 0x40682e92 (_end+0x32cc72): 00463000 2f440246 c81a4068 66b12fc3 0x40682ea2 (_end+0x32cc82): c19d6f8a 25b92f81 51634d58 33c04011 0x40682eb2 (_end+0x32cc92): 0011: sel=008f base=401133c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x23c94fed (_end+0x1bc38885) (ebp=00400000) 1 0x00000002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) 0x23c94fed (_end+0x1bc38885): *** Invalid address 0x23c94fed (_end+0x1bc38885) -- no code -- It seemd to me that the stack frame(s?) got corrupted so I debugged further. It seems that the app throws an exception and catches it later on. I set a breakpoint on EXC_CallHandler where the backtrace still looked fine. Just before wine calls the exception handler, it pushes edx and then edi onto the stack, then the handler gets called: call *%edx. This puts excecution into 0x420658 which calls 0x4206ac. The assembly code at 0x4206ac looks like this: 0x004206ac (wace22.exe.+0x1f6ac in C:\wace22.exe): xorl %eax,%eax 0x004206ae (wace22.exe.+0x1f6ae in C:\wace22.exe): popl %esi 0x004206af (wace22.exe.+0x1f6af in C:\wace22.exe): movl %fs:0x0(%eax),%ebx 0x004206b2 (wace22.exe.+0x1f6b2 in C:\wace22.exe): movl 0x0(%ebx),%ebx 0x004206b4 (wace22.exe.+0x1f6b4 in C:\wace22.exe): leal 0xffffffd6(%ebx),%esp 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe): popl %ebp This last pop is what makes the backtrace weird, before this the backtrace looks like: =>0 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe) (ebp=40570938) 1 0x400c84c0 (EXC_RtlRaiseException+0x10c(rec=0x405709dc, context=0x40570a34) [exception.c:214] in libntdll.dll.so) (ebp=405709c0) 2 0x400d26e9 (do_segv+0x1a5(context=0x40570d1c, trap_code=0x400d2b98, cr2=0x40570a50, err_code=0x1) [signal_i386.c:798] in libntdll.dll.so) (ebp=40570a2c) 3 0x400d2b4c (segv_handler+0x3c(__signal=0x2b, __context=0x2b) [[signal_i386.c:986] in libntdll.dll.so) (ebp=40570d28) 4 0x0000008f (ebp=00000000) But after it, it looks like this: =>0 0x004206c1 (wace22.exe.+0x1f6c1 in C:\wace22.exe) (ebp=00400000) 1 0x00000002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) Is this normal? If I just continue from this point then the first exception will be thrown but quite a lot of functions get called between here and that exception. The exception handler never does return. Any one have any ideas as to what might go wrong here? nog.

1 0

Unable to compile current CVS
by Guy L. Albertelli Sept. 29, 2002

Sept. 29, 2002

It seems that the D3D8 code depends heavily on both GL/gl.h and GL/glx.h being present. My system RH 6.1 does not have those header files. Is GL a requirement for developers now?? Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>> Bathed in his currents of liquid helium, self-contained, immobile, vastly well informed by every mechanical sense: Shalmaneser. Every now and again there passes through his circuts a pulse which carries the cybernetic equivalent of the phrase, "Christ, what an imagination I've got. " - Stand on Zanzibar by John Brunner

1 0

patch to MZ_Exec() PE executables
by Chris Morgan Sept. 28, 2002

Sept. 28, 2002

Guess this got lost when I mailed it from my web mail account... Look reasonable? dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Add PE support to MZ_Exec().

2 1

Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527)
by Uwe Bonnes Sept. 28, 2002

Sept. 28, 2002

Hallo, the Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527) in wine/dlls/ddraw/mesa_private.h unconditional inclused GL/gl.h and GL/glx.h. On my Suse V8.0 system ( with the mesa package installed and the mesa-devel package not installed) this leads to: make[2]: Wechsel in das Verzeichnis Verzeichnis »/home/bon/tmp/wine/compile/wine-realclean/wine/dlls/ddraw« gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTR ANT -I/usr/X11R6/include -o dsurface/main.o dsurface/main.c In file included from dsurface/main.c:27: mesa_private.h:32: GL/gl.h: Datei oder Verzeichnis nicht gefunden mesa_private.h:33: GL/glx.h: Datei oder Verzeichnis nicht gefunden make[2]: *** [dsurface/main.o] Fehler 1 Probably it's a bad idea to only install mesa and not mesa-devel, but I think wine should cope with this situation or at least warn the user about that. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0