https://bugs.winehq.org/show_bug.cgi?id=45756
Bug ID: 45756
Summary: Button not clickable when dpi setting changed in
Office 2007 Installer
Product: Wine
Version: 3.15
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: ulrich.gemkow(a)ikr.uni-stuttgart.de
Distribution: ---
After upgrading from wine 3.14 to wine 3.15 (self-compiled, 32-bit-only) the
push buttons in the office 2007 installer are no longer "clickable".
When pushing them with the mouse, nothing happens. Using the keyboard to "push"
the buttons works as before. Sometimes the mouse pointer is not even visible
inside the installer window.
This only happens when changing the screen resolution in winecfg (i.e. to 168
dpi). The windows version is set to Windows XP
A bisect shows this commit as the first bad commit:
commit 2068b73db5e19e1ce3b54b2a8ecb5a5b99ea19b5
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Aug 27 14:02:43 2018 +0200
user32: Process hardware messages in physical coordinates.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39113
Bug ID: 39113
Summary: SimplePC_SC.exe does not work
Product: Wine
Version: unspecified
Hardware: x86
URL: http://downloads.acs.com.hk/utility-tools/en/TOL-PCSC.
zip
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winscard
Assignee: wine-bugs(a)winehq.org
Reporter: vincent.hardy.be(a)gmail.com
Distribution: ---
Created attachment 52115
--> https://bugs.winehq.org/attachment.cgi?id=52115
screenshot
SimplePC_SC is a programme that tests easily the basic functions of winscard
with any smartcard.
I file this bug in the hope that a friendly developer starts a real
implementation of winscard.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=53728
Bug ID: 53728
Summary: "Escape from Tarkov" requires
"DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME" in
"DisplayConfigGetDeviceInfo" stub
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: vinni5.2001(a)web.de
Distribution: ---
Created attachment 73161
--> https://bugs.winehq.org/attachment.cgi?id=73161
Attachments for this report.
The video game "Escape from Tarkov" requires the
"DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME" type to be implemented in the
"DisplayConfigGetDeviceInfo" function (dlls/user32/sysparams.c).
The game uses that to determine monitor names to list in the ingame settings
menu.
When it first introduced the use of that function, the lack of it in wine made
the whole menu freeze, forcing you to kill the game. That freeze was worked
around by the game developers on their end, since it also affected some Windows
users, but parts of the issue still remain when running the game in wine.
Monitor names in the monitor list in the settings menu are simply blank, making
it hard to figure out which entry in the list corresponds to which monitor. See
"eft_monitors_blank.png" in "attachments.tar.gz" for reference.
Creating a quick and dirty patch to make wine return a string and pretend the
function was executed successfully confirms it is using that function to get
monitor names and the returned string shows up in the list. See
"eft_monitors_names.png" and "dirty-monitor-name-workaround.patch" in
"attachments.tar.gz" for reference.
I should mention that in case other people wanna test the game, it is not free
and makes use of the BattlEye anticheat software, so in order to launch the
game with wine, it requires staging, a patch to load the Proton BattlEye
Runtime (found here, for example:
https://github.com/Frogging-Family/wine-tkg-git/tree/master/wine-tkg-git/wi…),
as well as the Proton BattlEye Runtime itself (can be found and installed via
Steam by Valve) and the necessary environment variable that points to the
Proton BattlEye Runtime ("PROTON_BATTLEYE_RUNTIME"="/path/to/runtime"). It also
needs "corefonts", "vcrun2019" and "dotnet48" installed via winetricks.
I hope those requirements won't prevent this issue from being looked into, but
if they do, I apologize. I was able to put together the quick and dirty patch
to confirm it is indeed just a missing or incomplete function, however I lack
the programming skills and low-level wine/windows knowledge to implement it
properly.
Thank you!
--
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.
https://bugs.winehq.org/show_bug.cgi?id=53176
Bug ID: 53176
Summary: KeePassXC needs
Windows.Security.Credentials.KeyCredentialManager
(UWP)
Product: Wine
Version: 7.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: mk939(a)ymail.com
Distribution: ---
Created attachment 72622
--> https://bugs.winehq.org/attachment.cgi?id=72622
stdout and stderr from the terminal while launching the application
KeePassXC 2.7.1 (64-bit, Windows) can no longer be started due to a new Windows
Hello feature. Older versions prior to Feb 2022 will work as expected.
I reproduced this issue on two different machines, each with Wine 7.11
(vanilla).
Source code:
https://github.com/keepassxreboot/keepassxc/blob/develop/src/winhello/Windo…
Specifically, creating a stub for `IsSupportedAsync()` might suffice to disable
the feature for this application, assuming a proper implementation on their
side:
https://github.com/keepassxreboot/keepassxc/blob/develop/src/winhello/Windo…
PS: The error mentions "combase", but is not an available choice in the bug
report selection box. I am sorry if the selected component is wrong.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54584
Bug ID: 54584
Summary: kernel32:locale - The NtGetNlsSectionPtr() test fails
on Windows 11
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
kernel32:locale - The NtGetNlsSectionPtr() test fails on Windows 11:
locale.c:4978: Test failed: 14: failed 0
See https://test.winehq.org/data/patterns.html#kernel32:locale
This means Windows 11 supports a new type of NLS section (14). Also
NtGetNlsSectionPtr() returns success so presumably that section type does not
take an id parameter.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54583
Bug ID: 54583
Summary: kernel32:locale - The non-breaking space
GetNumberFormatEx() test fails on Windows 11
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
kernel32:locale - The non-breaking space GetNumberFormatEx() test fails on
Windows 11:
locale.c:1820: Test failed: Expected L"-12\00a0345,00", got L"-12\202f345,00"
See https://test.winehq.org/data/patterns.html#kernel32:locale
So Windows 11 returns a narrow non-breaking space instead of a 'plain'
non-breaking space separator when using the French format.
The narrow non-breaking space is probably more correct.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54534
Bug ID: 54534
Summary: dbghelp:dbghelp - The test_loaded_modules()
enumeration fails on Windows 10 1607
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: dbghelp
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
dbghelp:dbghelp - The test_loaded_modules() enumeration fails on Windows 10
1607:
dbghelp.c:517: Test failed: SymLoadModuleExW failed on
C:\WINDOWS\System32\bcryptPrimitives.dll: 0
See https://test.winehq.org/data/patterns.html#dbghelp:dbghelp
This is the only Windows 10 version which fails.
A bisect confirms that this failure was introduced by the commit below:
8be5c10ff893a22330ad94ae18dfb5fa497b09fd
Author: Eric Pouech <eric.pouech(a)gmail.com>
AuthorDate: Thu Feb 16 10:48:53 2023 +0100
dbghelp/tests: Add tests for 'module' name in EnumLoadedModules() callback.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
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.
https://bugs.winehq.org/show_bug.cgi?id=43224
Bug ID: 43224
Summary: Freelist scan can result in O(n) time when allocating
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: ranma42(a)gmail.com
Distribution: ---
Created attachment 58517
--> https://bugs.winehq.org/attachment.cgi?id=58517
Micro-benchmark that shows the degenerate behaviour
The heap implementation in ntdll can be very inefficient for some allocation
patterns.
Specifically, it is possible that a freelist contains thousands of entries of a
given size and it is scanned while looking for a bigger entry, that will not
fit in any of those.
This is demonstrated by the attached program. It accepts a size as an argument
and will allocate 1000000 elements of that size, deallocate half of them (the
"even" ones), then allocate 1000 elements that are just one bit bigger.
For most sizes the program terminates in milliseconds, but in my environment it
takes several seconds for sizes 16, 32, 48, 64, 80, 88, 96, 112, 120, 128.
A possible workaround (that I had implemented in the past, for short-lived
applications) is to allocate from a freelist whose entries are all at least as
big as the block that is being allocated, but that can cause inefficient memory
usage.
I noticed that wine includes an implementation of a red-black tree.
Would it make sense to organise the free entries as lists in such a tree?
That should ensure O(log N) in the worst case.
If performance is a concern, it might be possible to use "direct" freelists for
small sizes (ensuring that all of the alignment-compatible sizes are covered)
and use a tree for bigger sizes.
I am willing to work on this, but I need some directions on what is the best
path forward (namely, if we should prefer the memory-inefficient but simpler
approach of just allocating from "bigger" freelists or if the tree approach is
the desired one).
The bug https://bugs.winehq.org/show_bug.cgi?id=37773 might be related.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=37146
Bug ID: 37146
Summary: Untis 2015: Crashes while starting
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: schutthuffe(a)web.de
Created attachment 49371
--> https://bugs.winehq.org/attachment.cgi?id=49371
Report generated by wine
Installing Untis 2015 seemed to work. Trying to start the program, the
following message popped up: "Im Programm untis.exe traten schwerwiegende
Fehler auf und es muss beendet werden. Wir entschuldigen uns für die
Unannehmlichkeit." The following report is 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.