February 2005 - Wine-Devel - list.winehq.org

Re: x11drv regression?

by Lionel Ulmer

On Tue, Feb 01, 2005 at 10:05:52AM +0000, Oliver Stieber wrote: > I need to create a opengl context against the window, > is that still possible? I think you need to check the patch Alexandre comitted yesterday (http://www.winehq.org/hypermail/wine-cvs/2005/01/0724.html) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Feb. 1, 2005

Re: [AppDB] bug on links

by Paul van Schayck

Hey, On Mon, 31 Jan 2005 23:01:22 +0100, Raphael <fenix(a)club-internet.fr> wrote: > try http://appdb.winehq.org/appview.php?appId=443&versionId=627 > > select the www.darkageofcamelot.com link .... bug :) Far from a bug, that's how hyperlinks work. The people entering URL should use http://www.domain.com instead of www.domain.com. We can enforce that tough with some regex. I'll add that. But it won't fix this, that needs to be fixed by the app maintainer. Paul

Feb. 1, 2005

Re: NPTL and Wine threads

by Luke Kenneth Casson Leighton

On Mon, Jan 31, 2005 at 08:28:53PM -0800, Dan Kegel wrote: > Luke wrote: > > it's come to my attention that NPTL cannot cope with jumping out > > of a cancellation handler. > > Tough noogies, as it were. See it'll bother me later but for now it doesn't :) > > there is some code in FreeDCE which expects to be able to jump out > > of a cancellation handler > > Then FreeDCE should be fixed to be POSIX-compliant, I think. > Or is there something subtle going on here? the behaviour of LinuxThreads is different from NPTL. therefore, given that this cancellation thing matters for dce applications (the runtime relies on it being possible) i thought you might wish to be aware of this subtle difference in case Wine MSRPC or other applications also rely on it. that's all - nothing more. l.

Feb. 1, 2005

Re: x11drv regression?

by Oliver Stieber

--- Mike McCormack <mike(a)codeweavers.com> wrote: > > Oliver Stieber wrote: > > > I've just synced with CVS and the following > code > > and I can no longer get an x11 window ID using > > There is no longer any X11 window ID associated with > child windows. > Wine has been re-architected so that only top level > windows have an > associated X11 window. > > Mike > I need to create a opengl context against the window, is that still possible? I expect known I can drill down through all the X11 windows until I find the correct one, but that's a bit outside the box. > ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Feb. 1, 2005

Re: x11drv regression?

by Mike McCormack

Oliver Stieber wrote: > I've just synced with CVS and the following code > and I can no longer get an x11 window ID using There is no longer any X11 window ID associated with child windows. Wine has been re-architected so that only top level windows have an associated X11 window. Mike

Feb. 1, 2005

x11drv regression?

by Oliver Stieber

Hi, I've just synced with CVS and the following code and I can no longer get an x11 window ID using (Window)GetPropA(HWND,"__wine_x11_client_window" ); I've had a look at X11DRV and there have been a few changes reciently, should I be using something else? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Feb. 1, 2005

my trouble

by pyd

hello all: I download one Game http://www.qf.com.cn/software/qfweiqi.exe run in WINE but It show me like this. ------------------------------------------------ pyd(a)linux:~/.wine/drive_c/qf> wine GoStoneClient.exe fixme:ole:CoRegisterMessageFilter stub wine: Unhandled exception (thread 002c), starting debugger... WineDbg starting on pid 0x2b In 32 bit mode. 0x404719c4 DebugBreak+0x4 in kernel32: popl %ebp Wine-dbg> ------------------------------------------------ I have allready install win98 dll store in wine.my system is SuSe8.2 pyd.

Feb. 1, 2005

Update: olepicture.c compile failure : `UserData' / `DGifOpen'

by Rizwan Kassim

An update to my previous posting: Steps: 1) Install debian-stable-latest. 2) get Wine directly off the CVS server (version used Jan 31 2005 22:52p PST) 3) configure, make depend, make. The following results in dlls/oleaut32: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o olepicture.o olepicture.c In file included from /usr/include/jpeglib.h:24, from olepicture.c:85: /usr/include/jconfig.h:12: warning: `HAVE_STDLIB_H' redefined ../../include/config.h:541: warning: this is the location of the previous definition olepicture.c:898: `DGifOpen' undeclared here (not in a function) olepicture.c:898: warning: type defaults to `int' in declaration of `pDGifOpen' olepicture.c: In function `_gif_inputfunc': olepicture.c:930: structure has no member named `UserData' olepicture.c: In function `OLEPictureImpl_Load': olepicture.c:1040: called object is not a function olepicture.c:1070: structure has no member named `Function' olepicture.c:1018: warning: `gif' might be used uninitialized in this function make[2]: *** [olepicture.o] Error 1 jconfig.h just seems like a "bad citizen" - #undef HAVE_STDLIB_H before it redefines it works fine. Of greater concern is the issues with DGifOpen. It seems that configure approves of vesrion 3.0.0 of libungif.so / gif_lib.h, but compile fails using 3.0.0. DGifOpen gif_lib.h 4.0.0 compiles correctly (even without updating libungif.so, but afaik thats pretty poor practice) The gif_lib.h that configure approves of is labeled version 3.0 by Eric S Raymond. (from gif_lib.h - 4.0.0 : GifFileType *DGifOpen(void *userPtr, InputFunc readFunc); /* new one Interestingly, it seems that configure DOES show the failure during the test compile: config.log: configure:15570: test -s conftest configure:15573: $? = 0 configure:15590: result: libjpeg.so.62 configure:15599: checking for -lungif soname configure:15629: gcc -o conftest -g -O2 conftest.c -lungif >&5 /tmp/ccdg49tg.o: In function `main': /home/rizwank/wine/conftest.c:155: undefined reference to `DGifOpen' collect2: ld returned 1 exit status configure:15635: $? = 1 configure: failed program was: <snip confdefs.h and a few more lines> configure:15738: result: libgif.so ======= Now, looking through config.log, I noticed a number of various errors that didn't lead to compile errors in wine, but this one did. (its easy to quelch the error, copy a new lib_gif.h to dlls/oleaut32. I'd assume that new libraries would be smart; while oleauto32/tests doesn't report any errors with using 4.0 of lib_gif.h and 3.0 of libungif.so, it doesn't seem to actually test any of the olepicture calls just yet). So, whats the next step? Should it be a critical error for configure? Should configure report the incorrect gif_lib.h (and old libungif)? I'm new enough to OSS projects that I'm not sure if I should : a) attempt to patch configure to report the error and stop the configure process b) patch olepicture.c to stop using DGifOpen c) submit gif_lib.h to the tree in dlls/oleaut32 This has been (partially) reported as Bug 1730 and 2437. Any input would be totally appreciated! Rizwan (outputs of configure, make depend, make and make test, as well as config.log and config.status are available at http://www.geekymedia.com/twiki/bin/view.cgi/WineDev/LugWine ) -- Thank you, Rizwan Kassim Octal is the way God meant programmers to count - the thumbs are parity bits.

Feb. 1, 2005

Re: [d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem

by Oliver Stieber

> > Maybe. I got pirates partially to work. The intro > at loading plays, > after the Atari logo, it then crashes: > > fixme:d3d:IDirect3DDevice9Impl_CreateDepthStencilSurface > (0x403ac0f0) : stub > fixme:d3d:IDirect3DDevice9Impl_CreateDepthStencilSurface > (0x403ac0f0) : stub > wine: Unhandled exception (thread 0009), starting > debugger... > WineDbg starting on pid 0x8 > Unhandled exception: page fault on read access to > 0x00000001 in 32-bit > code (0x4a1a5b30). > In 32 bit mode. > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0000 > EIP:4a1a5b30 ESP:4068fc40 EBP:4068fd1c > EFLAGS:00010202( - 00 - -RI1) > EAX:4042c688 EBX:4a1cc32c ECX:403abe40 EDX:00000001 > ESI:403ec588 EDI:00000000 > Stack dump: > 0x4068fc40: 00000001 00007eac 00000002 00000000 > 0x4068fc50: 7a7d2ba0 0000000c 00000002 00000000 > 0x4068fc60: 00000000 00000000 00000000 00000000 > 0x4068fc70: 00000000 00000000 00000000 00000000 > 0x4068fc80: 00000000 00000000 00000000 00000000 > 0x4068fc90: 00000000 00000000 00000000 00000000 > Backtrace: > =>1 0x4a1a5b30 drawPrimitive+0x230(iface=0x403ec588, > PrimitiveType=0x6, NumPrimitives=0x2, > StartVertexIndex=0x0, > StartIdx=0xffffffff, idxSize=0x0, idxData=0x0, > minIndex=0x0) > [drawprim.c:1582] in wined3d (0x4068fd1c) > 2 0x4a19dc57 > IWineD3DDeviceImpl_DrawPrimitive+0x47(iface=0x403ec588, > PrimitiveType=0x6, StartVertex=0x0, > PrimitiveCount=0x2) > [/home/jesse/wine-printf/dlls/wined3d/device.c:3504] > in wined3d > (0x4068fd50) > 3 0x4a0244ee > IDirect3DDevice9Impl_DrawPrimitive+0x1e(iface=0x403ac0f0, > PrimitiveType=0x6, StartVertex=0x0, > PrimitiveCount=0x2) > [/home/jesse/wine-printf/dlls/d3d9/device.c:579] in > d3d9 (0x4068fd68) > 4 0x005c1ac0 in pirates! (+0x1c1ac0) (0x00000000) > 0x4a1a5b30 drawPrimitive+0x230 [drawprim.c:1582] in > wined3d: movl > 0x0(%edx),%eax > Unable to open file drawprim.c > Wine-dbg> > > Since I had to hack wine to get it to run to this > degree, here are the > patches I tried out: > > d3d9_device.diff > printf.diff > printf_compare_warn.diff > wined3d_vb_begin.diff > > By Oliver: > wined3d_guids_01_os.diff > wined3d_guids__newfiles_01_os.diff (slight fix to > get this to compile) > > I'm not sure if I need an older patch of his. > > I also hacked dlls/wined3d/surface.c > IWineD3DSurfaceImpl_UnlockRect() here: > > break; > case D3DFMT_A8R8G8B8: > case D3DFMT_X8R8G8B8: > { > > The game calls the function with D3DFMT_X8R8G8B8. I > think it could > work like case D3DFMT_A8R8G8B8 since it's padded the > same =) -- just > without alpha -- and seemed to thus far. It allowed > me to see the > intro. > > Jesse > I tried that and it seems to be fine, but the intro's crash a lot more now :( In wined3d_private.h search for anything that allocates and array HIGHEST_RENDER_STATE in size and change it to HIGHEST_RENDER_STATE + 1 since were addressing 1 based not 0 based. Do the same with HIGHEST_TRANSFORMSTATE, HIGHEST_TEXTURE_STATE and HIGHEST_SAMPLER_STATE. I've done a tone of debugging and to be honest the first patch was a lot buggier than I thought, but then I had been doing a 18hrs 7days a week on it, so it's not supprsing. Anyhow, I've more or less put in the other 80% of the effort and a lot more apps are running without any crash bugs things there's still a few issues that need to sorted out before patches can go into CVS, mainly where to put GUIDS. I'm putting a new big patch up against head as soon as I've done a cvs update, ./configure etc... and some regression. The big patch won't be CVS worthy but it will have things like non-power-2 textures if anyone wants to do some testing since I've only tested against an ATI 9600. > ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Feb. 1, 2005

regression in

by tony_lambregts＠telusplanet.net

According to bug 2659 http://bugs.winehq.org/show_bug.cgi?id=2659 This patch http://www.winehq.org/hypermail/wine-cvs/2005/01/0232.html causes a regression in Shareaza. http://www.shareaza.com/?id=download -- Tony lambregts

Feb. 1, 2005