- Wine-Devel - list.winehq.org

Re: move palettes from GDI heap to system heap
by Michael Stefaniuc Feb. 5, 2003

Feb. 5, 2003

On Wed, Feb 05, 2003 at 06:30:21PM -0500, Warren_Baird(a)cimmetry.com wrote: > > > > ChangeLog: > > Allocate palette objects on the large heap instead of the GDI heap > to avoid GDI heap saturation. This is already in CVS. bye michael -- 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: Opengl Glide
by Kristoffer Ericson Feb. 5, 2003

Feb. 5, 2003

Hey, Guilty as charged, been working on this thing for quite some time now. just send me the www link and i will upload the logs. Any idea, why Tribes don't detect opengl? i'm not familiar with any other game that does this. Although i know that Tribes didn't support Opengl nativly but it added it with a patch later on. Best wishes >From: Lionel Ulmer <lionel.ulmer(a)free.fr> >To: Kristoffer Ericson <kristoffer_e1(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: Opengl Glide >Date: Wed, 5 Feb 2003 18:21:53 +0100 > >Out of curiosity : are you the guy who submitted the Tribes 1 bug on WineHQ >about input and stuff ? > >If not, could you raise a bug (or two, one for input the other for OpenGL) >so that we could go back and forth on these issues more easily than by mail >on the devel list ? > > > * As soon as any key is pressed, wine quits > > = Fix with native dinput.dll version dx4->dx6 > >For this I would need a --debugmsg +dinput,+seh trace of the problem. THe >debugger won't work due to the 'LL hooks' problem, but let's hope that it >will be enough. > > > * Opengl isn't detected and impossible to choose > > = Currently no fix, although it works to use glidewrappers. Don't know > > what Tribes uses to detect opengl. > >For this, a +relay,+opengl,+x11drv log would be needed. > > > My other question is this, if i want to use glide (got a voodoo3) how do >i > > enable and use this in wine? > > > > Do i do a ./configure --enable-glide or --with-glide ? > > And so on.. > >If should be used automagically and not need any configure stuff. > > Lionel > >-- > Lionel Ulmer - http://www.bbrox.org/ _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re: Code Duplication
by Brian Vincent (C) Feb. 5, 2003

Feb. 5, 2003

>During my work to clean up the Unicode -> ascii cross-calls I have >noticed some A:W pairs where both are implemented in essentially the >same way. Would it be sensible in these case to make the A function into >a call to the W one, to reduce code size, or would I be wasting my time. This was discussed back in Novemeber: http://www.winehq.com/news/?view=143#Avoiding%20ASCII/Unicode%20Function%20D uplication Follow the "Archive" link for the thread. If I remember correctly there was no right or wrong thing to do - it depended on the case. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

font metrics II
by Scott Jackson Feb. 5, 2003

Feb. 5, 2003

ok, here's a better question: since my Japanese fonts don't puke under X11 (but do under wine :-P ), is there any way I can get wine to ignore certain directories of fonts?? This would help b/c wine crashes on one of my Kappa fonts. Thanks! -- "De-fault! The two sweetest words in the English language." -- Homer Simpson Get Gaim for unix or win32 systems! gaim.sourceforge.net Scott "Action" Jackson - scott_j(a)ajackson.org

2 1

{G|S}etThreadContext question
by Rein Klazes Feb. 5, 2003

Feb. 5, 2003

hi, I am trying to add some support for the floating point unit to winedbg. I have one question to the experts. The debugger code gets/sets the CPU registers through a {G|S}etThreadContext() from the server, adding the flag CONTEXT_FLOATING_POINT should make sure to include the FP registers. This doesn't work because the server code clears the CONTEXT_FLOATING_POINT flag at some point (see attached patch). My patch is simply preventing this, but it may well be that the FP registers should be available at this point. So is this the correct fix? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 3

CVS Compile error.
by Patrik Båt Feb. 5, 2003

Feb. 5, 2003

Hello people out there! Im trying to compile the cvs source of WINE and gets error: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fno-keep-static-consts -D__int8=char -D__int16=short -D__int32=int "-D__int64=long long" -fPIC -D__WINE__ -fshort-wchar -D_REENTRANT -I/usr/X11R6/include -o dpnet_main.o dpnet_main.c cc1: Invalid option `-fshort-wchar' make[2]: *** [dpnet_main.o] Error 1 make[2]: Leaving directory `/root/winecvs/wine/dlls/dpnet' make[1]: *** [dpnet/libdpnet.so] Error 2 make[1]: Leaving directory `/root/winecvs/wine/dlls' make: *** [dlls] Error 2 Is it anyone ho have a clue? I updated the CVS source today, 2003-02-05 (YYYY-MM-DD). ./configure dosen't complaine... My system is: Linux 2.4.20, Debian 3.0 unstable. -- Patrik Båt <patrik(a)researchelectronics.se> Research Electronics AB

4 7

Re: CVS Compile error.
by Patrik Båt Feb. 5, 2003

Feb. 5, 2003

hello, testing som stuff here.... root(a)lightning:~/winecvs/wine# gcc -fshort-wchar test.c cc1: Invalid option `-fshort-wchar' root(a)lightning:~/winecvs/wine# with 2.54 and root(a)lightning:~/winecvs/wine# gcc -fshort-wchar test.c root(a)lightning:~/winecvs/wine# cat test.c #include <stdio.h> int main() { printf("hello!"); } with 3.0 -- Patrik Båt <patrik.bat(a)home.se>

1 0

Opengl Glide
by Kristoffer Ericson Feb. 5, 2003

Feb. 5, 2003

Greetings, I've been trying to get StarSiege Tribes 1 to work on wine, basicly this is what's currently wrong: * As soon as any key is pressed, wine quits = Fix with native dinput.dll version dx4->dx6 * Opengl isn't detected and impossible to choose = Currently no fix, although it works to use glidewrappers. Don't know what Tribes uses to detect opengl. The basic errors i'm getting in the terminal is. fixme:dinput:IDirectInputDevice2AImpl_EnumObjects (!stub) fixme:dsound:IDirectSoundImpl_SetCooperativeLevel err:dinput:SysMouseAImpl_Unacquire Unacquiring a not-acquired device !!! The first fixme, makes me hope that if that is fixed it might get Tribes to work using our own builtin dinput.dll My other question is this, if i want to use glide (got a voodoo3) how do i enable and use this in wine? Do i do a ./configure --enable-glide or --with-glide ? And so on.. I've compiled Mesa with glide support and installed the glidev3 package (using gentoo). Haven't been able to find any info on the homepage or mailing lists, and if needed i could compile a nfo file covering the subject once i understand it better. I would like to point out also that Tribes is working quite well in software mode and since late fall last year i've noticed that many problems has dissapeared. Btw, using daily cvs so got the latest patches. Best wishes Kristoffer _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

2 1

Re: Initialize listview item size.
by Dimitrie O. Paun Feb. 5, 2003

Feb. 5, 2003

On February 3, 2003 11:58 am, Duane Clark wrote: > This is a separate bug from the other listview patches. If an app sends > a LISTVIEW_Paint to a new listview before adding any items (which an app > was :-) the item size was not getting set, causing subsequent > LISTVIEW_Paint calls to clip the painting. > > Changelog: > Make sure item size is initialized when the first item is added. This is an optimization I've put in to avoid a lot of complex calculations while the listview is initially populated (typically before it's being painted). You are right, we have to detect the change nItemCount from 0 to 1, to do all those calculations. But since we don't actually need them until we paint, I'd like to defer them as much as possible. Moreover, with your patch, we don't catch the SetItemCount case. What about this patch instead: Index: dlls/comctl32/listview.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.338 diff -u -r1.338 listview.c --- dlls/comctl32/listview.c 24 Jan 2003 00:54:59 -0000 1.338 +++ dlls/comctl32/listview.c 5 Feb 2003 06:48:41 -0000 @@ -7850,7 +7850,7 @@ { TRACE("(hdc=%p)\n", hdc); - if (infoPtr->bFirstPaint) + if (infoPtr->bFirstPaint && infoPtr->nItemCount) { UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; -- Dimi.

2 1

Re: Code Duplication
by Rolf Kalbermatter Feb. 5, 2003

Feb. 5, 2003

Matthew Davison <m.davison(a)virgin.net> wrote: >During my work to clean up the Unicode -> ascii cross-calls I have >noticed some A:W pairs where both are implemented in essentially the >same way. Would it be sensible in these case to make the A function into >a call to the W one, to reduce code size, or would I be wasting my time. I have noticed the same, and looking through it I have for myself come to the conclusion that if the function is rather simple, such as only calling a few A/W specific WinAPIs there is no gain in trying to make the A function call the W function other than an additional possible overhead in execution. Just make sure both functions remain at the same position in the source so that a prospective developer who patches one of the functions can't miss the other one. I for myself handle the rule: If the 'A calls W function with Unicode translation' results in more lines of source code than the direct A implementation I won't spend time to try to convert them. If the function however is a little more complex there is always the issue of maintaining two different functions in parallel and then making the A function call the W function is the most sensible approach indeed. Rolf Kalbermatter

1 0