wine-bugs July 2018

wine-bugs@winehq.org

1 participants
7954 discussions

[Bug 33743] New: Fullscreen with two monitors of different size
by wine-bugs＠winehq.org 08 Mar '25

08 Mar '25

http://bugs.winehq.org/show_bug.cgi?id=33743 Bug #: 33743 Summary: Fullscreen with two monitors of different size Product: Wine Version: 1.4.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: enicon(a)gmail.com Classification: Unclassified Created attachment 44681 --> http://bugs.winehq.org/attachment.cgi?id=44681 Fullscreen Word window in the biggest monitor (1440x900) is clipped On Linux Mint (both Nadia and Maya) on a laptop with build-in monitor 1024x768 and external monitor (now 1440x900). On the biggest monitor, wine application don't go fullscreen correctly, vertically size seems to be limited by the size of the smallest monitor. In my example if I fullscreen WORD I get some of the UI missing and a desktop background stripe in the lower part of the monitor. Notice that if I don't use fullscreen but drag the windows border I cat enlarge word on all the surface of the monitor and all the ui is correctly displayed. -- 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.

2 9

[Bug 40523] New: legrand xlpro3 400 : unable to insert a pictogram
by wine-bugs＠winehq.org 07 Mar '25

07 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=40523 Bug ID: 40523 Summary: legrand xlpro3 400 : unable to insert a pictogram Product: Wine Version: 1.9.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)winehq.org Reporter: tomlohave(a)gmail.com Distribution: --- Created attachment 54340 --> https://bugs.winehq.org/attachment.cgi?id=54340 inserting a pictogram inserting a pictogram (emf file) does not work logs show : fixme:olepicture:OLEPictureImpl_Save (0x851a938,0x33de48,0),PICTYPE_ENHMETAFILE not implemented! err:olepicture:OLEPictureImpl_Load Failure while reading picture header (hr is 0, nread is 4). fixme:olepicture:OLEPictureImpl_Save (0xdccff38,0x33def4,1), [unknown type] not implemented! and logs are spammed with this line : err:olepicture:OLEPictureImpl_Load Failure while reading picture header (hr is 0, nread is 4). -- 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.

2 15

[Bug 45119] New: Multiple applications from Google sandbox-attacksurface-analysis-tools ( targeting native API) need 'ntdll.NtGetNextProcess' implementation
by wine-bugs＠winehq.org 07 Mar '25

07 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=45119 Bug ID: 45119 Summary: Multiple applications from Google sandbox-attacksurface-analysis-tools (targeting native API) need 'ntdll.NtGetNextProcess' implementation Product: Wine Version: 3.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, required by various .NET-based apps from https://github.com/google/sandbox-attacksurface-analysis-tools --- quote --- sandbox-attacksurface-analysis-tools (c) Google Inc. 2015, 2016, 2017, 2018 Developed by James Forshaw This is a small suite of tools to test various properties of sandboxes on Windows. Many of the checking tools take a -p flag which is used to specify the PID of a sandboxed process. The tool will impersonate the token of that process and determine what access is allowed from that location. Also it's recommended to run these tools as an administrator or local system to ensure the system can be appropriately enumerated. CheckExeManifest: Check for specific executable manifest flags. CheckNetworkAccess: Check access to network stack. NewProcessFromToken: Create a new process based on existing token. TokenView: View and manipulate various process token values. NtApiDotNet: A basic managed library to access NT system calls and objects. NtObjectManager: A powershell module which uses NtApiDotNet to expose the NT object manager. ViewSecurityDescriptor: View the security descriptor from an SDDL string or an inherited object. --- quote --- It's actually a pretty neat "testsuite" for native API, Wine could benefit from it. I've already found 20+ bugs within one hour of playing with this (missing exports, stubs, incomplete + incorrect impl. etc.). Will create more tickets as time/mood permits ;-) Prerequisite: * 32-bit WINEPREFIX * .NET Framework 4.5 -> 'winetricks -q dotnet45' --- snip --- $ wine ./TokenViewer.exe ... Unhandled Exception: System.EntryPointNotFoundException: Unable to find an entry point named 'NtGetNextProcess' in DLL 'ntdll.dll'. at NtApiDotNet.NtSystemCalls.NtGetNextProcess(SafeKernelObjectHandle ProcessHandle, ProcessAccessRights DesiredAccess, AttributeFlags HandleAttributes, Int32 Flags, SafeKernelObjectHandle& NewProcessHandle) at NtApiDotNet.NtProcess.GetFirstProcess(ProcessAccessRights desired_access) at NtApiDotNet.NtProcess.GetProcesses(ProcessAccessRights desired_access, Boolean from_system_info) at TokenViewer.MainForm.RefreshProcessList(String filter, Boolean hideUnrestricted) at TokenViewer.MainForm..ctor() at TokenViewer.Program.Main(String[] args) --- snip --- https://github.com/mirror/processhacker/blob/master/2.x/trunk/phlib/include… --- snip --- #if !(PHNT_VERSION >= PHNT_WS03) typedef NTSTATUS (NTAPI *_NtGetNextProcess)( _In_ HANDLE ProcessHandle, _In_ ACCESS_MASK DesiredAccess, _In_ ULONG HandleAttributes, _In_ ULONG Flags, _Out_ PHANDLE NewProcessHandle ); ... --- snip --- $ sha1sum Release-v1.1.14.7z 8cd7991e675a995a3d67ef0aca2a8bf0e1512f6a Release-v1.1.14.7z $ du -sh Release-v1.1.14.7z 384K Release-v1.1.14.7z $ wine --version wine-3.7-50-g8dca6c35e1 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.

2 7

[Bug 41427] New: [Game Maker Studio - Android][Subst.exe] - not working
by wine-bugs＠winehq.org 07 Mar '25

07 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=41427 Bug ID: 41427 Summary: [Game Maker Studio - Android][Subst.exe] - not working Product: Wine Version: 1.9.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: thunderstormpolska(a)o2.pl Distribution: Debian Hello. subst.exe is (from Windows) probably something like Linux mount or Winecfg Disks, but it's not available in Wine. I tried to borrow it from Windows XP, but it doesn't work. Game maker try to create "virtual disk" to Y: using subst.exe, but subst doesn't 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.

2 14

[Bug 38879] New: wbemprox fill_videocontroller calls are expensive
by wine-bugs＠winehq.org 07 Mar '25

07 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=38879 Bug ID: 38879 Summary: wbemprox fill_videocontroller calls are expensive Product: Wine Version: 1.7.41 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)winehq.org Reporter: c10ud.dev(a)gmail.com Distribution: --- Created attachment 51812 --> https://bugs.winehq.org/attachment.cgi?id=51812 wbemprox: cache videocontroller queries Specifically League of Legends likes to continuously ask for video controller specs while in game (every 4 seconds or so). On my (old?) box this leads to a pretty big framedrop (~15fps when capped at 60) due to dxgi being initialized every time (and thus wined3d) by the fill_videocontroller function. The proposed solution caches results for subsequent calls, but I'm not sure about the implications (i.e. do we expect any of those fields to change in the lifespan of a wine application?) Comments welcome Greets -- 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.

2 13

[Bug 43894] New: FTDI Vinculum II IDE V2.0.2-SP2 some of the toolbar tabs are not visible
by wine-bugs＠winehq.org 07 Mar '25

07 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=43894 Bug ID: 43894 Summary: FTDI Vinculum II IDE V2.0.2-SP2 some of the toolbar tabs are not visible Product: Wine Version: 2.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: skenton(a)ou.edu Distribution: --- After working around bug 38350 the IDE opens and functions but some of the toolbar tabs are not visible. Specifically those on the blue line with the help button on the far right that is between the two lines of icons at the top of the IDE. They normally select which toolbar to show for edit, build, debug, program etc. Clicking where they are known to be reveals a different color rectangle but no text. -- 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.

2 6

[Bug 25682] New: Super Crate Box runs slowly
by wine-bugs＠winehq.org 05 Mar '25

05 Mar '25

http://bugs.winehq.org/show_bug.cgi?id=25682 Summary: Super Crate Box runs slowly Product: Wine Version: 1.3.10 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: madewokherd(a)gmail.com On Wine, Super Crate Box runs slowly enough to actually be playable. While this is arguably an improvement, we should match the Windows behavior which is to run unplayably fast. -- 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.

2 13

[Bug 34108] New: Rally Trophy: Controller configuration is very buggy
by wine-bugs＠winehq.org 04 Mar '25

04 Mar '25

http://bugs.winehq.org/show_bug.cgi?id=34108 Bug #: 34108 Summary: Rally Trophy: Controller configuration is very buggy Product: Wine Version: 1.6 Platform: x86-64 URL: http://games.softpedia.com/get/Games-Demo/Rally-Trophy .shtml OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput AssignedTo: wine-bugs(a)winehq.org ReportedBy: jettis(a)gmail.com Classification: Unclassified Created attachment 45353 --> http://bugs.winehq.org/attachment.cgi?id=45353 Rally Trophy log trace+dinput Rally Trophy uses DirectInput's device configuration window. There are some bugs that make device configuration difficult and for example a racing wheel impossible to use. Device configuration usually doesn't show the currently mapped keys for keyboard especially when a racing wheel is connected. If it shows they are only default keys and not the currently mapped keys. If a function is already mapped to a key by you, you can't change it to an another key anymore. For example you set 'shift up' to 's' key and go to play, then you go back to device configuration and set 'shift up' to 'd' key and again go to play. You will notice that 'd' key does not change a gear. In full version of Rally Trophy the key mappings are saved, but in Rally Trophy Demo in wine they are not. The keys are always the default ones when you start the game. In Windows you can select a player (Pelaaja 1/Player 1) for the device when you want to use it. Wine does not see the player and shows only a blank list, so you can't get a racing wheel in to use. However a racing wheel becomes usable if keyboard and mouse enumeration is deleted from IDirectInput8AImpl_EnumDevicesBySemantics from wine's code. Logs are made with these steps: 1. Start the game 2. Go to device configuration 3. Set key 's' to 'shift up' 4. Go to in game 5. Close the game with alt+f4 A racing wheel is connected when logging. Tested wine version is the latest git. Demo can be downloaded from: http://games.softpedia.com/get/Games-Demo/Rally-Trophy.shtml -- 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.

2 20

[Bug 44863] New: Performance regression in Prince of Persia 3D
by wine-bugs＠winehq.org 04 Mar '25

04 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=44863 Bug ID: 44863 Summary: Performance regression in Prince of Persia 3D Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: stefan(a)codeweavers.com Distribution: --- Prince of Persia 3D's performance went from perfectly smooth to about 0.5 fps. I suspect 0b92a6fba7a6e60c6ff1a3729a3b21019c2df0ce is to blame, but I have not run a regression test yet. The problem is that the game creates a rather large (2MB) D3DVBCAPS_SYSTEMMEMORY, maps it (the entire buffer due to API limitations), writes a handful of vertices and draws a handful of vertices. Currently wined3d uploads the entire 2MB, evicts the sysmem copy and downloads it from the GPU every map / unmap / draw cycle. The most obvious performance fix is not to create a VBO. Doing this restores the performance, but questions remain. On startup, the game writes "NetImmerse D3DDriver Info: Hardware supports system memory textures" and "NetImmerse D3DDriver Info: No AGP support detected". The first info seems wrong, so it is possible that the game enters a codepath it does not choose on Windows. Not creating a VBO is not an option on Core Contexts, so I investigated what's going wrong with the PBO codepath on. First of all, evicting the sysmem copy seems like a bad choice. It happens because ddraw buffers are not marked dynamic. We may want to chance this. The game uses d3d3, so there's no DDLOCK_DISCARDCONTENTS. The game passes DDLOCK_WAIT | DDLOCK_WRITEONLY to IDirect3DVertexBuffer::Lock. Commenting out the eviction call improves performance quite a bit, but it is still noticeably slow. wined3d_buffer_map maps through heap_memory instead of glMapBuffer because of the "(flags & WINED3D_MAP_WRITE) && !(flags & (WINED3D_MAP_NOOVERWRITE | WINED3D_MAP_DISCARD))" condition. Removing this condition uses glMapBuffer, but does not improve performance. It seems the large glMapBuffer is still slow, at least on OSX with legacy contexts. So there are a few questions that need to be answered: *) Is the game using a broken codepath? *) Write tests for sysmem buffers *) Consider making all d3d3 buffers dynamic *) Test if the glMapBuffer path is fast on Linux *) Investigate if Core Contexts + GL_ARB_buffer_storage help on OSX. -- 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.

2 24

[Bug 40495] New: Impossible to function at 64 bit on FreeBSD
by wine-bugs＠winehq.org 02 Mar '25

02 Mar '25

https://bugs.winehq.org/show_bug.cgi?id=40495 Bug ID: 40495 Summary: Impossible to function at 64 bit on FreeBSD Product: Wine Version: 1.7.46 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexandrosperdikomatis(a)gmail.com Created attachment 54269 --> https://bugs.winehq.org/attachment.cgi?id=54269 the regular backtrace report I've compiled wine64 several times in many ways at FreeBSD. 32 bit version always works fine. This is the port emulators/wine-devel from RELEASE ports collection at FreeBSD 10.2 Application tried was Wow-64.exe I am really disappointed with wine64 at FreeBSD. On Linux it flies. -- 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.

2 2

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 July 2018