July 2008 - Wine-Bugs - list.winehq.org

[Bug 9775] Syberia 2, Max Payne 1 & 2 - Screenshots and thumbnails broken

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=9775 --- Comment #28 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-02 18:36:36 --- Created an attachment (id=14543) --> (http://bugs.winehq.org/attachment.cgi?id=14543) fixes bug and activates test (which should pass now) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 9775] Syberia 2, Max Payne 1 & 2 - Screenshots and thumbnails broken

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=9775 --- Comment #27 from Tobias Jakobi <liquid.acid(a)gmx.net> 2008-07-02 18:36:08 --- Created an attachment (id=14542) --> (http://bugs.winehq.org/attachment.cgi?id=14542) adds the testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 13838] AutoCAD 2005 setup : Missing backslash in registry entry and profile path

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13838 --- Comment #28 from max(a)veneto.com 2008-07-02 18:32:41 --- Well, I think I've found it... In dlls/msi/appsearch.c, the function ACTION_AppSearchReg() when looking for a path in registry just gets the path as-is. Its returned path is then used to set local properties as APPDATAFOLDER (among others...) which are then set without the trailing backslash. I think the right stuff would be to add the trailing backslash inside Action_AppSearchReg() when required searched value is a directory : ---snip--- switch (type & 0x0f) { case msidbLocatorTypeDirectory: ====> HERE add the backslash to string... must reallocate string increasing size by one and copy it, if there's no better way. rc = ACTION_SearchDirectory(package, sig, (LPWSTR)value, 0, appValue); break; case msidbLocatorTypeFileName: *appValue = strdupW((LPWSTR)value); break; ---snip--- Ciao Max -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 5852] Gray background color overlays Items

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=5852 Matthew D'Asaro <medasaro(a)comcast.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |medasaro(a)comcast.net --- Comment #11 from Matthew D'Asaro <medasaro(a)comcast.net> 2008-07-02 18:14:03 --- I can confirm this problem still exists in Wine 1.1.0. I have also seen a similar issue in other 16 bit applications. -Matthew D'Asaro -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 14234] WC Prophecy and SO crash in both software and D3D modes

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14234 --- Comment #2 from DanLev <dlev89(a)gmail.com> 2008-07-02 18:12:50 --- (In reply to comment #1) > Doesn't look like Wine crash. Enable core dumping (ulimit -c unlimited) and > examine it to see what's crashing. > I know it's a Wine problem, since SO and Prophecy worked in earlier versions of Wine... Anyway here's the core dump. It's 44 MB... Hope it helps: http://www.mediafire.com/?9cbuzbsfzdy -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 14118] wine needs its own dxdiag

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14118 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> 2008-07-02 18:04:16 --- closing -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 14118] wine needs its own dxdiag

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14118 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |ABANDONED --- Comment #4 from Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> 2008-07-02 18:04:00 --- apparently there seems to be no need to have a dxdiag in wine, so i'll abandon the bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 13838] AutoCAD 2005 setup : Missing backslash in registry entry and profile path

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13838 --- Comment #27 from max(a)veneto.com 2008-07-02 17:57:47 --- (In reply to comment #26) > (In reply to comment #25) > > Another finding... The problem arises from the case-sensitivity of properties. > > In dlls/msi/package.c, the properties 'LocalAppDataFolder' and 'AppDataFolder' > > are initialized to corresponding register values WITH the trailing backslash. > > > > There are tons of tests to prove that property names are case sensitive. That one I know for sure, it's stated everywhere..... > What > needs to be tested is if LOCALAPPDATAFOLDER and APPDATAFOLDER are also set as > well as their counterparts. They're NOT tested as their counterparts. The capitalized ones (i.e. the LOCAL ones) are set with NO trailing backslash. The global (uncapitalized) ones are set WITH the trailing backslash. BTW, I still don't know WHERE the capitalized ones are set.... I don't know installer so in depth. Maybe do you ? > > > AutoCAD installer OTOH looks for the properties CAPITALIZED, so > > 'LOCALAPPDATAFOLDER' and 'APPDATAFOLDER' which are initialized (don't know > > where yet) as corresponding registry values WITHOUT trailing backslash. > > > > Shouldn't be too hard to find... Well, for me it is... (to find WHERE capitalized props are set and WHY they're different from global ones) > > > I guess it's a bug in Acad installer, but I guess M% returns the capitalized > > properties with backslash too, as uncapitalized ones, so the installer just > > appends 'Autodesk' to returned path. > > In wine, the resulting path misses the backslash between the returned property > > and the word 'Autodesk'. > > > > I think it's a little too early to say it's a bug in the acad installer. > Yep, it was too early. Now I understand the difference from capitalized props and uncapitalized ones. Max -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 13838] AutoCAD 2005 setup : Missing backslash in registry entry and profile path

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13838 --- Comment #26 from James Hawkins <truiken(a)gmail.com> 2008-07-02 17:51:48 --- (In reply to comment #25) > Another finding... The problem arises from the case-sensitivity of properties. > In dlls/msi/package.c, the properties 'LocalAppDataFolder' and 'AppDataFolder' > are initialized to corresponding register values WITH the trailing backslash. > There are tons of tests to prove that property names are case sensitive. What needs to be tested is if LOCALAPPDATAFOLDER and APPDATAFOLDER are also set as well as their counterparts. > AutoCAD installer OTOH looks for the properties CAPITALIZED, so > 'LOCALAPPDATAFOLDER' and 'APPDATAFOLDER' which are initialized (don't know > where yet) as corresponding registry values WITHOUT trailing backslash. > Shouldn't be too hard to find... > I guess it's a bug in Acad installer, but I guess M% returns the capitalized > properties with backslash too, as uncapitalized ones, so the installer just > appends 'Autodesk' to returned path. > In wine, the resulting path misses the backslash between the returned property > and the word 'Autodesk'. > I think it's a little too early to say it's a bug in the acad installer. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008

[Bug 14250] New: richedit: Deleting text at end of edit control is improperly handled

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14250 Summary: richedit: Deleting text at end of edit control is improperly handled Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: dylan.ah.smith(a)gmail.com The following steps will show the bug: 1. Open Wine's Wordpad 2. Enter plenty of lines of text so that the vertical scrollbar appears (extra lines are fine, and typing the line number for each line makes it easier to see what is happening). 3. Move the cursor to the end of the text 4. Press enter followed by backspace Builtin Result: The second last line will be repeated twice at the end until the control is repainted by doings something like minimizing and restoring the window. Native Result: The text will not be scrolled despite the fact that the end of the text is before the end of the control, and more text remains invisible because of the scroll position. Notes: - Lines don't need to be deleted at the end of the text, as long as you scroll to the end of the text. - It doesn't matter how the text is entered or deleted, so instead of hitting backspace on the last step feel free to move the cursor back and press the delete key, select with the mouse and cut, or undo. Wine seems to avoid having the scroll position so that there is extra space at the end of the control when there is enough text to fill the control, but native seems to allow this extra space to be shown. This is probably done like this in Wine because scrolling manually with the mouse wheel or using the scrollbar control doesn't allow the scroll position to be this far down. I modified wordpad's status bar to print the scroll info via GetScrollInfo and noticed that nPos and nMax increase and decrease with native richedit controls when I add lines and remove lines to the end of the text without causing the richedit control to seem to scroll. This might indicate that a copy of SCROLLINFO.nPos might be stored in the richedit control. This can be further shown with the following steps: 1. Open Wine's Wordpad 2. Enter plenty of lines of text. More than enough to cause the vertical scrollbar to shown. 3. Move the cursor to the end of the text. 4. Increase the height of the window to increase the height of the richedit control. Builtin result: The text will be scrolled down so the end of the text is at the end of the richedit control. Native result: The text will remain in the same place, with extra space left at the end of the control, until the richedit control is resized to be large enough to show all the text. Once all the text can be displayed the scrollbar will disappear, and start of the text will be at the top of the control. I hope this is detailed enough, if not let me know which steps are not clear enough to reproduce this. I tested this on Windows and in Ubuntu 8.04 with native and builtin riched20.dll on both platforms. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 2, 2008