- Wine-Devel - list.winehq.org

Re: [dx52] fix AddDirtyRect
by Raphaël Junqueira June 6, 2003

June 6, 2003

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi all, Hi, > This patch fixes a problem that appeared in Mafia. how mafia works ? ;))) > Before this function > crashed when pDirtyRect was null. According to MSDN D3DERR_INVALIDCALL > should be returned in case of problems. Well, this is not really the good way to fix the problem (as the surface isn't dirtified) IDirect3DSurface8Impl_AddDirtyRect is an internal function (as seen in d3d8_provate.h declaration) so i cannot see where you have found the msdn docs ;) I think you wanted to fix a crash who happened in some IDirect3D*TextureImpl_AddDirty* call no ? if yes, can you try this patch instead ? > Regards, > Roderick Colenbrander Thanks, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+4NBdp7NA3AmQTU4RAkkxAJ9oHG+cSN5Px+mga6BQrrb/wytc9QCfRpc2 QMvmNo9HL43iicyKWEfp1bY= =H46H -----END PGP SIGNATURE-----

2 1

Re: [GDI] GetObject patch (for null buffer functionality)
by Michael Stefaniuc June 6, 2003

June 6, 2003

On Fri, Jun 06, 2003 at 10:39:43AM -0500, Kelly Leahy wrote: > I just found a problem with this patch. Let me send another one... Please send the patch as unified diff (diff -u). See http://www.winehq.com/Docs/wine-devel/patches.shtml for details. bye michael > I'll have it this afternoon. It shouldn't be a big deal (it won't be worse than the code was before) but let me fix it anyway. > > Kelly > ----- Original Message ----- > From: Kelly Leahy > To: wine-patches(a)winehq.com > Sent: Friday, June 06, 2003 10:22 AM > Subject: [GDI] GetObject patch (for null buffer functionality) > > > Kelly Leahy > kellyleahy(a)swbell.net > > Changelog- > - fixes problems with GDI GetObject function not working properly when a NULL buffer or 0 count is used. > - note - no attempt was made to fix this problem under 16-bit windows functions (GetObject16). > > Description: > The GDI GetObject function should return the number of bytes required for the buffer, when a NULL buffer pointer is passed to the function. However, the implementation in CVS did not provide this functionality. I've added two function pointers to the gdi_obj_funcs structure that allow for this functionality. The pointers are pGetObjectSizeA and pGetObjectSizeW, and for all object types except FONT, they are implemented by the same function. On FONT, the structure differs depending on whether the LOGFONTA or LOGFONTW structure is required (depends on which function is called - GetObjectA or GetObjectW). For bitmaps, the function must determine which structure is most appropriate (BITMAP or DIBSECTION) and return the size of that structure - it does so now. > > Patch is attached. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Re: RE: GL Header question
by fenix＠club-internet.fr June 6, 2003

June 6, 2003

>Theyre proprietary and only have GL 1.1 & 1.2 version. no they calims to be openGL1.3 compatible (and the define most of the pre-openGL1.4 values) But if they are proprietary, we can't use it Raphael

2 1

dlls/d3d8/device.c fails to compile
by Gerald Pfeifer June 6, 2003

June 6, 2003

After the recent wave of commits, I'm getting a build failure for the following line in dlls/d3d8/device.c: IDirect3DBaseTexture8* cont = NULL; The failure looks as follows device.c:1989: syntax error before `*' device.c:1991: `hr' undeclared (first use in this function) device.c:1991: (Each undeclared identifier is reported only once device.c:1991: for each function it appears in.) device.c:1991: `cont' undeclared (first use in this function) gmake[2]: *** [device.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/d3d8' gmake[1]: *** [d3d8] Error 2 gmake[1]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls' gmake: *** [dlls] Error 2 which indicates that IDirect3DBaseTexture8 is not a known type at that point. That's using XFree86-4.3.0 and Mesa-3.4.2 (on FreeBSD 4.8). Gerald PS: I'll happily test any patches to fix this. -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

2 1

Re: Re: Re: Submits galore
by fenix＠club-internet.fr June 6, 2003

June 6, 2003

>> PS: As jason have some compilation problems too as it use a specific gl.h >> with a generic glext.h, i'm thinking about not using anymore the gl/glext >> headers definitions (i'm too bored to fixes each mismatch headers >> declaration) Hi All, >Well, I would say that we use the standard gl.h file (otherwise >it's too messy) but completely remove the dependency on glext.h. well, the problem is that gl.h defines ugly things too. as i have reports from users using mesa headers 3.4 (openGL 1.2 only declared but ugly pre 1.3 support) while using Mesa5.0 (very easy to do: install a XFree4.0 and after install only mesa5) >I plan to change all _EXT and _ARB stuff in the D3D7 code by >_WINE #defines (defined from the GL extension specs) and to never >use at all the function pointer typedef and use my own. i think you'll have many breakage :) >Basically, my baseline would be GL 1.2 and all the rest would be >redefined. As you want, But for me, I think building with GL1.4 (last ans most complete) headers and detecting/activing caps on runtime it's a more proper solution (no more #ifdef/#define in code, only in d3dcore_gl.h definitions). > Lionel Regards, Raphael

2 1

Re: dlls/d3d8/device.c fails to compile
by fenix＠club-internet.fr June 6, 2003

June 6, 2003

Hi, Stefan Leichter have already sent a patch (wine-patches archive) to fix it. Thanks to him. But now i want to understand why my gcc3 in c89 mode compil this code without any problem :( Regards, Raphael ----Message d'origine---- >Date: Fri, 6 Jun 2003 11:08:01 +0200 (CEST) >De: Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> >A: wine-devel(a)winehq.com >Copie à: Raphael Junqueira <fenix(a)club-internet.fr> >Sujet: dlls/d3d8/device.c fails to compile > >After the recent wave of commits, I'm getting a build failure for the >following line in dlls/d3d8/device.c: > > IDirect3DBaseTexture8* cont = NULL; > >The failure looks as follows > > device.c:1989: syntax error before `*' > device.c:1991: `hr' undeclared (first use in this function) > device.c:1991: (Each undeclared identifier is reported only once > device.c:1991: for each function it appears in.) > device.c:1991: `cont' undeclared (first use in this function) > gmake[2]: *** [device.o] Error 1 > gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/d3d8' > gmake[1]: *** [d3d8] Error 2 > gmake[1]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls' > gmake: *** [dlls] Error 2 > >which indicates that IDirect3DBaseTexture8 is not a known type at that >point. > >That's using XFree86-4.3.0 and Mesa-3.4.2 (on FreeBSD 4.8). > >Gerald > >PS: I'll happily test any patches to fix this. >-- >Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/ > >

1 0

[FYI] Vacation
by Dimitrie O. Paun June 6, 2003

June 6, 2003

Folks, I'm leaving for vacation today for a month, I'll be back July 7th. I'll probably read my email from time to time, but I will not be very active on the lists. All the best, and I'll see you soon! (maybe Wineconf? :)) -- Dimi. P.S. Don't release 0.9 without me! :)))

2 2

Re: Re: GL Header question
by fenix＠club-internet.fr June 6, 2003

June 6, 2003

>> well, better ;) >> my goal is to detect and active all capabilities on runtime and never bother >> again about declared/defined caps from gl headers (gl,glext,glx). >> For this we need an header where all defines and functions pointers are >> declared (as seen in d3dcore_gl.h) > >As said in another mail, I agree for glext.h but not for GL.h. Or >if we go that way, why not ship a 'valid' set of gl.h / glext.h / >glxext.h that are known to work instead of redoing all the >constants ? No, i not want to redefine all constants, i'll only define needed defines and prototypes for compilation. For GL.h see my last mail >For example, we know that Raphael has a configuration where his >tree builds... Well, let him ship his .hs in Wine :-) lol why not, but i think sending the three (or two) headers in wine tree can be replaced by a "minimalist" header (only define what we need) for compilation > Lionel Raphael

1 0

Re: RE: GL Header question
by fenix＠club-internet.fr June 6, 2003

June 6, 2003

Re, >>As said in another mail, I agree for glext.h but not for GL.h. Or if we go >>that way, why not ship a 'valid' set of gl.h / glext.h / glxext.h that are >>known to work instead of redoing all the constants ? > >Curiously, why glext and not gl? I'd be more for shipping all 3 >if required or merging them all into one wine header. Could we >not just be causing ourselves the same problem further down the >line otherwise? I not approve to merge all gl headers into one HUGE header. I only want to have its the minimalist header where we only define what we need. >>For example, we know that Raphael has a configuration where his >>tree builds... Well, let him ship his .hs in Wine :-) > >Perhaps they are copyright nvidia? :-) Yes, but i think they redistribuable. (they are here: http://cvs1.nvidia.com/inc/GL/) Else we can always use last mesa headers. >Jason Raphael

2 1

Fixme:s in simcity 4 native install (DDRAW.dll.DdEntry, commctrl:InitCommo)
by Arne Falk June 6, 2003

June 6, 2003

I am trying to install Simcity 4 natively in Linux with just wine setup.exe, everything else default. I get some Fixme:s that I hope someone is interested in. [root(a)foo cdrom]# wine setup.exe err:font:ReadFontDir Can't open directory "/mnt/windows/windows/Fonts" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/drakfont/ttf " FIXME:pthread_cond_init ... ... (these 3 lines are repeated many times) ... fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x8000 err:dc:DCE_FreeWindowDCE [0x3003f] GetDC() without ReleaseDC()! FIXME:pthread_cond_init mcop warning: user defined signal handler found for SIG_PIPE, overriding err:wave:ARTS_WaveInit arts_init() failed (-1) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403d2cf8)->(00000000,00000008 ) err:module:import_dll No implementation for NTDLL.dll.IoUnregisterDeviceInterfac e imported from C:\windows\system\cfgmgr32.dll, setting to 0xdeadbeef fixme:file:DeviceIoControl ignored dwIoControlCode=80000072 err:module:import_dll No implementation for DDRAW.dll.DdEntry18 imported from C: \windows\system\d3d8.dll, setting to 0xdeadbeef err:module:import_dll No implementation for DDRAW.dll.DdEntry19 imported from C: \windows\system\d3d8.dll, setting to 0xdeadbeef ... (repeated many times for other DdEntryxx) ... fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403d4258)->(00000000,00000008 ) err:module:import_dll No implementation for NTDLL.dll.IoUnregisterDeviceInterfac e imported from C:\windows\system\cfgmgr32.dll, setting to 0xdeadbeef fixme:file:DeviceIoControl ignored dwIoControlCode=80000072 _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

2 1