January 2003 - Wine-Devel - list.winehq.org

Re: Bug #540: DLL Separation of user32 from x11drv (clipboard)

by Vincent Béron

Andrew John Hughes a écrit: > License: LGPL > > Changelog: > Removes calls to CLIPBOARD_IsPresent, CLIPBOARD_EmptyCache and CLIPBOARD_GetFormatName. > Something's missing... Vincent

Jan. 28, 2003

Re: [dx8 patch 12]: huge cleanup + split

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mardi 28 Janvier 2003 21:56, Andrew John Hughes a écrit : > On Sat, 25 Jan 2003 01:14:15 +0100 > > Raphaël Junqueira <fenix(a)club-internet.fr> wrote: <snip> > Including glext.h appears to break the DLL for me. NVidia's GL headers > (gl.h) already define some of the types specified in glext.h. I presume X > installs glext.h, but I've not had a conflict between the two headers > before. yukkkk, it's a known recurrent problem ;( currently i have a proto where i redefined all the types, protos, ... but it's not merged yet (it's a HAL arch draft) sorry, but your nvidia header don't seem to respect the "standard" ;( can you send me your nvidia gl.h header i'll try to play with #ifdef/#endif Raphael > In file included from d3d8_private.h:30, > from device.c:35: > /usr/local/include/GL/glext.h:3142: conflicting types for > `glCopyTexSubImage3DEXT' /usr/local/include/GL/gl.h:2486: previous > declaration of `glCopyTexSubImage3DEXT' /usr/local/include/GL/glext.h:3566: > conflicting types for `glColorSubTableEXT' /usr/local/include/GL/gl.h:2446: > previous declaration of `glColorSubTableEXT' > /usr/local/include/GL/glext.h:4372: conflicting types for > `glTbufferMask3DFX' /usr/local/include/GL/gl.h:2984: previous declaration > of `glTbufferMask3DFX' /usr/local/include/GL/glext.h:4406: conflicting > types for `glTextureColorMaskSGIS' /usr/local/include/GL/gl.h:3050: > previous declaration of `glTextureColorMaskSGIS' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+NvFrp7NA3AmQTU4RAhq0AJ993XKW2bTJMnbmeztOkJkQ4dGysQCeP4sM sUaIe8zEH9J0vxKwiBTvIkQ= =vZjr -----END PGP SIGNATURE-----

Jan. 28, 2003

Re: [dx8 patch 12]: huge cleanup + split

by Andrew John Hughes

On Sat, 25 Jan 2003 01:14:15 +0100 Raphaël Junqueira <fenix(a)club-internet.fr> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > it seems a big patch, but it's only simple cleanups/splits ;) > > it's the first and bigger patch for splitting d3d8 from the future d3d7/d3d8/d3d9 comon code > > Changelog: > - some needed cleanups for future dx9 and d3d common layer support: > - stateblocks to IDirect3DStateBlockImpl interface and moving into a new file (stateblock.c) > - shaders to IDirect3D*ShaderImpl interfaces > - splitting vshader and vshader declaration as in dx9 into 2 interfaces (for future common layer use) > - vshader declaration code to a new file (vsaderdeclaration.c) > - device calls to new interfaces (redirect stubs) > - simple texture fix for a little regression after last jason patches > - some caps code using the GL/glext.h defines (GL_VERSION_*) > > Todo: > - renaming IDirec3DDevice8Impl::StateBlock to IDirec3DDevice8Impl::startupStateBlock > - moving IDirec3DDevice8Impl d3d generic code to a "common layer" interface (maybe IDirec3DDeviceImpl) > - merging new DrawPrimitive prototype (using ddraw code) with current code > - splitting d3d8_private.h into 2 headers (d3d8 specific header, and common layer header) > - merging the hal base prototype > > Raphael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+MdbYp7NA3AmQTU4RAg3DAJ94zf6kzopk2WH95+Nvq/BcH26dogCdEhf2 > UASOhtqMDLoJocMODUtZZv8= > =5SNm > -----END PGP SIGNATURE----- > Including glext.h appears to break the DLL for me. NVidia's GL headers (gl.h) already define some of the types specified in glext.h. I presume X installs glext.h, but I've not had a conflict between the two headers before. In file included from d3d8_private.h:30, from device.c:35: /usr/local/include/GL/glext.h:3142: conflicting types for `glCopyTexSubImage3DEXT' /usr/local/include/GL/gl.h:2486: previous declaration of `glCopyTexSubImage3DEXT' /usr/local/include/GL/glext.h:3566: conflicting types for `glColorSubTableEXT' /usr/local/include/GL/gl.h:2446: previous declaration of `glColorSubTableEXT' /usr/local/include/GL/glext.h:4372: conflicting types for `glTbufferMask3DFX' /usr/local/include/GL/gl.h:2984: previous declaration of `glTbufferMask3DFX' /usr/local/include/GL/glext.h:4406: conflicting types for `glTextureColorMaskSGIS' /usr/local/include/GL/gl.h:3050: previous declaration of `glTextureColorMaskSGIS' -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html "Windows is the one true OS. MS invented the GUI. MS invented the 32 bit OS. MS is open and standard. MS loves you. We have always been at war with Oceania."

Jan. 28, 2003

Re: Guess who's back, back again... :)

by Sylvain Petreolle

Wb ! --- "Dimitrie O. Paun" <dpaun(a)rogers.com> a écrit : > Hi folks, > > My ski vacation was a blast, good snow, good skiing, good people... > > You guys have been busy this past week judging by the number of > messages I had to go through :) > > It's good to be back! > > -- > Dimi. > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 28, 2003

Re: PATCH: glibc 2.3.x and errno

by Dan Kegel

Sylvain Petreolle wrote: >>It occurs to me that implementing Wine threads on top of pthreads >>would probably get rid of a few of the problems keeping us from >>running >>Wine under Valgrind. Short of getting the Stanford Checker guys >>interested in the Wine source tree, I can't think of an cooler >>way to look for stupid memory bugs in Wine... > > Can Valgrind run GL programs (except NVidia binaries-linked ;)) ? Yes. See http://developer.kde.org/~sewardj/ -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 28, 2003

Re: remote app problem: menus go away at wrong time

by Dan Kegel

Zsolt Rizsanyi wrote: > I use LTSP to run a diskless Linux workstation. I'm running two Windows > programs on top of it regularly (two dictionaries). And they work exactly the > same as they work on the main machine. I have also tried some other programs > too, and never seen any difference beetween the local and the remote machine > (wrt this). > > So it works pretty good. I dont know for what the above cygwin and double ssh > is needed. I dont need it :) Think about it: the computer I was using was running Windows XP. The only free X server for Windows I know of is the Cygwin one. ssh was needed to get to the remote computer to start the X program. I'm not saying everyone is going to use this configuration -- in fact, the test was more for humor value than anything else -- but there's no reason it shouldn't work. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 28, 2003

Re: mkdir, copy, etc.

by Sylvain Petreolle

--- Jon Bright <jon(a)siliconcircus.com> a écrit : > Hi, > > I'm trying to build OpenSSL using Borland Builder 5 within wine. > Installation of Builder has gone fine, ActiveState Perl went on after > a > bit of fiddling, but I've now hit a small problem. The makefile for > OpenSSL attempts to run mkdir, copy, etc. - this results in Borland's > make attempting to run (after trying to find copy.exe/com/bat/cmd), > the > command interpreter found in COMSPEC. But wcmd is only a unix > command - > there is no windows\system\wcmd.exe its installed into windows\system if you use the latest version. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 28, 2003

Re: PATCH: glibc 2.3.x and errno

by Sylvain Petreolle

Can Valgrind run GL programs (except NVidia binaries-linked ;)) ? > > It occurs to me that implementing Wine threads on top of pthreads > would probably get rid of a few of the problems keeping us from > running > Wine under Valgrind. Short of getting the Stanford Checker guys > interested in the Wine source tree, I can't think of an cooler > way to look for stupid memory bugs in Wine... > - Dan ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 28, 2003

Re: mkdir, copy, etc.

by davep

On Tuesday 28 Jan 2003 11:07, Jon Bright wrote: > Hi, > > I'm trying to build OpenSSL using Borland Builder 5 within wine. > Installation of Builder has gone fine, ActiveState Perl went on after a > bit of fiddling, but I've now hit a small problem. The makefile for > OpenSSL attempts to run mkdir, copy, etc. - this results in Borland's > make attempting to run (after trying to find copy.exe/com/bat/cmd), the > command interpreter found in COMSPEC. But wcmd is only a unix command - > there is no windows\system\wcmd.exe > > Is there already a workaround for this, or can someone point me in the > right direction to look at fixing it? It's been a while since I tried, but it used to be possible to compile wcmd as a Win32 console application. Modulo a small bootstrap issue that could solve your problem. Dave

Jan. 28, 2003

Re: remote app problem: menus go away at wrong time

by Alberto Massari

At 23.40 27/01/2003 -0800, Dan Kegel wrote: >[...] >First issue: you can't use the menus with the mouse! Sure, they'll >pop up, but when you move the mouse down to one of the menu items, >the menu goes away. It decides the user really wanted to highlight >the toolbar, or something. You have the same behavior when using eXceed from a Windows machine to talk with a Linux box. The mouse coordinates are properly converted to detect toolbar hits, and even to highlight the entry in the menu that is beneath the cursor, but when you click, you get a completely different point. Alberto

Jan. 28, 2003