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

Fixing wrong prototypes in a header

by Juan Lang

Some of the function prototypes in wintrust.h have the wrong calling convention. The trouble is, PSDK gets them wrong too. So calling the functions, as declared in the PSDK header, results in a crash in Windows. Casting them to function pointers with the correct calling convention succeeds. Should I leave the prototypes incorrect in wintrust.h to match the PSDK, or should I fix them to make them more convenient for me to use? Thanks, --Juan

Aug. 15, 2007

[wininet/tests] Replace import of ws2_32 by wsock32 to please win95

by Paul Vriens

Hi, Currently we import ws2_32 for our wininet tests. ws2_32 is however not available on win95 and thus presents users of winetest with a pop-up. A crash of the tests I could live with but a pop-up gets in the way of automatic testing (if ever implemented again). I could do LoadLibrary/GetProcAddress to overcome that but a much easier solution seems to be to import wsock32 instead of ws2_32. Comments? Cheers, Paul.

Aug. 15, 2007

Re: A script for automatic regression testing

by martin pilka

Hi Mikolaj, nice work! I saw that you successfully ran cxtest.sh script on your machine and submitted results. Currently, we are in process of setuping cxtest.sh (tests Wine make test, Picasa, WinZip, WordViewer, ExcelViewer, PptViewer) and 3dMark2000 tests nightly on our testing machines. Once we have this, we will need functionally equivalent to script you wrote, which would help us to find defective patch for regression cases like this: http://www.cxtest.org/product-evaluation?id_product=3&id_failure=170&m_from… Would you be interested in joining forces, working together and integrate your script into CxTest backend? Martin

Aug. 15, 2007

Re: [PATCH] Fix Bug in DeadZone calculation

by Kuba Ober

> >> Artur Szymiec wrote: > >>> Here is attached patch > >>> for joystick_linuxinput.c where bug in dead zone > >>> calculation make joystick unusable. After correction > >>> tested in two games and works properly. > >> Thanks for spotting the problem. Unfortunately your patch has few > >> problems too. I'll sending a better patch. > > What kind of problems do you mean ? > You calculating center wrong: > > + ret = (props->lMax-props->lMin)/2; > > This won't work for min=1000 max=2000. But it does. Maybe you meant if min/max were switched? In such case ret = (props->lMax-props->lMin)/2; if (props->lMax < props->lMin) ret = -ret; Cheers, Kuba

Aug. 15, 2007

Re: [PATCH] Fix Bug in DeadZone calculation

by Vitaliy Margolen

Artur Szymiec wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Vitaliy Margolen napisał(a): >> Artur Szymiec wrote: >>> Here is attached patch >>> for joystick_linuxinput.c where bug in dead zone >>> calculation make joystick unusable. After correction >>> tested in two games and works properly. >>> >>> Best Regards >>> Artur Szymiec >>> >> Thanks for spotting the problem. Unfortunately your patch has few >> problems too. I'll sending a better patch. >> >> Vitaliy. >> > Thanks for reviewing the patch. > Could you please explain to me what's wrong with this patch. > What kind of problems do you mean ? > You calculating center wrong: > + ret = (props->lMax-props->lMin)/2; This won't work for min=1000 max=2000. Vitaliy.

Aug. 15, 2007

Problems with focus losing on virtual desktops

by Patrick Leamon

There seems to be a bug for this now: http://bugs.winehq.org/show_bug.cgi?id=9320 ____________________________________________________________________________________ Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. http://au.docs.yahoo.com/mail/unlimitedstorage.html

Aug. 15, 2007

Re: AMD64 package broken on Ubuntu Gutsy

by Scott Ritchie

On Wed, 2007-08-15 at 12:31 +0200, Maarten Lankhorst wrote: > Scott Ritchie schreef: > > The Wine package in Ubuntu Gutsy is currently failing to build on the > > AMD 64 arch, and I'm not sure why. I don't have a gutsy 64 system to > > play around with at the moment, but you can see the package error log > > here: > > > > http://launchpadlibrarian.net/8598218/buildlog_ubuntu-gutsy-amd64.wine_0.9.… > > > > I suspect one of the 32 bit libraries that we have to link by hand got > > renamed or upgraded, but I can't figure out which one from the log > > there. > > > > Thanks, > > Scott Ritchie > > > Actually, looking at the warnings and commands you passed > --enable-win64, that means a 64 bit wine will be built that can't run 32 > bit executables. Just remove that flag and everything should be fine > > Cheers, > Maarten Hmm...someone was changing my package then to not be 32 bit. No wonder it broke. Thanks, Scott Ritchie

Aug. 15, 2007

Re: AMD64 package broken on Ubuntu Gutsy

by Maarten Lankhorst

Scott Ritchie schreef: > The Wine package in Ubuntu Gutsy is currently failing to build on the > AMD 64 arch, and I'm not sure why. I don't have a gutsy 64 system to > play around with at the moment, but you can see the package error log > here: > > http://launchpadlibrarian.net/8598218/buildlog_ubuntu-gutsy-amd64.wine_0.9.… > > I suspect one of the 32 bit libraries that we have to link by hand got > renamed or upgraded, but I can't figure out which one from the log > there. > > Thanks, > Scott Ritchie > Actually, looking at the warnings and commands you passed --enable-win64, that means a 64 bit wine will be built that can't run 32 bit executables. Just remove that flag and everything should be fine Cheers, Maarten

Aug. 15, 2007

AMD64 package broken on Ubuntu Gutsy

by Scott Ritchie

The Wine package in Ubuntu Gutsy is currently failing to build on the AMD 64 arch, and I'm not sure why. I don't have a gutsy 64 system to play around with at the moment, but you can see the package error log here: http://launchpadlibrarian.net/8598218/buildlog_ubuntu-gutsy-amd64.wine_0.9.… I suspect one of the 32 bit libraries that we have to link by hand got renamed or upgraded, but I can't figure out which one from the log there. Thanks, Scott Ritchie

Aug. 15, 2007

WINEDEBUG output issues

by Paul Vriens

Hi, I was trying to read a '+all,+relay,-syslevel,-gdi,-font' trace but several lines show something like: 000d:Cget_window_property000d:Call0x000d:, atom=000d:Call usePropertySheetInfo000d000000d:Call user32.CharNextA(0 {000d:Call user32.CharNextA(0040a04d "les\\Nmap") ret=0040551c The above is output from the same thread. I also have: 0009:trace:heap:RtlAllocateHeap (0x110000,00000002,0000014000d:Call user32.CharNe0009:trace:dc:GetDCState (0x474): retu000d:Ret user32.CharNextA() retval=004093c6 ret=0040551c Which mixes threads. Debug traces can already be hard to read but this is even more confusing. Any idea what the cause is (or better, the solution)? Cheers, Paul.

Aug. 15, 2007