April 2013 - Wine-bugs - list.winehq.org

[Bug 27349] New: SafeDisc v2.x API entry analyzer flags Wine's user32.dll as "bad" (too many exports with PIC loads in prolog code) (SimCity 4, ...)
by wine-bugs＠winehq.org 08 Mar '19

08 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=27349 Summary: SafeDisc v2.x API entry analyzer flags Wine's user32.dll as "bad" (too many exports with PIC loads in prolog code) (SimCity 4, ...) Product: Wine Version: 1.3.21 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, many games (and some apps) have dependency on "meta" bug 219 "Programs refuse to run because of safedisc copy-protection" which just bad (not even targeting specific version). I bought some games for few bucks just to have a look at some copy protections. Though I will probably never play them ;-) Collecting/tracking affected games/apps for this _specific_ issue here (applicable appdb entries should have bug 219 dependency removed in favor of this one). The root cause was already targeted by bug 10273 ("satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins (affects e.g. adobe photoshop)") ... That bug was closed a long time ago because it ought to work for various SD 2.x apps/games (unfortunately also depending on wine build environment/host gcc). I rejected the idea of reviving that bug and instead created a new one, targeting the affected core dll. Game: "SimCity 4" A quick scan with "ProtectionID" reveals: --- snip --- -=[ ProtectionID v0.6.4.0 JULY]=- (c) 2003-2010 CDKiLLER & TippeX Build 07/08/10-17:57:05 Ready... Scanning -> H:\.wine\drive_c\Program Files\Maxis\SimCity 4\Apps\SimCity 4.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 7971630 (079A32Eh) Byte(s) [x] Warning - FileAlignment seems wrong.. no solution calculated (using NULL) -> File has 746286 (0B632Eh) bytes of appended data starting at offset 06E4000h [File Heuristics] -> Flag : 00000000000000000100000100000111 (0x00004107) [!] Safedisc v2/v3/v4 [unknown version] detected ! [i] Appended data contents.... ... [CompilerDetect] -> Visual C++ 6.0 - Scan Took : 0.262 Second(s) --- snip --- We can do better ... The string "BoG_" is well known for detection of SafeDisc versions. --- snip --- $:~/.wine/drive_c/Program Files/Maxis/SimCity 4/Apps$ xxd -g 4 SimCity\ 4.exe | grep "BoG_" -A 2 0006fd0: 00000000 426f475f 202a3930 2e302621 ....BoG_ *90.0&! 0006fe0: 21202059 793e0000 00000000 00000000 ! Yy>.......... 0006ff0: 00000000 02000000 50000000 0a000000 ........P....... --- snip --- 0x02000000 -> 2 0x50000000 -> 90 0x0a000000 -> 10 So this is SafeDisc v2.90.10 protection. By debugging this game I came to conclusion there is still a problem with the API entry statistics. $ wine --version wine-1.3.21-26-ge6ee2c1 $ gcc --version gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) For the meaning of the table just read up some comments in bug 10273 kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x43 0x55 0x50 0x5F c2: 0x23 *0x41 0x39 0x3C c3: 0x00 0x00 0x00 0x5A * = threshold exceeded -> bad Basically the majority of exported user32 API entries have PIC register load code within range of first 8 opcode bytes of entry which is treated as trampoline (= high c2 value). --- snip --- ... .text:0001D847 __i686_get_pc_thunk_bx proc near .text:0001D847 mov ebx, [esp+0] .text:0001D84A retn .text:0001D84A __i686_get_pc_thunk_bx endp ... API entry: .text:0003735C push ebp .text:0003735D mov ebp, esp .text:0003735F push ebx .text:00037360 sub esp, 34h .text:00037363 call __i686_get_pc_thunk_bx .text:00037368 add ebx, 0AEC8Ch ... --- snip --- Kernel32 gets the good looking stats because it forwards various stuff to ntdll, letting compiler produce different function prolog code (= not having PIC register load in first place). As already mentioned in the other bug, unimpl. stubs also help to improve stats because they have 8 NOPs on entry. I've tweaked user32 again a bit just to pass the threshold - there are various ugly methods one bad as the other ;-| A method without adding unimpl. stubs or stack protector code (unreliable because cookie code can be inserted _after_ PIC code) and keeping -fPIC is to convince the compiler to use the 6 byte opcode for reserving stack space, e.g. "subl $xxx, %esp" with a 32-bit immediate (0x81,0xEB,<32 bit immediate>). Good targets are stubs and functions that make use of FIXME/TRACE. There are lots of them that can be tweaked this way (= no performance penalty), improving entry stats. Result: games work out of the box without the need of No-CD patches. Regards -- 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 30

[Bug 20104] New: Fujiprint/Fotokasten albums cannot be created due to missing richtext query interface
by wine-bugs＠winehq.org 03 Mar '19

03 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=20104 Summary: Fujiprint/Fotokasten albums cannot be created due to missing richtext query interface Product: Wine Version: 1.1.29 Platform: PC URL: http://www.fotokasten.de/index.php?ftkPage=static&ftkV iew=ftksoftware OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: cweiske(a)cweiske.de Running the "fotokasten" photo album creation software fails to create certain photo books with the following error: > fixme:richedit:fnTextSrv_QueryInterface Unknown interface: > {01c25500-4268-11d1-883a-3c8b00c10000} > fixme:richedit:fnTextSrv_OnTxInplaceDeactivate 0x3a1e8e0: STUB How to reproduce: 1. Run software 2. Click on tab "Fotobücher" 3. Click on "Fotobücher" icon 4. Click on "Fun" 5. Click on "Fun A4" 6. A loading window appears but is hidden soon after. When using Fotobücher->Fotobücher->Soft->A4, the richtext window has not to be shown, and I get to the next window (meaning it works without richtext). -- 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 9

[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 31644] New: glMapBufferRange is extremely slow while playing Resident Evil 5 ( happens only on nvidia binary driver )
by wine-bugs＠winehq.org 01 Mar '19

01 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=31644 Bug #: 31644 Summary: glMapBufferRange is extremely slow while playing Resident Evil 5 ( happens only on nvidia binary driver ) Product: Wine Version: 1.5.12 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: tizbac2(a)gmail.com Classification: Unclassified Calls to glMapBufferRange are extremely slow on nvidia drivers with resident evil 5, if this should be reported to nvidia instead just close it over 90% of frame time is taken by glMapBufferRange -- 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 20

[Bug 18496] New: BREW simulator always shows a black display
by wine-bugs＠winehq.org 01 Mar '19

01 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=18496 Summary: BREW simulator always shows a black display Product: Wine Version: 1.1.21 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: jon.dufresne(a)gmail.com Tested with wine-1.1.21 I am attempting to use the Qualcomm BREW simulator under wine. After installing, I attempted to run the example applets. The application launches and I am able to select an applet directory, but the simulated device's screen always shows black and not the usual list of icons that represent available applets. The BREW simulator installer is found here: https://brewx.qualcomm.com/bws/content/gi/products/sdk/3.1/en/3.1.5.179/ins… Steps to reproduce: 1. Download and install BREW SDK simulator 2. Run simulator 3. Use menu to selec "File->Change Applet Dir..." 4. Navigate to c:/Program Files/BREW 3.1.5/sdk/examples/ 5. Hit "OK" 6. Notice screen is black Expected results: Under windows, the BREW simulator will show a listing of the available BREW applets (one for each *.mif file in the directory chosen). This list appears as a series of icons inside the device's display area. -- 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 17

[Bug 15703] New: LEGO Star Wars controller options
by wine-bugs＠winehq.org 01 Mar '19

01 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=15703 Summary: LEGO Star Wars controller options Product: Wine Version: 1.1.6 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: infernux(a)web.de Going to "Controller Options" freezes the game, pressing "Esc" does not make it playable again. I don't know what other information / logs would be helpful, if you need anything specific just say so. This only affects the _first_ of the two games - but the 2nd seems to have a different input system anyway (requires xinpit1_2.dll for example). -- 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 17

[Bug 19777] New: Ad Astra game runs very slow glBlitFramebuffer
by wine-bugs＠winehq.org 01 Mar '19

01 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=19777 Summary: Ad Astra game runs very slow glBlitFramebuffer Product: Wine Version: 1.1.26 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P3 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: chrisyate+wine(a)gmail.com CC: chrisyate+wine(a)gmail.com Ad Astra is a free space flight sim available at www.a-astra.com. The game runs (as in starts) successfully, with a clean .wine prefix folder. However once it enters 3D mode the disk starts to grind, wine spits out lots of fixmes and the program runs slowly with fps around 3, max maybe 5. The following is output, over and over until you stop the game. <quote> fixme:d3d:stretch_rect_fbo >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION_EXT (0x506) from glBlitFramebuffer() @ device.c / 6532 fixme:d3d:state_ckeyblend Render state WINED3DRS_COLORKEYBLENDENABLE not implemented yet (repeated 6 times)... </quote> My System is Athlon XP2400+, a NVidia 6200 clone (the Zotac with 256Mb), 1.5Gb ram. Unfortunately I can't confirm whether it would work on my machine if I was running Windows natively. Any other info, please ask. -- 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 21023] New: SetupDiOpenDevRegKey() returns wrong HKEY
by wine-bugs＠winehq.org 01 Mar '19

01 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=21023 Summary: SetupDiOpenDevRegKey() returns wrong HKEY Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: setupapi AssignedTo: wine-bugs(a)winehq.org ReportedBy: mdealencar(a)gmail.com Created an attachment (id=25222) --> (http://bugs.winehq.org/attachment.cgi?id=25222) bug example In a Windows XP system SetupDiOpenDevRegKey() returns the "Device Parameters" HKEY under the device instance corresponding to the supplied (DeviceInfoSet, &DeviceInfoData) pair. Wine's SetupDiOpenDevRegKey() returns the device instance HKEY instead. The relevant registry keys are not created by Wine, so I had to import them from a Windows XP system Example: Windows HKEY returned corresponds to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_0451&Pid_6951\5&5a20206&0&1\Device Parameters Wine HKEY returned corresponds to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_0451&Pid_6951\5&5a20206&0&1 The attached registry patches and source code enable the reproduction of 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.

1 12

[Bug 32374] New: List box with LBS_NODATA set, has very low performance, depending on items count.
by wine-bugs＠winehq.org 01 Mar '19

01 Mar '19

http://bugs.winehq.org/show_bug.cgi?id=32374 Bug #: 32374 Summary: List box with LBS_NODATA set, has very low performance, depending on items count. Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: johnfound(a)evrocom.net Classification: Unclassified Created attachment 42719 --> http://bugs.winehq.org/attachment.cgi?id=42719 Test application that illustrates the bug. Source code included. List box control, when has LBS_NODATA style set, needs very big time to process LB_SETCOUNT message (this message works only for list box with LBS_NODATA set). On Windows this message is handled for less than 1ms regardless of the count sent by LB_SETCOUNT (because the list box has nothing to allocate/reallocate when LBS_NODATA is set. It only need to set the scroll bar parameters). In WINE (every version but in v1.4 and v1.5 it is really slow) processing this message needs some amount of time, proportional to the item count set by LB_SETCOUNT. As long as this list box style is provided because of its speed, such a behavior can block the execution of the application for very long time. Small test application is attached which measures the time needed for LB_SETCOUNT to be executed on list box with LBS_NODATA set. Source code included. -- 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 9

[Bug 30123] New: Mouse pointer is confined in a box lesser than the full screen
by wine-bugs＠winehq.org 23 Feb '19

23 Feb '19

http://bugs.winehq.org/show_bug.cgi?id=30123 Bug #: 30123 Summary: Mouse pointer is confined in a box lesser than the full screen Product: Wine Version: 1.4-rc4 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput AssignedTo: wine-bugs(a)winehq.org ReportedBy: kol(a)MV8660.spb.edu Classification: Unclassified Running TES5:Skyrim on the old system without Xinput2 support and on the modern Fedora 16 (but not on Ubuntu) under Wine 1.3.21 or later versions exhibits the "inertial mouse" bug described in http://appdb.winehq.org/objectManager.php?sClass=version&iId=24749 : after changing the direction of mouse movement the look continues to move in the old direction for some time. Since Wine 1.4-rc1 the old "inertial mouse" bug goes away but it is replaced by the new "clip" bug. The old bug appeared to be caused by the next strings in the dinput_mouse_hook() function in "dlls/dinput/mouse.c": if (This->clipped) pt = This->mapped_center; else GetCursorPos(&pt); which have been changed to GetCursorPos(&pt); in Wine 1.4-rc1. With new versions of Wine the mouse pointer is confined to some box lesser than the full screen. The behaviour of mouse depends on the "HKCU\Software\Wine\X11 Driver\GrabPointer" key. When it is set to "Y", the pointer is strictly confined to a box in game and in menus, when the key is set to "N", the pointer moves free in menus but mouse look in game is free within some limits and becomes very slow beyond these limits. It is similar to Bug#6971 but setting "MouseWarpOverride" to "force" does not change the mouse movement. I experimentally found a simple "patch" to workaround: in the function warp_check() in "dlls/dinput/mouse.c" file the last operator "This->clipped = ..." has to be commented out and "This->clipped = FALSE;" has to be inserted in place of. I do not know how it work but it makes the mouse look correct in Skyrim on my Fedora 10 system and, as far as I can see, does not break other games at least in fullscreen mode. -- 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 28