https://bugs.winehq.org/show_bug.cgi?id=54149
Bug ID: 54149
Summary: shlwapi:ordinal - test_SHFormatDateTimeA() fails on
the mixed locales configuration
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: shlwapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
test_SHFormatDateTimeA() fails on the mixed locales configuration:
ordinal.c:1765: Test failed: expected (mercredi 14 décembre 2022), got
(mercredi 14 decembre 2022)
ordinal.c:1773: Test failed: expected (mercredi 14 décembre 2022), got
(mercredi 14 decembre 2022)
ordinal.c:1787: Test failed: expected (mercredi 14 décembre 2022) got (mercredi
14 decembre 2022) for date part
ordinal.c:1801: Test failed: expected (mercredi 14 décembre 2022) got (mercredi
14 decembre 2022) for date part
See https://test.winehq.org/data/patterns.html#shlwapi:ordinal
All was fine until 2022-12-09. Then on the 11th I let the TestBot rebuild the
snapshot [1] to ensure that Internet time synchronization would be disabled to
fix random failures in other tests. And on the 12th this test started failing:
the date lost its e-acute!
Yet the WineTest system information shows that none of the locale settings
changed, not even the code page. Before and after they are:
SystemDefaultLCID 0411
UserDefaultLCID 040c
ThreadLocale 0411
SystemPreferredUILanguages 0412,0409
UserDefaultUILanguage 0412
ThreadUILanguage 0412
Country 231
ACP 932
The test did not change and the binary from the 9th has the same failure. So it
is some obscure Windows setting that changed for some unknown reason.
Furthermore given that the code page is 932 I would expect the plain 'e' to be
the more correct result. Unfortunately there is no record of what the result
was before the test started failing. Is it possible for SHFormatDateTimeA() and
GetDateFormatA() to use different code pages?
[1] It goes like this: that VM has a 'langs' powered-off snapshot with all the
locales installed. This snapshot has not changed since 2022-04-24. From this
the TestBot produces the 'langs-mx-MX-live' live snapshot using LibvirtTool.pl
and SetWinLocale to change the locale settings.
--
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=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=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.
https://bugs.winehq.org/show_bug.cgi?id=54338
Bug ID: 54338
Summary: Swift crashes due unimplemented
QueryUnbiasedInterruptTimePrecise function
Product: Wine
Version: 8.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mikrutrafal(a)protonmail.com
Distribution: ---
Swift language after installing, crashes with this message
```
wine: Call from 000000017002FA08 to unimplemented function
api-ms-win-core-realtime-l1-1-1.dll.QueryUnbiasedInterruptTimePrecise, aborting
wine: Unimplemented function
api-ms-win-core-realtime-l1-1-1.dll.QueryUnbiasedInterruptTimePrecise called at
address 000000017002FA08 (thread 0110), starting debugger...
```
Steps to reproduce
- install Swift 5.7.2 -
https://download.swift.org/swift-5.7.2-release/windows10/swift-5.7.2-RELEAS…
- execute `wine swift`
--
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=53504
Bug ID: 53504
Summary: Sacred:unhandled exception in Wine 7.14
Product: Wine
Version: 7.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: chebanenkoigor93(a)gmail.com
Distribution: ---
Created attachment 72868
--> https://bugs.winehq.org/attachment.cgi?id=72868
screenshot
Wine 7.14 gives me exception after launching Sacred.
--
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.