- Wine-Bugs - list.winehq.org

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

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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 May 25, 2002

May 25, 2002

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

[Bug 24] Changed - err:progress:ProgressWindowProc unknown msg be10 wp=34940001 lp=00003494
by wine-bugs＠winehq.com May 25, 2002

May 25, 2002

http://bugs.winehq.com/show_bug.cgi?id=24 *** shadow/24 Thu Mar 28 23:35:24 2002 --- shadow/24.tmp.32513 Sat May 25 17:13:50 2002 *************** *** 2,13 **** | err:progress:ProgressWindowProc unknown msg be10 wp=34940001 lp=00003494 | +----------------------------------------------------------------------------+ | Bug #: 24 Product: Wine | ! | Status: NEW Version: unspecified | | Resolution: Platform: | | Severity: normal OS/Version: All | | Priority: P1 Component: wine-gui | +----------------------------------------------------------------------------+ ! | Assigned To: bugs(a)codeweavers.com | | Reported By: 914(a)bianca.com | +----------------------------------------------------------------------------+ | Milestone: TargetMilestone: --- | --- 2,13 ---- | err:progress:ProgressWindowProc unknown msg be10 wp=34940001 lp=00003494 | +----------------------------------------------------------------------------+ | Bug #: 24 Product: Wine | ! | Status: RESOLVED Version: unspecified | | Resolution: Platform: | | Severity: normal OS/Version: All | | Priority: P1 Component: wine-gui | +----------------------------------------------------------------------------+ ! | Assigned To: wine-bugs(a)winehq.com | | Reported By: 914(a)bianca.com | +----------------------------------------------------------------------------+ | Milestone: TargetMilestone: --- | *************** *** 112,114 **** --- 112,118 ---- ------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-03-28 23:35 ------- Adding myself to CC: list + + ------- Additional Comments From Speeddymon(a)yahoo.com 2002-05-25 17:13 ------- + Reporter, try your program out on a recent wine build, if the problem exists, + please reopen the bug.. \ No newline at end of file

1 0