wine-bugs April 2018

wine-bugs@winehq.org

1 participants
8108 discussions

[Bug 45097] New: Wrong process name when using CreateProcess from kernel32
by wine-bugs＠winehq.org 07 May '18

07 May '18

https://bugs.winehq.org/show_bug.cgi?id=45097 Bug ID: 45097 Summary: Wrong process name when using CreateProcess from kernel32 Product: Wine Version: 3.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: sr-tream(a)yandex.ru Distribution: --- After using CreateProcess from kernel32 on Linux, lpCommandLine is used as the process name, although lpApplicationName should be used. ================================================================================= BOOL WINAPI CreateProcess( _In_opt_ LPCTSTR lpApplicationName, _Inout_opt_ LPTSTR lpCommandLine, _In_opt_ LPSECURITY_ATTRIBUTES lpProcessAttributes, _In_opt_ LPSECURITY_ATTRIBUTES lpThreadAttributes, _In_ BOOL bInheritHandles, _In_ DWORD dwCreationFlags, _In_opt_ LPVOID lpEnvironment, _In_opt_ LPCTSTR lpCurrentDirectory, _In_ LPSTARTUPINFO lpStartupInfo, _Out_ LPPROCESS_INFORMATION lpProcessInformation ); -- 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.

1 3

[Bug 41438] New: fastone image viewer 5.9 "crop" window do not show if called by hotkey from full screen mode
by wine-bugs＠winehq.org 07 May '18

07 May '18

https://bugs.winehq.org/show_bug.cgi?id=41438 Bug ID: 41438 Summary: fastone image viewer 5.9 "crop" window do not show if called by hotkey from full screen mode Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: unxed(a)mail.ru Distribution: --- steps to reproduce: 1. get faststone image viewer from here: http://www.faststone.org/FSViewerDownload.htm 2. select any image 3. press "enter" to go to fullscreen mode 4. prexx "x" for crop properties window 5. the window will be shown in background, with no way to switch to it: actually unusable -- 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.

1 5

[Bug 45099] New: SetWindowPlacement doesn' t restore the normal position correctly
by wine-bugs＠winehq.org 07 May '18

07 May '18

https://bugs.winehq.org/show_bug.cgi?id=45099 Bug ID: 45099 Summary: SetWindowPlacement doesn't restore the normal position correctly Product: Wine Version: 3.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: vz-wine(a)zeitlins.org Distribution: --- Consider an application which calls GetWindowPlacement() on its main window to store its geometry on exit and SetWindowPlacement() on startup to restore the previously stored values. If the window of such application is maximized on exit, then the window is correctly restored to the maximized state during the next run, but restoring this window, i.e. returning it to the normal, unmaximized state, doesn't restore it to the previous position (although it does restore its size). Here are some excerpts from the logs I see with WINEDEBUG=win for the last execution: 0009:trace:win:WINPOS_SetPlacement 0x10050: setting min 0,0 max 0,55 normal (3440,1910)-(3840,2160) flags 6 ajusted to min 0,0 max 0,55 normal (3440,1910)-(3840,2160) 0009:trace:win:SetWindowPos hwnd 0x10050, after (nil), 3440,1910 (400x250), flags 00000014 ... 0009:trace:win:WINPOS_MinMaximize 0x10050 3 0009:trace:win:GetWindowPlacement 0x10050: returning min -1,-1 max 0,55 normal (3440,1910)-(3840,2160) 0009:trace:win:GetWindowRect hwnd 0x10050 (3440,1910)-(3840,2160) ... I restore the window here ... 0009:trace:win:WINPOS_MinMaximize 0x10050 9 0009:trace:win:GetWindowPlacement 0x10050: returning min -1,-1 max 0,55 normal (3440,1910)-(3840,2160) ... almost immediately after ... 0009:trace:win:USER_SetWindowPos status flags = 1807 0009:trace:win:GetWindowRect hwnd 0x10064 (3445,2119)-(3835,2155) 0009:trace:win:GetWindowRect hwnd 0x10064 (3445,2119)-(3835,2155) 0009:trace:win:GetWindowRect hwnd 0x10064 (3445,2119)-(3835,2155) 0009:trace:win:GetWindowRect hwnd 0x10050 (3440,1910)-(3840,2160) 0009:trace:win:SetWindowPos hwnd 0x10050, after (nil), 115,87 (400x250), flags 00000015 ... when closing the program ... 0009:trace:win:GetWindowPlacement 0x10050: returning min -1,-1 max 0,55 normal (115,87)-(515,337) I.e. SetWindowPlacement() is passed the correct position (3440,1910 corresponding to the lower right corner), and even restoring it still uses the same correct position, but then the window is somehow moved to the wrong position (115,87) for some reason which I don't understand. This is just a minor irritant, of course, but I'd still like to open this bug just in case it's also simple to fix. -- 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.

1 1

[Bug 30762] New: msxml3/domdoc tests flaky
by wine-bugs＠winehq.org 06 May '18

06 May '18

http://bugs.winehq.org/show_bug.cgi?id=30762 Bug #: 30762 Summary: msxml3/domdoc tests flaky Product: Wine Version: 1.5.4 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: msxml3 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified ca48dac8821e128db8991dc54b4dedc8c321e816 and 9c0486d7a802c2f618a56a2074c5d790d329e3cf both seem to have introduced some flaky tests in msxml3/domdoc. Here's the result of 455 runs in a loop on ubuntu 12.04 (though I also saw these on Centos 6): 342 domdoc.c:11537: Test failed: got L"http://blahblah.org" 342 domdoc.c:11542: Test failed: got L"http://blah.org" 350 domdoc.c:11647: Test failed: got L"http://blahblah.org" 350 domdoc.c:11652: Test failed: got L"http://blah.org" 3 domdoc.c:2098: Test failed: can't create file C:\users\dank\Temp\leading_spaces.xml: 32 -- 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.

1 7

[Bug 28578] New: Editing a wiki page strips out carriage returns from all preformatted text on that page
by wine-bugs＠winehq.org 06 May '18

06 May '18

http://bugs.winehq.org/show_bug.cgi?id=28578 Bug #: 28578 Summary: Editing a wiki page strips out carriage returns from all preformatted text on that page Product: WineHQ.org Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dimesio(a)earthlink.net Classification: Unclassified This most recently happened with the Regression Testing page (bug 28575), but I've seen it before on other pages: carriage returns are removed from preformatted text, even if that part is not edited directly, and the preformatted text turns into an unreadable mess. It used to be possible to avoid this by staying in GUI mode and not previewing, but that seems to no longer work. -- 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.

1 23

[Bug 33470] New: Don't allow to create wiki pages with external links
by wine-bugs＠winehq.org 06 May '18

06 May '18

http://bugs.winehq.org/show_bug.cgi?id=33470 Bug #: 33470 Summary: Don't allow to create wiki pages with external links Product: WineHQ.org Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: www-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dmitry(a)baikal.ru CC: dimi(a)lattica.com Classification: Unclassified Just have a look at http://wiki.winehq.org/RecentChanges, it really starts to take quite a bit of an effort to clean Wine wiki from spam. Apparently, spammers can't be stopped by keywords listed in the stop list http://wiki.winehq.org/LocalBadContent, and that's another problem. Disallowing to create wiki pages with external links is considered main and very efficient way to stop wiki spam, there are many resources explaining how to do that for various wiki engines. -- 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.

1 16

[Bug 31296] New: broken link http://www.winehq.org/docs/wineusr-guide/installing-wine-source/running
by wine-bugs＠winehq.org 06 May '18

06 May '18

http://bugs.winehq.org/show_bug.cgi?id=31296 Bug #: 31296 Summary: broken link http://www.winehq.org/docs/wineusr-guide/installing-wi ne-source/running Product: WineHQ.org Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: Szymon.Piszczek(a)gmail.com Classification: Unclassified Broken link on page http://www.winehq.org/docs/wineusr-guide/installing-wine-source/ (Wine User Guide Chapter 2. Getting Wine): link "Next" in right top corner points to http://www.winehq.org/docs/wineusr-guide/installing-wine-source/running which said "404" -- 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.

1 6

[Bug 29574] New: Ajax example fails with unspecified error (IE8)
by wine-bugs＠winehq.org 06 May '18

06 May '18

http://bugs.winehq.org/show_bug.cgi?id=29574 Bug #: 29574 Summary: Ajax example fails with unspecified error (IE8) Product: Wine Version: 1.3.36 Platform: x86 URL: http://www.w3schools.com/ajax/tryit.asp?filename=tryaj ax_asyncfalse OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: msxml3 AssignedTo: wine-bugs(a)winehq.org ReportedBy: ocean04(a)suomi24.fi Classification: Unclassified There are many examples: http://www.w3schools.com/ajax/default.asp All work fine except this one: http://www.w3schools.com/ajax/tryit.asp?filename=tryajax_asyncfalse 1. winetricks ie8 2. open that page in ie 3. click "Change Content" -> There is yellow question mark "unspecified error". Workaround is winetricks msxml3 -- 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.

1 21

[Bug 40642] New: Show windows application menu in OS X global menubar
by wine-bugs＠winehq.org 03 May '18

03 May '18

https://bugs.winehq.org/show_bug.cgi?id=40642 Bug ID: 40642 Summary: Show windows application menu in OS X global menubar Product: Wine Version: 1.9.9 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)winehq.org Reporter: f.platte(a)platte-web.de Distribution: --- The MacDriver has evolved significantly from when it was introduced and I have no need to use the X11 window environment since quiet some time. However what is still missing menubar integration. I don't know if this ever was planed, however I think this is one of the most logical progression for wine on OS X. I'm posting this now because I just came across a windows tool which does exactly that. While there were always attempts to theme windows like OS X and emulating the global menubar now someone found a way to do just that (http://lee-soft.com/el-capitan-menubar-for-windows/). So as it's possible to extract windows applications' menus it might be possible to integrate them into OS X's menubar as GTK and Java can inject menus there, too. While I related this "bug report" to the MacDriver and OS X it might also be useful for Ubuntu, as it (optionally) also features a global menubar. -- 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.

1 8

[Bug 43231] New: Dai-Senryaku Perfect 3.0:Not draw background with GDI.
by wine-bugs＠winehq.org 02 May '18

02 May '18

https://bugs.winehq.org/show_bug.cgi?id=43231 Bug ID: 43231 Summary: Dai-Senryaku Perfect 3.0:Not draw background with GDI. Product: Wine Version: 2.9 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: whatisthis.sowhat(a)gmail.com Distribution: --- When playing Dai-Senryaku Perfect 3.0 for PC (大戦略バーフェクト3.0 http://www.ss-alpha.co.jp/products/dsperfect3.html ), using with GDI as DDraw renderer, not show background and map. When using OpenGL as renderer, background and map were drawn, but, very slowly. Too slow to unplayable. With Wine 2.0, with GDI, play fine.But with 2.0 with OpenGL, very slowly. Note: 1. Trial version is available: http://www.ss-alpha.co.jp/download/dsperfect3_tk.html 2. For product version, set registry values to "DSP3.bin", do not set to "DSP3.exe". Regards. -- 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.

1 8

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-bugs April 2018