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

[Bug 36089] New: SpinTires a wrong dirt rendering
by wine-bugs＠winehq.org 07 Sep '19

07 Sep '19

http://bugs.winehq.org/show_bug.cgi?id=36089 Bug ID: 36089 Summary: SpinTires a wrong dirt rendering Product: Wine Version: 1.7.17 Hardware: x86 URL: http://oovee.chicsystems.net/SpinTiresInstall_060613.z ip OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Created attachment 48275 --> http://bugs.winehq.org/attachment.cgi?id=48275 in wine See attached screenshots. -- 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

[Bug 46606] New: [Git]vkd3d_d3d12.h not found
by wine-bugs＠winehq.org 07 Sep '19

07 Sep '19

https://bugs.winehq.org/show_bug.cgi?id=46606 Bug ID: 46606 Summary: [Git]vkd3d_d3d12.h not found Product: vkd3d Version: 1.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs(a)winehq.org Reporter: berillions(a)gmail.com Distribution: --- Hello, I try to build vkd3d from git and it's impossible at this moment because "vkd3d.h" does not find "vkd3d_d3d12.h". make[1] : on entre dans le répertoire « /home/babaorheum/Desktop/vkd3d-git/src/build » CC libs/vkd3d/command.lo In file included from ../vkd3d/libs/vkd3d/vkd3d_private.h:32, from ../vkd3d/libs/vkd3d/command.c:20: ../vkd3d/include/vkd3d.h:26:11: erreur fatale: vkd3d_d3d12.h : Aucun fichier ou dossier de ce type # include <vkd3d_d3d12.h> ^~~~~~~~~~~~~~~ compilation terminée. make[1]: *** [Makefile:1138: libs/vkd3d/command.lo] Error 1 make[1] : on quitte le répertoire « /home/babaorheum/Desktop/vkd3d-git/src/build » make: *** [Makefile:814: all] Error 2 ==> ERREUR : Une erreur s’est produite dans build(). Abandon… -- 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 29792] New: Gothic 2 (JoWood Productions) installer fails due to media validation tool failing (don't add FILE_ATTRIBUTE_ARCHIVE by default to file entries)
by wine-bugs＠winehq.org 07 Sep '19

07 Sep '19

http://bugs.winehq.org/show_bug.cgi?id=29792 Bug #: 29792 Summary: Gothic 2 (JoWood Productions) installer fails due to media validation tool failing (don't add FILE_ATTRIBUTE_ARCHIVE by default to file entries) Product: Wine Version: 1.4-rc1 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello, I first wanted to investigate bug 22515 hence i bought the game for a few bucks and looked into it... Well, it seems there exist different editions of the game and the problems might not be connected at all. Although this is related to copy protection it's not the SecuROM 4.x tests failing here - that part of protection works fine. I have the 3 CD set by JoWood Productions released on November 29, 2002. Near the end of installation process there is a tool "g2setup.exe" launched which verifies the authenticity of install media. That process returns a specific exit code (0x777 -> 1911) which basically says: "all checks passed". Any different exit code will roll back the whole installation! Current workaround: kill the installer from another terminal when this verification process starts. Everything has already been copied up to this point so just wait until the disc spins up and execute 'wineserver -k'. --- snip --- 0024:Starting process L"C:\\Program Files\\Jowood\\Gothic II\\g2setup.exe" (entryproc=0x4c6929) --- snip --- --- snip --- -=[ ProtectionID v0.6.4.0 JULY]=- (c) 2003-2010 CDKiLLER & TippeX Build 07/08/10-17:57:05 ... Scanning -> Z:\home\focht\.wine\drive_c\Program Files\Jowood\Gothic II\g2setup.dll File Type : 32-Bit Dll (Subsystem : Win GUI / 2), Size : 229376 (038000h) Byte(s) [File Heuristics] -> Flag : 00000000000000001100001100000001 (0x0000C301) [!] Armadillo v2.xx - v3.xx detected ! [i] Splash Setting (0x0) -> NONE / Duration : 00 second(s) [CompilerDetect] -> Visual C/C++ - Scan Took : 0.560 Second(s) --- snip --- Various anti-debugging/hacking trickery which of course can be bypassed ;-) Additionally to physical media analysis of GOTHIC2_CD3 (part of SecuROM) there are "custom" checks present. Most of them are simple ones like comparing disc serial against hard coded value. The directory structure is read from disc and CRC32 checksums are calculated for specific files. --- snip --- ATTRIBS SIZE CRC32 NAME ____________________________________________________________ A R 362,789,836 5f4cb098 Gothic2-Setup.W03 A R 123 JoWooD Homepage.url A R 14,816 Readme.txt A R 289 Register.url A R 5,569 eula.txt A R 766 gothic2.ico (DIR) 168,146,318 ArxDemo A R 31,744 1d31e5c6 ArxDemo\Setup.exe A R 877 ArxDemo\Setup.ini A R 1,304,064 ArxDemo\Setup.msi A R 101,581,207 ArxDemo\Setup1.cab A R 23,103,162 ArxDemo\Setup2.cab A R 31,150,491 ArxDemo\Setup3.cab A R 1,309,184 ArxDemo\Setup_Deutsch.msi A R 1,708,856 34ec21c0 ArxDemo\instmsi.exe A R 1,822,520 e5563f20 ArxDemo\instmsiw.exe ... Scan time.............[ 551.80] Seconds (551801 ms) Total files...........[ 35] Files Total size............[ 558,468,227] Bytes Dirlist Text CRC32....[ 0032ED44] ____________________________________________________________ ... --- snip --- Forget the scan time, I was debugging at this place ;-) What makes things complicated is that additionally to per-file CRC32 checksums there is also a CRC32 for the whole in-memory folder listing content generated (see snippet) -> "Dirlist Text CRC32" (in snippet the address is printed, not the value itself). That overall checksum didn't match the internal hard-coded one. One problem is that Wine adds FILE_ATTRIBUTE_ARCHIVE by default to each file info entry. Source: http://source.winehq.org/git/wine.git/blob/c7cb3e6cb21598281cf2b00b2ccd8323… This is breaks the overall checksum (file entries get "A" added). The file entries have to have only FILE_ATTRIBUTE_READONLY set -> "R" (reside on CDROM). If FILE_ATTRIBUTE_ARCHIVE is omitted (and a second bug is worked around) the verification process exits with exit code 0x777 which allows the main installer to successfully finish. --- There is another problem, a bug in the verification tool that unfortunately prevents a "full" fix for this installer. One of the file CRC32 on CD3 gets miscalculated ... It took me some hours to find out this brain damage after successfully pinning down the first problem and wondering why the overall checksum still didn't match. --- snip --- ... 0024:Call KERNEL32.CreateFileA(0032d734 "D:\\arxdemo\\setup.exe",80000000,00000001,00000000,00000003,00000080,00000000) ret=00d86dfe 0024:Ret KERNEL32.CreateFileA() retval=000000a0 ret=00d86dfe 0024:Call KERNEL32.GetFileSize(000000a0,00000000) ret=00d87385 0024:Ret KERNEL32.GetFileSize() retval=00007c00 ret=00d87385 0024:Call ntdll.RtlAllocateHeap(00fc0000,00000000,00010010) ret=00be379b 0024:Ret ntdll.RtlAllocateHeap() retval=00fc5238 ret=00be379b 0024:Call KERNEL32.ReadFile(000000a0,00fc5238,00010000,00bfd464,00000000) ret=00d8725a 0024:Ret KERNEL32.ReadFile() retval=00000001 ret=00d8725a 0024:Call ntdll.RtlFreeHeap(00fc0000,00000000,00fc5238) ret=00be3cea 0024:Ret ntdll.RtlFreeHeap() retval=00000001 ret=00be3cea 0024:Call KERNEL32.CloseHandle(000000a0) ret=00d8743a 0024:Ret KERNEL32.CloseHandle() retval=00000001 ret=00d8743a --- snip --- "D:\\arxdemo\\setup.exe" is the culprit. The file size is 31744 bytes. The tool allocates a fixed 65552 byte buffer to read file content in and calculate checksum on (actually 65536 bytes are used for checksumming). Prior to calculating file CRC32 for "D:\\arxdemo\\setup.exe", the 350 MiB "D:\\gothic2-setup.w03" was checksummed in 0x10000 byte chunks. It had the same heap chunk address 0x00fc5238 which was later reused for "D:\\arxdemo\\setup.exe" checksum calculation. --- snip --- 0024:Call KERNEL32.CreateFileA(0032dd20 "D:\\gothic2-setup.w03",80000000,00000001,00000000,00000003,00000080,00000000) ret=00d86dfe 0024:Ret KERNEL32.CreateFileA() retval=0000009c ret=00d86dfe 0024:Call KERNEL32.GetFileSize(0000009c,00000000) ret=00d87385 0024:Ret KERNEL32.GetFileSize() retval=159fbbcc ret=00d87385 0024:Call ntdll.RtlAllocateHeap(00fc0000,00000000,00010010) ret=00be379b 0024:Ret ntdll.RtlAllocateHeap() retval=00fc5238 ret=00be379b 0024:Call KERNEL32.ReadFile(0000009c,00fc5238,00010000,00bfd464,00000000) ret=00d8725a 0024:Ret KERNEL32.ReadFile() retval=00000001 ret=00d8725a ... 0024:Call KERNEL32.ReadFile(0000009c,00fc5238,00010000,00bfd464,00000000) ret=00d8725a 0024:Ret KERNEL32.ReadFile() retval=00000001 ret=00d8725a 0024:Call KERNEL32.ReadFile(0000009c,00fc5238,00008480,00bfd464,00000000) ret=00d8725a 0024:Ret KERNEL32.ReadFile() retval=00000001 ret=00d8725a 0024:Call KERNEL32.ReadFile(0000009c,00fc5238,00008480,00bfd464,00000000) ret=00d8725a 0024:Ret KERNEL32.ReadFile() retval=00000001 ret=00d8725a 0024:Call ntdll.RtlFreeHeap(00fc0000,00000000,00fc5238) ret=00be3cea 0024:Ret ntdll.RtlFreeHeap() retval=00000001 ret=00be3cea ... --- snip --- Because the heap chunk was reused and the buffer was fully filled from previous run, the read file operation for "D:\\arxdemo\\setup.exe" only initialized the first 31744 bytes. The checksum is done on 65536 bytes of buffer which includes garbage/leftover already present. Well, the developers didn't bother to pass HEAP_ZERO_MEMORY to RtlAllocateHeap() or explicit memset(ptr, 0, nbytes). The tool "works" in Windows most likely due to different heap manager implementation/usage or maybe application shims. They put some effort into anti-debugging/hacking/copying and rambled about piracy in hidden messages (found while debugging) ... and yet managed to put in such bugs. You can hack/patch ntdll.dll RtlAllocateHeap() -> forcing flags |= HEAP_ZERO_MEMORY to verify the installer really works after fixing the first problem. 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 5

[Bug 30421] New: obscure GDI Message Queue + Focus bug
by wine-bugs＠winehq.org 05 Sep '19

05 Sep '19

http://bugs.winehq.org/show_bug.cgi?id=30421 Bug #: 30421 Summary: obscure GDI Message Queue + Focus bug Product: Wine Version: 1.3.37 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lkcl(a)lkcl.net Classification: Unclassified ok, this is a rather obscure bug that i've been experiencing for quite some time, but hadn't got a handle on any of the functions being used, so couldn't really provide a useful report. as i am now running pyjamas-desktop which uses python ctypes bindings to gdi32 (!!) i can now provide useful feedback. please see the following file, the GetMessage loop towards the end: http://pyjs.org/pygit/#file=pyjd/mshtml.py&id=0d4b6787d01c3d90f2c8801c5c4c4… basically, the repro is as follows: * run wine python.exe Hello.py (an example) * move the mouse out of the GDI32 (IWebBrowser2 OLE control) window * move the mouse into the xterm where wine was fired up * press ctrl-c now, _normally_, under xp, nothing happens... and nothing _should_ happen... ever. ctrl-c should be *completely* ignored. but, continue: * move the mouse _back_ into the GDI32 window * the program exits the exit should *not* be happening when the mouse is moved back. which brings me on to the various experiences that i've had with focus issues, especially dialog boxes. maybe this is because i'm using fvwm2, but the behaviour of focus on dialog boxes and especially inputboxes within dialog boxes is _very_ erratic. the mouse is needed to be moved into the parent window in order sometimes for keyboard focus to arrive on the inputbox within the dialog box! sometimes that doesn't work, and the mouse is required to be moved onto the bar at the top of the parent window (the one with the title - the x-windows / fvwm window bar!) all very odd, and probably a different bug, but hey :) -- 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 47692] New: RealmWorks can not extend a Field after it has been saved ( Context_CC_ContextCallback?)
by wine-bugs＠winehq.org 05 Sep '19

05 Sep '19

https://bugs.winehq.org/show_bug.cgi?id=47692 Bug ID: 47692 Summary: RealmWorks can not extend a Field after it has been saved (Context_CC_ContextCallback?) Product: Wine Version: 4.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: legine(a)gmx.net Distribution: --- Despite similar Reports I decided to write an own description. The behavior is specific to Realm Works. And not really compare able to 38940 or 21483since I have no crash. I can work on. Background: Realmworks is a special Documentation tool for Role playing Adventures and Campaigns. Basically you enter information to a topic and the tool can link and extend Information very easily. It is a great tool for Game mastering Pen & Paper Role playing games. Issue Description: 1) create an Object where you want to edit something 2) edit a text field. Just enter something. 3) save the object. 4) reopen the Object for extending the text field (if you want to fix something before it is all fine) the Fronted prints only boxes. In the Log I see after a short delay following message: 002c:fixme:ole:Context_CC_ContextCallback (001B0430/001B0434)->(017481F0, 042AFB68, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 00000000) 002c:fixme:ole:Context_CC_ContextCallback (001B0430/001B0434)->(017481F0, 042AFAEC, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, 00000000) 0168:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet 0177:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet 0170:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet An open and close is logged with 0009:fixme:ole:snapshot_QueryGetData (118ABAF0, 0034F198 {cf c075 ptd 00000000 aspect 1 lindex -1 tymed 75}) Thanks for all your work. -- 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 47638] New: Newsleecher 8.0 Beta 1 - will not start with win7+dxgi enabled ( workaround as winxp)
by wine-bugs＠winehq.org 04 Sep '19

04 Sep '19

https://bugs.winehq.org/show_bug.cgi?id=47638 Bug ID: 47638 Summary: Newsleecher 8.0 Beta 1 - will not start with win7+dxgi enabled (workaround as winxp) Product: Wine Version: 4.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bob.mt.wya(a)gmail.com Distribution: --- Created attachment 65073 --> https://bugs.winehq.org/attachment.cgi?id=65073 wine-vanilla-4.14_newsleecher_8_log.txt The application fails to start in Windows 7 mode, hanging on the splash screen (and segfaulting in the terminal). No backtrace is generated. Using the workarounds: winetricks winxp wine reg.exe ADD "HKEY_CURRENT_USER\Software\Wine\DllOverrides" "/v" "dxgi" "/t" "REG_SZ" "/d" "" enables the application to start normally. I haven't tested further, but it appears to run OK, with these workarounds. Both workarounds are necessary. The application attempts to load d3d10 / d3d11 libraries - although it only generates a regular 2D gui window. Debug log was generated with: export WINEDEBUG=+timestamp,+tid,+loaddll,+module,+seh,+wgl,+d3d,+d3d10,+d3d10core,+d3d11,+dxgi -- 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 47674] New: Changing current system locale for non-Unicode programs ( Maktabah Shamela - arabic language not showing properly)
by wine-bugs＠winehq.org 04 Sep '19

04 Sep '19

https://bugs.winehq.org/show_bug.cgi?id=47674 Bug ID: 47674 Summary: Changing current system locale for non-Unicode programs (Maktabah Shamela - arabic language not showing properly) Product: Wine Version: 1.8.6 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: svet6ma(a)gmail.com Created attachment 65127 --> https://bugs.winehq.org/attachment.cgi?id=65127 normal Greeting you. Im using MacOS High Sierra. Second day.. I have installed Wine 1.8.6 (then tried 4.0.1) I need this for executing program named Maktabah Shamela which is also in your appDB: https://appdb.winehq.org/objectManager.php?sClass=application&iId=19409 APP Launched with NO Problems. BUT. It doesn't recognize arabic letters properly. So you can look there in detailed informations about application (click 3.64) there are test results. You can see Workarounds for application there: ______________________________ First of all, to get it display Arabic language properly, follow the instructions here : https://abuhirr.wordpress.com/2013/12/20/syamilah/ Notice that you may have to uncomment the line "ar_SA.UTF-8" in you /etc/locale.gen and to run "sudo locale-gen".) Run "winetricks wsh57 vcrun6". _______________________________ So. These workarounds as I understand all for linux/ubuntu. But I cant do it on my Mac. Generally this application has problem with unicode. In WINDOWS it requires changing current language for non-unicode programs to Arabic (Saudi Arabia). So that UTF-8 will read properly. I have tried many ways to configure this. winetricks - allfonts / corefonts; DOS > intl.cp configuration to ar-SA; registry> machine/system/currentcontrolset/control/nls/locale.. or codepage.. or USER/control panel/international/local.. tried to ad .ttf files manually; changed safari/view/unicode/ to utf-8 and etc.. forget how much. Working about more than 10 hours. Nothing WORKS. I will add the proper view of app, and the one is in my Wine/MacOS. Any ideas? -- 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 47012] New: Photoshop Installer crashes after showing blank window
by wine-bugs＠winehq.org 02 Sep '19

02 Sep '19

https://bugs.winehq.org/show_bug.cgi?id=47012 Bug ID: 47012 Summary: Photoshop Installer crashes after showing blank window Product: Wine Version: 4.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: funtimeschaos(a)rocketmail.com Distribution: --- Created attachment 64171 --> https://bugs.winehq.org/attachment.cgi?id=64171 wine4.5-staging output According to the AppDB it is a known problem that PS cannot be installed and a complete installation needs to be copied from elsewhere, but couldn't find a bug report on the matter attached to the app or anything that looks like a dupe, so I'll submit this one. Tested with 4.5 staging. Logs attached. -- 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 19182] New: Allow to completely disable MIME-type and application integration
by wine-bugs＠winehq.org 01 Sep '19

01 Sep '19

http://bugs.winehq.org/show_bug.cgi?id=19182 Summary: Allow to completely disable MIME-type and application integration Product: Wine Version: 1.1.25 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: diafero(a)arcor.de Note: I could not find a component "winemenubilder" which is why I selected "-unknown". It would be great to have a way to tell wine not to create a whole bunch of files across the .config and .local directories. I don't want any mime-type which is registered by a windows application run through wine to reflect on my system - if I really want to use wine to open a certain filetype (which never happened so far) I will do that manually. Nor do I want all the unnecessary start menu entries to be added to my KDE menu - they end up in the wrong category anyway. I like to have the control of creating these entries myself. For the menu it worked fine to simply remove the "Wine" menu directory with the menu editor. The annoying files still got created, but they were ignored. However now wine started to spam my mime directory, too, and it constantly re-creates the files in there - a really annoying behaviour. This not only leads to the danger of me accidentally starting wine without wanting to do so, it also drives some applications crazy (for example the KDE screenshot application no longer recognizes ".jpg" to be a JPEG extension since wine added .jfif). I understand that many people want wine to just magically integrate into their Linux environment, but there are also people like me who switched to Linux because they like to have control, and Windows often prefers its own preferences over the user's. Wine should really not bring that to Linux, or it will get as annoying as Windows is. If I could not patch wine myself to no longer create these files, I had no way to stop all these mime types from being added, no configuration panel to remove them, nothing. I do not even know which of my many WINEPREFIXes created the files. -- 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 102

[Bug 46723] New: Kholat stucks and shows a black screen instead of playing video
by wine-bugs＠winehq.org 31 Aug '19

31 Aug '19

https://bugs.winehq.org/show_bug.cgi?id=46723 Bug ID: 46723 Summary: Kholat stucks and shows a black screen instead of playing video Product: Wine Version: 4.2 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- fixme:mfplat:mfeventqueue_BeginGetEvent 0x6ef6c20, 0x80ca320, (nil) fixme:mfplat:mfsourceresolver_CreateObjectFromURL (0x6ef8b60)->(L"../../../Kholat/Content/Movies/Startup.mp4", 0x1, (nil), 0x241fb2c, 0x241fb28): stub fixme:mfplat:mfsession_Close (0x6ef6540) Disabling mfplat is a workaround. wine-4.2-195-gf784cabd34 -- 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