May 2002 - Wine-bugs - list.winehq.org

Lower bugs changing note
by Dustin Navea 25 May '02

25 May '02

The changes on the lower numbered bugs are done by me, trying to get some of these old bugs out of he list of ones to be worked on, if they have been fixed..... __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

[Bug 654] Changed - Can't install ms money web edition from win98se installation cd
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=654 *** shadow/654 Fri May 24 04:59:16 2002 --- shadow/654.tmp.1484 Sat May 25 17:40:14 2002 *************** *** 43,45 **** --- 43,51 ---- Try a workaround - backup the files while they exist in the temporary directory, then try to execute the webinst.exe installer manually. + + ------- Additional Comments From puoti(a)inwind.it 2002-05-25 17:40 ------- + I tried, but I got a message windows (Wine) message saying that some files coud + not open some files, despite they wehere all in the backuped directory, but wine + exited with a succesful status, I don't think you are ment to do these sort of + things, and if setup will ever eork, it will be from normal setup. \ No newline at end of file

1 0

[Bug 721] Changed - Missing 'FONTS' dir
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=721 *** shadow/721 Sat May 25 16:30:41 2002 --- shadow/721.tmp.1377 Sat May 25 17:37:22 2002 *************** *** 2,13 **** | Missing 'FONTS' dir | +----------------------------------------------------------------------------+ | Bug #: 721 Product: Wine | ! | Status: ASSIGNED Version: unspecified | | Resolution: Platform: | | Severity: normal OS/Version: All | | Priority: P1 Component: wine-tools | +----------------------------------------------------------------------------+ ! | Assigned To: Speeddymon(a)yahoo.com | | Reported By: maxx2(a)veneto.com | +----------------------------------------------------------------------------+ | Milestone: TargetMilestone: --- | --- 2,13 ---- | Missing 'FONTS' dir | +----------------------------------------------------------------------------+ | Bug #: 721 Product: Wine | ! | Status: NEW Version: unspecified | | Resolution: Platform: | | Severity: normal OS/Version: All | | Priority: P1 Component: wine-tools | +----------------------------------------------------------------------------+ ! | Assigned To: wine-bugs(a)winehq.com | | Reported By: maxx2(a)veneto.com | +----------------------------------------------------------------------------+ | Milestone: TargetMilestone: --- | *************** *** 93,95 **** --- 93,118 ---- config output so that it remaps the fonts i listed above to a native unix fonts... this can already be done in the fonts section, but i will discuss it with alexandre about which would be the better solution + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:37 ------- + Talked to Alexandre, and he reminded me that the MS fonts are copyrighted, so + we couldn't simply include them in wine's source... The best bet for right now + would be to download the default fonts from microsof, although I am not sure of + the link to them + + What I may try to do is implement some sort of override for the fonts like the + dll overrides and like alexandre's .exe overrides where you have something like + + [DllOverrides] + "arial.ttf"="builtin, native" + + [fonts] + alias1=blah blah + + so that wine defaults to using the "native" font, i.e. the MS version of it, if + it exists, and if it doesn't it uses the "builtin" one, i.e. the alias for that + font in the fonts section of the config, that way users can decide which MS + fonts get used by wine and which unix fonts get subbed for the MS equivalent... + + its kinda complicated to explain, but seems like it would work... if i get a + chance to work on it... \ No newline at end of file

1 0

[Bug 53] New - PrgWin95: Wine does not support Win9x style (16bit) coordinates
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=53 *** shadow/53 Sat May 25 17:25:14 2002 --- shadow/53.tmp.928 Sat May 25 17:25:14 2002 *************** *** 0 **** --- 1,54 ---- + +============================================================================+ + | PrgWin95: Wine does not support Win9x style (16bit) coordinates | + +----------------------------------------------------------------------------+ + | Bug #: 53 Product: Wine | + | Status: NEW Version: unspecified | + | Resolution: Platform: | + | Severity: normal OS/Version: All | + | Priority: P1 Component: wine-gdi | + +----------------------------------------------------------------------------+ + | Assigned To: wine-bugs(a)winehq.com | + | Reported By: fgouget(a)codeweavers.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | Milestone: TargetMilestone: --- | + | URL: | + +============================================================================+ + | DESCRIPTION | + On Win9x if one draws a line to (65520,65520) it should go to the top left + corner of the Window (with an MM_TEXT coordinate system I believe). In Wine, + and, I believe, in NT too, this line would go to the bottom right corner of the + Window. + + The reason is that Win9x only supports 16bit coordinates, i.e. values ranging + from -32768 to 32767 so that 65520 is way in the negatives, while NT supports + 32bit coordinates so that 65520 is, well, what it is. + + So should all the GDI functions test whether winver==win9x and adjust the + coordinates accordingly if it is so? + If not we should document this... somewhere. I'm not sure where. Maybe it's + already documented somewhere, I did not find it. Do we have some sort of a + 'limitations' section? + + History: + This issue was revealed to me by the capture2 example of the Petzold 95. When + the mouse got out to the left of the window, the application would behave as if + it was to the far right. I traced it down to the WM_MOUSEMOVE message that was + returning values like 65520 but then noticed Win9x was doing the same. That's + when I realized it was the Rectangle API that was behaving differently. + Actually I should also test this in NT to see if NT too returns 65xxx in + WM_MOUSEMOVE for values <0, and to see how this application behaves in NT. + + See also: + http://fgouget.free.fr/wine/PrgWin95/Chap6.shtml#capture2 + + ------- Additional Comments From fgouget(a)codeweavers.com 2000-10-25 14:59 ------- + I tested capture2 on Windows NT and Windows 2000 and it behaves just like in + Wine. + So it is definitely a bug in the application: wherever it does 'ptEnd.x = + LOWORD (lParam) ;' it should do 'ptEnd.x = (short)LOWORD (lParam) ;' instead. + But the core of this report remains. + + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:25 ------- + This still an issue or should it be closed? \ No newline at end of file

1 0

[Bug 52] New - PrgWin95: Problems with access to the root window
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=52 *** shadow/52 Sat May 25 17:23:40 2002 --- shadow/52.tmp.778 Sat May 25 17:23:40 2002 *************** *** 0 **** --- 1,41 ---- + +============================================================================+ + | PrgWin95: Problems with access to the root window | + +----------------------------------------------------------------------------+ + | Bug #: 52 Product: Wine | + | Status: NEW Version: unspecified | + | Resolution: Platform: | + | Severity: normal OS/Version: All | + | Priority: P1 Component: wine-gdi | + +----------------------------------------------------------------------------+ + | Assigned To: wine-bugs(a)winehq.com | + | Reported By: fgouget(a)codeweavers.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | Milestone: TargetMilestone: --- | + | URL: | + +============================================================================+ + | DESCRIPTION | + The Petzold 95 contains an example program, scramble, which divides the + screen into small rectangles, swaps them randomly., and then waps them in the + exact reverse order so that in the end the screen is unchanged. + The first time I ran it in Wine I was actually amazed that it managed to grab + the screen's contents at all. + But I quickly recovered and started wondering why the screen is not restored + correctly. As the program runs the contents of the cells quickly become slightly + corrupted and they end up looking all alike. + And the screen is scrambled until you invoke the refresh of your window + manager. + + Actually, I still wonder why it does not work hence this report! + + Oh, I did try to make sure noone was updating the screen while this + application was running. + + See also: + http://fgouget.free.fr/wine/PrgWin95/Chap4.shtml#scramble + + Is there some fundamental impossibility, in which case fine, let's document + it somewhere and close this report. Or is there an actual bug? + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:23 ------- + whats up with this bug, does it still exist? \ No newline at end of file

1 0

[Bug 50] New - PrgWin95: Text justification needs beefing up
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=50 *** shadow/50 Sat May 25 17:22:36 2002 --- shadow/50.tmp.725 Sat May 25 17:22:36 2002 *************** *** 0 **** --- 1,38 ---- + +============================================================================+ + | PrgWin95: Text justification needs beefing up | + +----------------------------------------------------------------------------+ + | Bug #: 50 Product: Wine | + | Status: NEW Version: unspecified | + | Resolution: Platform: | + | Severity: trivial OS/Version: All | + | Priority: P1 Component: wine-gdi | + +----------------------------------------------------------------------------+ + | Assigned To: wine-bugs(a)winehq.com | + | Reported By: fgouget(a)codeweavers.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | Milestone: TargetMilestone: --- | + | URL: | + +============================================================================+ + | DESCRIPTION | + Running the justify1 example from the Petzold 95 the feeling I get is that + the text is not justified. + + I say that because the end of lines don't line up. Yet if I pay attention to + the size of spaces there is no doubt that they don't have the same width. So + something is actually being done. + + I suspect that the problem is that we don't carry the rounding errors. What + conforts me in this idea is that the longer the line is the bigger the + differences between lines are. Actually I also got tipped by the MSDN + documentation for SetTextJustification. + See http://msdn.microsoft.com/library/psdk/gdi/fontext_9lm6.htm + + Also suspicious is the fact the SetTextJustification is not implemented by + x11drv. + + See also: + http://fgouget.free.fr/wine/PrgWin95/Chap4.shtml#justify1 + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:22 ------- + is this problem still existant Francois? \ No newline at end of file

1 0

[Bug 48] Changed - PrgWin95/98: System metrics differ from the Win9x values
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=48 *** shadow/48 Thu May 16 11:11:27 2002 --- shadow/48.tmp.642 Sat May 25 17:21:29 2002 *************** *** 95,97 **** --- 95,101 ---- SM_CXMENUCHECK 14 13 SM_CYMENUCHECK 14 13 + + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:21 ------- + are the differences still present, or can this bug be closed? \ No newline at end of file

1 0

[Bug 47] Changed - wrc does not find system headers
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=47 *** shadow/47 Thu Mar 28 22:27:44 2002 --- shadow/47.tmp.458 Sat May 25 17:19:18 2002 *************** *** 7,13 **** | Severity: normal OS/Version: All | | Priority: P1 Component: wine-winelib | +----------------------------------------------------------------------------+ ! | Assigned To: bugs(a)codeweavers.com | | Reported By: fgouget(a)codeweavers.com | | CC list: Cc: | +----------------------------------------------------------------------------+ --- 7,13 ---- | Severity: normal OS/Version: All | | Priority: P1 Component: wine-winelib | +----------------------------------------------------------------------------+ ! | Assigned To: wine-bugs(a)winehq.com | | Reported By: fgouget(a)codeweavers.com | | CC list: Cc: | +----------------------------------------------------------------------------+ *************** *** 67,69 **** --- 67,74 ---- ------- Additional Comments From fgouget(a)codeweavers.com 2002-03-19 14:41 ------- Yep, still happens with CVS 2002/03/18. + + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:19 ------- + Guess I will leave this one alone, since it existed a couple months ago, feel + free to test again with a recent CVS if you want to Francois \ No newline at end of file

1 0

[Bug 39] New - PrgWin95: Wrong message sequence for keyboard auto-repeat
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=39 *** shadow/39 Sat May 25 17:17:26 2002 --- shadow/39.tmp.365 Sat May 25 17:17:26 2002 *************** *** 0 **** --- 1,68 ---- + +============================================================================+ + | PrgWin95: Wrong message sequence for keyboard auto-repeat | + +----------------------------------------------------------------------------+ + | Bug #: 39 Product: Wine | + | Status: NEW Version: unspecified | + | Resolution: Platform: | + | Severity: normal OS/Version: All | + | Priority: P1 Component: wine-kernel | + +----------------------------------------------------------------------------+ + | Assigned To: wine-bugs(a)winehq.com | + | Reported By: fgouget(a)codeweavers.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | Milestone: TargetMilestone: --- | + | URL: | + +============================================================================+ + | DESCRIPTION | + The message sequence that Wine generates when a key is in auto-repeat mode is + incorrect. + + In Windows one gets a series of WM_KEYDOWN messages. The first one has the + 'previous state' bit (30th of LPARAM) set to 0, and all those that come after + have it set to 1. Then when the key is released the application gets a single + WM_KEYUP message. + + In Wine the application receives a succession of WM_KEYDOWN and WM_KEYUP + messages instead. Note that this description is valid for a key like the down + arrow key. + + If the key generates characters, 'a' for instance, then these messages streams + are interspersed with WM_CHAR messages. But the principle remains the same. + + This problem is best illustrated by a couple of programs from programming books: + - the keylook example of the chapter 5 of the 'Programming Windows 95' Petzold + - the KeyView1 example of the chapter 6 of the 'Programming Windows 98' Petzold + - the VirtualKey example of the chapter 3 of 'Programming Windows 95 with MFC' + + See also: + http://fgouget.free.fr/wine/PrgWin95/Chap5.shtml#keylook + http://fgouget.free.fr/wine/PrgWin98/Chap6.shtml#KeyView1 + http://fgouget.free.fr/wine/PrgMFC/Chap3.shtml#VisualKB + + ------- Additional Comments From dtimoshkov(a)codeweavers.com 2000-11-03 03:33 ------- + The root of this problem lies in the way X server sends keyboard events. + X *always* generates Down/Up events for the single key press. It could + be seeing with the xev tool. I don't know a way yet how to work around it. + + One ugly hack could be to delay sending WM_KEYUP message, but for what + amount of time: until next key press, 1 ms, next X event, ...? + + ------- Additional Comments From fgouget(a)codeweavers.com 2000-11-12 15:01 ------- + + Disclaimer: I don't know anything about the way X handles the keyboard. + + But I just got an idea. In most systems you can receive an event saying that + such and such key has been pressed/released, but you can also query whether a + given key is up or down. + When we receive the KeyUp event, would it be possible to query X to determine + if the key is really up or if it is pressed? If it is still pressed, then we + would ignore the KeyUp event, mark the key as pressed internally, and on the + next KeyDown event we would send a VM_KEYDOWN with the bit 30 set to 1. + Of course doing so probably won't be very simple: I guess there will be nasty + key mapping issues, it will introduce a (small) delay if the X server is + remote... But the point is moot if we cannot query the state of a key with X. + + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:17 ------- + Should this bug be closed? no comment on it for over a year...... \ No newline at end of file

1 0

[Bug 26] Changed - StrokeAndFillPath doesn't fill paths on EMF
by wine-bugs＠winehq.com 25 May '02

25 May '02

http://bugs.winehq.com/show_bug.cgi?id=26 *** shadow/26 Tue Apr 16 13:49:00 2002 --- shadow/26.tmp.32631 Sat May 25 17:15:12 2002 *************** *** 2,8 **** | StrokeAndFillPath doesn't fill paths on EMF | +----------------------------------------------------------------------------+ | Bug #: 26 Product: Wine | ! | Status: NEW Version: unspecified | | Resolution: Platform: | | Severity: normal OS/Version: All | | Priority: P1 Component: wine-gdi | --- 2,8 ---- | StrokeAndFillPath doesn't fill paths on EMF | +----------------------------------------------------------------------------+ | Bug #: 26 Product: Wine | ! | Status: RESOLVED Version: unspecified | | Resolution: Platform: | | Severity: normal OS/Version: All | | Priority: P1 Component: wine-gdi | *************** *** 37,39 **** --- 37,44 ---- ------- Additional Comments From e.persiani(a)bo.nettuno.it 2000-10-20 03:49 ------- I just forgot to tell you that the image changes the fill-mode to ALTERNATE... + + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:15 ------- + Reporter, try your app on a recent wine build, if the problem still exists, + repoen the bug... \ No newline at end of file

1 0