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

Is anyone monitoring Transgaming's changes to the LGPL files?

by Scott Ritchie

I don't know when it started, but Transgaming has been using LGPL chunks of Wine for quite some time. As they're required to, they've released the source for these files, along with whatever changes they've made. However, they're not required to tell us what they did, to send us patches, or to even let us know they've made a change. What this means is that it's possible, even likely, that Transgaming has improved the LGPL parts of Cedega in some important way that would be useful to Wine as well, without us having even known about it. The simplest thing to do is for someone to just track the code they release and diff it against our own stuff, and note if anything new and interesting (eg an implementation of a function) comes up. Then send in a patch if it seems like it could help us too. But, is anyone doing this? Thanks, Scott Ritchie

Jan. 25, 2007

Re: scroll window fix

by Peter Oberndorfer

On Thursday 25 January 2007 18:56, Aric Stewart wrote: > finds the case where the scrolling amount exceeds the window but still falls > within the clipping rect. This generates an additional update region > that needs > to be invalidated. > includes a test Hi, I can't argue about the correctness of the patch itself but it adds tabs and a few trailing spaces. Greetings Peter > --- > dlls/user32/painting.c | 21 +++++++++++++++++++++ > dlls/user32/tests/win.c | 9 +++++++++ > 2 files changed, 30 insertions(+), 0 deletions(-) >

Jan. 25, 2007

Re: Patch to make X11DRV_GetAsyncKeyState work for TacOps

by Martin Cracauer

Mike McCormack wrote on Thu, Jan 25, 2007 at 06:42:25PM +0900: > > Martin Cracauer wrote: > > >The game "TacOps" (a standalone 2D wargame, not to be mixed up with > >the Unreal mod "Tac Ops") uses home-grown scrollbars. They have > >autorepeat, that means holding the mouse button on the "down" or "up" > >icons will continue to scroll until you release the button. Without > >the appended patch Wine will never notice when you release the mouse > >button. That effectively means an application hang since you can > >never do anything else anymore, as the game continue to execute "down" > >autorepeat. > > You'll probably need Alexandre's comment on this, but it doesn't look > correct to me. > > Querying the X server for the key state on each call to GetAsyncKeyState > bypasses the input queue, and is likely to cause applications that poll > GetAsyncKeyState to slow down... I have seen in other parts of the code that a call like mine is only made no more often than 100msec. That will still cause a systemcall for getting the time, but it'll probably fix my application problem (at work right now, can't test) and at the same time make the code much lighter so that polling GetAsyncKeyState won't slow down. Does that sound better? Also keep in mind I only query the X11 server when the keycode is one of a selected few. Combined with a 100msec cap that should keep the extra load down. > This is likely to be a tricky problem to solve, as you need to run > Wine's X11 message loop, but Wine currently only does that when the > application waits for input. The application is just sitting in the GUI waiting for me to poke around. But it is one of those applications with permanent 100% CPU load, so it is clearly not doing some select() equivalent. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer(a)cons.org> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/

Jan. 25, 2007

Re: [kernel32][tests][locale] Add test for CompareStringA for non latin symbols

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: >> I'd suggest to test specific strings instead of auto-generated tables. >> Since microsoft apparently uses their own unicode tables that differ >> from unicode.org ones that's almost impossible to get the exactly same >> behaviour among Wine and Windows. >> > Unfortunately there are programs which are using this table of sorting > and no other. We can do nothing to fix the apps calling CompareStringA for binary data. The only way would be to patch unicode.org tables manually, but it's not acceptable as a general solution. Anyway you need to test the specific cases, and not add a blanket (all in one) case IMO. >>> + return CompareStringA(LOCALE_USER_DEFAULT,0,s1,1, s2,1) - 2; >>> +} >> >> You need to directly specify the locale id, otherwise the test won't pass >> on a system with different user default locale (like the Alexandre's >> one). >> > > In: > > + > + while(Locales[j].pcTable) > + { > + if(setlocale(LC_ALL,Locales[j].pcLocalName)!=NULL) > + { > + for(i=0;i<cSize;i++) > > > set another locale, isn't it? This doesn't magically change Wine internal locale used by CompareStringA. -- Dmitry.

Jan. 25, 2007

Re: Failing regression tests, how to solve?

by Alexandre Julliard

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > Maybe it's due to renaming of gdi32 directory, but how can i solve this? > Regression testing is really impossible this way :( Remove all traces of libgdi32.def in your tree and rebuild. -- Alexandre Julliard julliard(a)winehq.org

Jan. 25, 2007

Re: make crosstest broken (tmarshal)

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > What parameters do i need to pass to configure for this case. If i do > it like Paul Millar descripted it > > ../wine-git/configure --host=i586-mingw32msvc \ > -with-wine-tools=../wine-build That should work. Make sure you don't have a tmarshal.h in the source tree. -- Alexandre Julliard julliard(a)winehq.org

Jan. 25, 2007

Re: make crosstest broken (tmarshal)

by Paul Vriens

Stefan Leichter wrote: > Alexandre Julliard schrieb: >> Stefan Leichter <Stefan.Leichter(a)camline.com> writes: >> >>> The problem is related to the fact that i'm doing out of tree builds. >>> Therefore i have three directories: >>> 1. wine-git : the source tree >>> 2. wine-build : the normal build (unix) >>> 3. wine-mingw : the cross compile build >> >> If you are doing a cross-compile build then you don't need to use >> crosstest, a simple make will build the tests as PE binaries. "make >> crosstest" is meant for people who want to quickly build a PE test >> inside the normal tree, without the complexity of a separate build >> tree. >> > What parameters do i need to pass to configure for this case. If i do it > like Paul Millar descripted it > > ../wine-git/configure --host=i586-mingw32msvc \ > -with-wine-tools=../wine-build > > in http://www.winehq.org/pipermail/wine-devel/2006-December/053069.html > get get the same problem (no tmarshal.h) as posted in my first mail. > > -- > Thanks Stefan > > > > > Hi, I took Paul's example as well (partly). I have two trees: /wine/wine-git and /wine/wine-pe wine-git is configured with the standard ./configure. wine-pe with: ./configure --host=i386-mingw32 --with-wine-tools=../wine-git This works fine (for me) and also for the tmarshal.h: ../../../../wine-git/tools/widl/widl -I. -I. -I../../../include -I../../../include -h -H tmarshal.h tmarshal.idl Cheers, Paul.

Jan. 25, 2007

Failing regression tests, how to solve?

by Louis Lenders

Hi, regression testing back to for example wine-0.9.22 all fails for me with link errors: palette.o: In function `X11DRV_PALETTE_ToPhysical': /sda3/wine-git/dlls/winex11.drv/palette.c:828: undefined reference to `GDI_GetObjPtr' /sda3/wine-git/dlls/winex11.drv/palette.c:848: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:859: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:866: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:881: undefined reference to `GDI_ReleaseObj' /sda3/wine-git/dlls/winex11.drv/palette.c:898: undefined reference to `GDI_ReleaseObj' Maybe it's due to renaming of gdi32 directory, but how can i solve this? Regression testing is really impossible this way :(

Jan. 25, 2007

Re: make crosstest broken (tmarshal)

by Stefan Leichter

Alexandre Julliard schrieb: > Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > >> The problem is related to the fact that i'm doing out of tree builds. >> Therefore i have three directories: >> 1. wine-git : the source tree >> 2. wine-build : the normal build (unix) >> 3. wine-mingw : the cross compile build > > If you are doing a cross-compile build then you don't need to use > crosstest, a simple make will build the tests as PE binaries. "make > crosstest" is meant for people who want to quickly build a PE test > inside the normal tree, without the complexity of a separate build > tree. > What parameters do i need to pass to configure for this case. If i do it like Paul Millar descripted it ../wine-git/configure --host=i586-mingw32msvc \ -with-wine-tools=../wine-build in http://www.winehq.org/pipermail/wine-devel/2006-December/053069.html get get the same problem (no tmarshal.h) as posted in my first mail. -- Thanks Stefan

Jan. 25, 2007

Re: cabinet: Fix overrun of static array (Coverity)

by Alexandre Julliard

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > This patch is aimed at fixing Coverity CID-297. The existing code writes > 52 values to a 51-value array. The patch code only writes the first 51. > > Please let me know what is wrong with this patch. It may well be correct, but I think both the old and the new code are very confusing. Initializing this from a static constant would be a lot cleaner. -- Alexandre Julliard julliard(a)winehq.org

Jan. 25, 2007