March 2019 - Wine-bugs - list.winehq.org

[Bug 46677] New: Test Drive Unlimited 2 Crash at begins
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=46677 Bug ID: 46677 Summary: Test Drive Unlimited 2 Crash at begins Product: Wine Version: 4.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mrdeathjr28(a)yahoo.es Distribution: --- Created attachment 63629 --> https://bugs.winehq.org/attachment.cgi?id=63629 backtrace Game shows credits first screen and after this crash -- 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 46629] New: Unravel Two crashes crashes during loading
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=46629 Bug ID: 46629 Summary: Unravel Two crashes crashes during loading Product: Wine-staging Version: 4.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ahmed.com(a)protonmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 63528 --> https://bugs.winehq.org/attachment.cgi?id=63528 Unravel Two.log Unravel two crashes at the beginning of loading. Any suggestions will be appreciated. -- 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 11

[Bug 46705] New: Revenant GOG don't running
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=46705 Bug ID: 46705 Summary: Revenant GOG don't running Product: Wine Version: 3.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: evjeniy(a)mail.ru Distribution: --- Created attachment 63665 --> https://bugs.winehq.org/attachment.cgi?id=63665 setup.txt Wine version (staging) I use environment variables: WINEARCH = win32 WINEPREFIX = clean winecfg defaults Additional libraries: winetricks d3dx9_36 directplay quartz At the end of the installation process (similar to installing directx9.0c) "Runtime error (at 73: 1358):" "Runtime error (at 210: 800): Out Of Stack Range." "Runtime error (at 210: 806): Out Of Stack Range." "Out of Global Vars range." Console output (setup.txt) In winecfg I put the checkbox "Graphics -) Emulate a virtual desktop 640x480" During launch: FATAL ERROR. "DirectX Error D3DERR_SURFACENOTINVIDMEM in d: \ revenant \ DirectDraw.cpp at line 333" Console output (start.txt) -- 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 4

[Bug 46759] New: Wine Resource Compiler (wrc) ignores options in POPUP statement
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=46759 Bug ID: 46759 Summary: Wine Resource Compiler (wrc) ignores options in POPUP statement Product: Wine Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: roger.moser(a)pamho.net If you have the following resource script: xyz MENU BEGIN POPUP "Grayed Popup", GRAYED MENUITEM "Item", 100 END END then the Wine Resource Compiler (wrc), unlike Microsoft's RC, ignores the options like GRAYED in the POPUP statement. To fix this bug, make the following change in the file tools/wrc/parser.y at around line 1235: | item_definitions tPOPUP tSTRING item_options menu_body { $$ = new_menu_item(); $$->prev = $1; if($1) $1->next = $$; $$->popup = get_item_head($5); $$->state = $4; // <<<<<<<< Insert this line <<<<<<<< $$->name = $3; } ; -- 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 5891] Multiple apps need control panel applet association/handler ( registry) to support running through start.exe or rundll32.exe shell32.dll ,Control_RunDLL (bftelnet)
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=5891 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86 OS|other |Linux --- Comment #8 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, still present. Wohoo ... approaching 13 year anniversary here ;-) --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/BFtelnet $ file * bfsetup.exe: PE32 executable (GUI) Intel 80386, for MS Windows bftelnet.exe: PE32 executable (console) Intel 80386, for MS Windows bftelnethelp.exe: PE32 executable (GUI) Intel 80386, for MS Windows license.rtf: Rich Text Format data, version 1, ANSI setup.cfg: ASCII text, with CRLF line terminators telm.cpl: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows $ wine cmd /c start telm.cpl 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 002a:fixme:exec:SHELL_execute flags ignored: 0x00000100 Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. $ wine rundll32.exe shell32.dll,Control_RunDLL telm.cpl 0009:fixme:win:LockWindowUpdate (0x10020), partial stub! 0009:fixme:win:LockWindowUpdate ((nil)), partial stub! 0009:fixme:win:LockWindowUpdate (0x10020), partial stub! 0009:fixme:win:LockWindowUpdate ((nil)), partial stub! --- snip --- $ sha1sum bftelnetdemo.exe 50be5be350ef871c458af150a38cc3d3483794c1 bftelnetdemo.exe $ du -sh bftelnetdemo.exe 1.4M bftelnetdemo.exe $ wine --version wine-4.3 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 0

[Bug 10913] New: start.exe doesn't support optional process title argument
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=10913 Summary: start.exe doesn't support optional process title argument Product: Wine Version: CVS/GIT Platform: Other URL: http://jedit.org OS/Version: other Status: NEW Keywords: download Severity: normal Priority: P2 Component: wine-programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Running real Java apps under the latest Sun win32 JRE on Wine seems like a fine stress test, even though in many cases users should run with the Linux JRE instead. The Sun JRE and jEdit install ok, but jedit has many startup problems. Here's the first one. Invoking it with the batch file provided by jEdit fails. Here's what's in the batch file: start "jEdit startup" "c:\windows\system32\javaw.exe" -Xms64M -Xmx192M -jar "C:\Program Files\jEdit\jedit.jar" -reuseview %* And here's what happens when you run it: $ cd ~/.wine/drive_c/Program Files/jEdit $ ~/wine-git/wine cmd /c jedit.bat fixme:exec:SHELL_execute flags ignored: 0x00000500 trace:process:CreateProcessW app (null) cmdline L"jEdit startup c:\\windows\\system32\\javaw.exe -Xms64M -Xmx192M -jar \"C:\\Program Files\\jEdit\\jedit.jar\" -reuseview" trace:process:find_exe_file looking for L"jEdit" trace:process:find_exe_file Trying native exe L"c:\\windows\\system32\\jEdit.exe" ... trace:process:find_exe_file Trying built-in exe L"c:\\windows\\system32\\jEdit startup.exe" ... trace:process:find_exe_file looking for L"jEdit startup c:\\windows\\system32\\javaw.exe -Xms64M -Xmx192M -jar \"C:\\Program Files\\jEdit\\jedit.jar\" -reuseview" Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found So it seems that start takes an optional process title argument. Sure enough, http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… documents it. Who knew? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 20

[Bug 3950] Native/builtin name conflicts: SOUND.DLL, USER.EXE, START.EXE
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

1 0

[Bug 42508] New: start.exe does not detect its title argument when it should ( breaking .e.g URL opening in League of Legends)
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=42508 Bug ID: 42508 Summary: start.exe does not detect its title argument when it should (breaking .e.g URL opening in League of Legends) Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: hydratech(a)gmail.com Distribution: --- Created attachment 57397 --> https://bugs.winehq.org/attachment.cgi?id=57397 Trace showing League of Legends Client attempting to open a URL. When start.exe is invoked, its first argument in quotes that is not an argument of the application to be executed should be interpreted as the console title. Wine's start.exe fails to do so. -- How to reproduce -- Running the following line in Wine's cmd should open a URL in your browser: Z:\>start "" https://winehq.org/ the actual result is an application not found error. On Windows the same line opens the website as expected. -- Why this is a bug -- I know this was marked as fixed in bug 10913 but the reasoning was incorrect. The argument for stating the bug was fixed was, that when \"escaping your quotes\" in cmd to the title was parsed. This is however not consistent with with Windows behaviour. As explained at the end of that bug report, if you escape your quotes in Wine's cmd start.exe parses the argument as the console title, i.e.: Z:\>start \"hello\" cmd I will now clarify why this is incorrect by showing Windows' behaviour. The following command lines are not equivalent on Windows: C:\>start hello.exe vs. C:\>start "hello.exe" The latter will open a new cmd window titled hello.exe whereas the former attempts to execute an application named hello.exe. In other words cmd's start built-in parses its own command-line checking wether quotes where used. In fact escaping the quotes using back-slashes is invalid as it tries start a process named \hello.exe\. I have tested this on both Windows 7 and Windows XP. In other words, this is invalid: C:>start \"hello.exe\" To illustrate how unintuitive this Windows behaviour is: C:>start "C:\Program Files\Application\hello.exe" Few would guess this actually opens a console titled as such, instead of running an application. That's why I can understand the maintainers would think the bug was fixed. Wine will however correctly emulate unescaped quote-senstive behaviour with the echo built-in: Z:\>echo hoi hoi Z:\>echo "hoi" "hoi" We can see echo being "aware" of the quotes and correctly displaying them; behaviour identical to Windows' echo built-in. Looking at the wine source, start.exe relies on its "argv" parameter instead of using GetCommandLine() and thereby accessing the unmodified command-line. As a consequence the difference between a quoted argument and a non-quoted argument is lost as CreateProcess strips the quotes off the parameters when passing them to execve(). To quote the source of Wine's cmd.exe (wcmdmain.c): /* Can't use argc/argv as it will have stripped quotes from parameters * meaning cmd.exe /C echo "quoted string" is impossible */ It should now be evident that start.exe should either become a wrapper around cmd.exe's built-in start function, invoking cmd and let cmd itself implement start.exe's actual behaviour, or implement GetCommandLine() based argument parsing similar to cmd.exe's within start.exe, leading to duplicated command-line parsing code. Both are not ideal solutions. -- Why does this bug matter? -- There are actually Windows applications relying on this behaviour to open URLs in the user's browser. As an example, League of Legends executes the following shell command to open a URL: cmd.exe /c start "" "<url here>" In other words, League instructs start to launch an untitled shell window with a URL as application, effectively causing the shell to pass it to the browser. However, wine's start.exe interprets this as League trying to execute an empty string as executable name, with a URL as argument. I have attached the relevant output running League with WINEDEBUG=cmd,start,process,exec set. I will speculate that more applications will run into this exact same issue. League's client is based on CEF and it might very well be CEF which implements this style of external URL opening, furthermore there is documentation recommending the use of empty quotes as console title argument when invoking start to prevent it from accidentally parsing follow up arguments in quotes as the console title, think "C:\Program Files\etc...", establishing this as a pattern that might well have been adopted by other applications. See: https://ss64.com/nt/start.html I will also say that, given some instruction, I will be glad to help fixing this bug and write any necessary code. There is actually another issue with current start.exe's console title parsing which I will submit as a separate issue. That issue is however, significantly easier to fix. Finally this also means wine's current handling of command-line arguments might need fixing as: $ wine start '""' "http://winehq.og" will break in a fixed version of 'start.exe', while it should work. For this I will file yet another issue, although the necessity of this fix is debatable. -- 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 13

[Bug 46756] New: Running (Linux) bash from Wine doesn't output anything
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=46756 Bug ID: 46756 Summary: Running (Linux) bash from Wine doesn't output anything Product: Wine Version: 4.2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Best explained by an example. Starting bash generally works: > wine start "Z:\bin\bash" -c "echo hello > x.txt" This creates a text file, as expected. The following command does not work properly: wine start "Z:\bin\bash" -c "echo hello" No text is printed to the terminal, while it should be. Don't know where it is disappearing to. -- 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 2

[Bug 46751] New: Allow starting native binaries
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

https://bugs.winehq.org/show_bug.cgi?id=46751 Bug ID: 46751 Summary: Allow starting native binaries Product: Wine Version: unspecified Hardware: x86 OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kolan_n(a)mail.ru Sometimes apps use CLI apps, and these CLI apps have a version native for the OS and a compatible command line interface. It would be nice to allow Windows apps to call them. An example of such an app is git. Of course paths in arguments and env variables should be rewritten automatically. -- 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 11