wine-devel

wine-devel@winehq.org

3 participants
84481 discussions

RFC: 'test' bugzilla keyword
by Francois Gouget 24 Aug '02

24 Aug '02

Hi, I think that conformance test failures should generally be easier to analyze and fix than general application failures. Thus I think we may get a community of contributers interested in specifically tracking these issues to fix them, and that some in this community may not otherwise be interested in tackling the complex diagnosis of general application failures. In other words, if we make it easy to track conformance test issues in Bugzilla, we may get new contributers (sure I realize it's not a magic bullet either). Thus I propose to add a 'test' keyword to make it easy to find such issues in bugzilla for people specifically interested in conformance tests. This keyword would apply to reports concerning a conformance/regression test that: * fails to pass on Windows * fails to pass on Wine * fails to pass on specific architectures (e.g. FreeBSD, Solaris, etc.) Note that this would be different from the regression keyword which only applies to reports describing something that used to work and no longer works. Obviously, if a conformance test used to pass in Wine but no longer does, then both keywords would apply to the report. So for instance, if one finds that a conformance test passes on Win98 but not on NT4, then one would create a bug report with the keyword 'test' and OS 'Windows NT'. If a conformance test fails to pass on Solaris systems, then the report would have the 'test' keyword and the OS would be 'Solaris'. Comments / Objections / Better names for the keyword? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

broken input
by sauer＠studcs.uni-sb.de 23 Aug '02

23 Aug '02

i succeded to run the game "Wizardry 8" with original wine. Now the input is broken, almost every event is handled twice (e.g. i hit a and 2 a's appear, clicking with mouse results in doubleclick) and it does not seem to be a problem with dlls/x11drv/[event.c|keyboard.c|mouse.c]. Also the windows/input.c sends all requests only once! to see this insert in windows/input.c line 113 (the queue_raw_hardwar...): if (message == 0x0100) printf("request KeyDown\n"); if (message == 0x0101) printf("request KeyUp\n"); here, 0x0100 is WM_KEYDOWN, 0x0101 is WM_KEYUP now, i've added to scheduler/client.c line 745 (the wine_server_call): if (req->u.req.send_message_request.msg == 0x0100) \\ printf("sending KeyDown\n"); if (req->u.req.send_message_request.msg == 0x0101) \\ printf("sending KeyUp\n"); In most cases this results in two send_requests per action (mouse also) and sometimes (nondeterministic) i've got only one WM_KEYDOWN => only one keypress (at the end of the mail is some output). I'm stuck now at this point and do not know how to debug furhtermore. It's obvious that wine_server_call gets called twice (once from windows/input.c and the second time from ?!?). Can someone help me and tell me how to continue. What do I have to do now to find the bug ? mIc P.S.: Yes, beeing addicted to computer games make's me debug wine!!!!! Output: request KeyDown sending KeyDown sending KeyDown request KeyUp sending KeyUp sending KeyUp request KeyDown sending KeyDown sending KeyDown request KeyUp sending KeyUp request KeyDown sending KeyDown sending KeyDown request KeyUp sending KeyUp sending KeyUp request KeyDown sending KeyDown request KeyUp sending KeyUp sending KeyUp request KeyDown sending KeyDown sending KeyDown request KeyUp sending KeyUp sending KeyUp

1 1

freereport initialization crash - cups problem?
by Grzegorz Prokopski 23 Aug '02

23 Aug '02

Hi! I finally narowed down the problem with crashing freereport app while it is initializing freereport dll. I got a workaround, but real fix should be trivial for someone who knows a bit more about wineps driver. App was crashing int wineps/init.c:PSDRV_UpdateDevCaps at: physDev->horzSize = (physDev->horzRes * 25.4) / physDev->logPixelsX because physDev->logPixelsX == 0 In wineps/init.c:PSDRV_CreateDC I see: physDev->logPixelsX = physDev->pi->ppd->DefaultResolution; physDev->logPixelsY = physDev->pi->ppd->DefaultResolution; in turn ppd->DefaultResolution is filled in wineps/ppd.c:PSDRV_ParsePPD where it scans for "*DefaultResolution" or "*DefaultJCLResolution" in ppd file. For me it was /etc/cups/ppd/lp.ppd (HP DeskJet 694C, Foomatic + cdj550) Unfortunatelly there was NO "DefaultResolution" information in it. For now, because the app has more problems with running (now it hangs) I just added: "DefaultResolution: 20" to this file. But long term solution would be IMO to check in either ppd.c or CreateDC if adequatly ppd->DefaultResolution or physDev->LogPixels* are not 0. If they are... hm... no idea - maybe we can somehow calculate some values for that? Surely it shouldn't stay as it is now. Dividing by zero in wine's code is Bad Thing(tm). Anyone would propose "the right fix" for this? Regards Grzegorz B. Prokopski

2 2

Bug in VirtualAlloc
by Robert Lunnon 23 Aug '02

23 Aug '02

An Interesting one, on my system wine has been broken for a little while failing with a bad heap message I have tracked it down to one solitary line in Virtual.c:(115) and here it is : #define ADDRESS_SPACE_LIMIT ((void *)0xc0000000) /* top of the user address space */ when making an anonymous mmap Solaris returns (gdb) disp ptr 11: ptr = (void *) 0xdf620000 (ptr gets copied to base later) Which is somewhat larger than 0xc0000000 and a comparison at around line 1010 if ((base <= (char *)granularity_mask) || (base + size < base) || (base + size > (char *)ADDRESS_SPACE_LIMIT)) { SetLastError( ERROR_INVALID_PARAMETER ); return NULL; } Fails Q. Why is there a hard limit on this ? Is this a Windows thing or a Linux thing. My only way to work around it would be to "strongly Suggest* mapping addresses to the OS which would be very messy. Suggestions (Constructive ones) warmly received Bob

3 4

10072002 version - printing bug
by leanne 23 Aug '02

23 Aug '02

Dear all, I found the 10072002 version of WINE that the layout of printout got problems. some letters overlap. Thanks. Leanne

2 3

quick question about windows.h and then a long one if anyone is interested.
by Steven Edwards 23 Aug '02

23 Aug '02

I've been playing around with building the wine dlls with the headers in winsup for cygwin/mingw. I've included the mingw headers after the local directory but before inclusion of the wine headers. I can build some of the more simple like twain and mapi doing this but I must also include windows.h in the sources. I noticed in wines windows.h it says it should not be included internaly so I assume this is also wrong for Mingw/MS_VC. Simple Question: Is my assumption right? Long Question: If so then does anyone have any recommendations on testing 3rd party headers under mingw. Thanks Steven __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com

2 2

Re: spec file format changed?
by Michael Cardenas 23 Aug '02

23 Aug '02

Hello again. I found this cvs entry: http://cvs.winehq.com/patch.py?id=1020902756411430620894865 Describing how imports have to be moved to Makefiles and out of spec files. and by looking at parser.c in winebuild, I see that when alexandre removed the need for "type win32" entries, he made it a required change, so now winebuild terminates if it finds a "type win32" line in a spec file. michael -- michael cardenas | lead software engineer | lindows.com | hyperpoem.net "Be the change you want to see in the world" - Mahatma Gandhi

1 0

Bad icon drawing under native comctl32
by Bill Medland 22 Aug '02

22 Aug '02

Any ideas? I'll try and get together a reasoanbly sized test case. When our application runs using the native comctl32 the icons in the SysListview32 are displayed with random black pixels in the background. The pattern varies between icons and between runs of the application. Bill

1 0

wine systray and KDE tray
by Medland, Bill 22 Aug '02

22 Aug '02

I just noticed the other day that the icon that used to appear nicely in the KDE's tray has gone and now the WINE systray comes up (but without the icon in it). Is this a deliberate change? Bill

2 1

spec file format changed?
by Michael Cardenas 22 Aug '02

22 Aug '02

Hello all. I'm trying to compile our wine tree with the latest release of wine, and it seems that some of the codeweavers' helper applications don't want to compile. Specifically, when tring to do a "make" in the utils directory, it complains about the spec file for geticon. LD_LIBRARY_PATH="/home/mbc/src/wineall/wine/library:/home/mbc/src/wineall/wine/dlls:$LD_LIBRARY_PATH" /home/mbc/src/wineall/wine/tools/winebuild/winebuild -fPIC -L/home/mbc/src/wineall/wine/dlls -sym geticon.tmp.o -o geticon.spec.c -spec ./geticon.spec ./geticon.spec:3: Expected name, id, length or ordinal make[1]: *** [geticon.spec.c] Error 1 make[1]: Leaving directory `/home/mbc/src/wineall/utils/geticon' make: *** [geticon] Error 2 Has the spec file format changed? According to the manpage in it's dir, it's the same, and according to the docs on winehq the format is unchanged. thanks for your time michael -- michael cardenas | lead software engineer | lindows.com | hyperpoem.net "A painting of a rice cake does not satisfy hunger." - Ancient saying

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel