http://bugs.winehq.org/show_bug.cgi?id=58592
Bug ID: 58592
Summary: Font substitution partially broken - regression
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: zdenek.koprivik(a)post.cz
Distribution: ---
While trying to replace "Tahoma" with "Noto Sans Regular" (the default Plasma
desktop font), I've encountered an issue, where the font replacement does not
work in some cases. Since I'm migrating from a very old system with Wine 1.6.2,
I know that the font replacement used to work for the exact same binary and the
same UI elements.
I've set the following registry keys:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\FontSubstitutes]
"Tahoma"="Noto Sans Regular"
"Segoe UI"="Noto Sans Regular"
"MS Shell Dlg"="Noto Sans Regular"
"MS Shell Dlg 2"="Noto Sans Regular"
The issue can be reproduced by opening the file dialog in the built-in registry
editor.
Running the built-in registry editor I've got the main font changed to "Noto
Sans Regular" as expected, but in the file open dialog for import, there is
still "Tahoma". When I'm browsing for directories, the font changes to "Noto
Sans Regular", but when an item is selected, the font changes back to "Tahoma".
Here is a short video showing the issue: https://imgur.com/a/l0BhsB8
This is only one example of the non-working substitution. The "Tahoma" is also
rendered on the buttons and almost everywhere around in the dialog. I'm using
the substitution mostly for MikroTik network equipment management apps (WinBox
and The Dude) to improve the readability. It is working fine when running the
exact same binaries on the old PC with Wine 1.6.2, but I can't get it to work
with the newest Wine.
The system is KDE neon User, Plasma 6.4.4, Wine 10.12 from the WineHQ PPA.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58670
Bug ID: 58670
Summary: [Damavand] The renderer crashes with Clickteam games
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: user.pecheniok(a)gmail.com
Distribution: ---
When trying to play clickteam games with damavand, they crash before anything
is rendered. These lines appear the most in the console:
0148:fixme:d3d_shader:shader_spirv_scan_shader Shader log:
0148:fixme:d3d_shader:shader_spirv_scan_shader <anonymous>:25:0: W7006:
Input register 9 was used without being declared.
0148:fixme:d3d_shader:shader_spirv_scan_shader <anonymous>:26:0: W7006:
Input register 10 was used without being declared.
The full log is attached (This one is from FNaF World specifically)
--
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=56614
Bug ID: 56614
Summary: Videos are not player in The Signifier (GOG)
Product: Wine
Version: 9.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mfplat
Assignee: wine-bugs(a)winehq.org
Reporter: titan.costa(a)gmail.com
Distribution: ---
Created attachment 76371
--> https://bugs.winehq.org/attachment.cgi?id=76371
console log
Videos are not played. Observable during menu and on the computer at the
beginning. Console output attached.
wine-9.7-100-g7641124d07a
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58604
Bug ID: 58604
Summary: Unable to handle Ctrl+C signal
correctly,02c0:fixme:console:default_ctrl_handler
Terminating process e0 on event 0
Product: Wine
Version: 10.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: 1514704742(a)qq.com
Distribution: ---
Unable to handle Ctrl+C signal correctly
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58668
Bug ID: 58668
Summary: SolidWorks - Certain buttons fail to trigger actions
Product: Wine
Version: 10.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: depaoli.renzo(a)gmail.com
Distribution: ---
Created attachment 79253
--> http://bugs.winehq.org/attachment.cgi?id=79253
SolidWorks 2023 buttons not working on Wine-10.14
Clicking certain buttons in SolidWorks no longer trigger an action, but stop at
selecting the button instead.
This bug must have been introduced some time after wine-9.22, as wine-9.22
works fine.
Please see attached screen grab for SolidWorks 2023sp05:
The buttons in question are
- <Close>, aka green tick mark
- "Rectangle Type" selection
When building wine-10.14 from source, replacing the wine-10.14 folder
"dlls/comctl32"
with the older one from wine-9.22 fixes the problem and the SolidWorks buttons
work again.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58665
Bug ID: 58665
Summary: cmd incorrectly wraps text containing ANSI escape
sequences
Product: Wine
Version: 10.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: cmd
Assignee: wine-bugs(a)winehq.org
Reporter: forestix(a)gaga.casa
Distribution: ---
Created attachment 79250
--> http://bugs.winehq.org/attachment.cgi?id=79250
reproducer: should print 3 lines; wine prints 4 lines
Wine's cmd.exe prematurely inserts line breaks when a program's output contains
non-printable ANSI escape sequences, such as those used to change colors.
It looks as though Wine is counting not only the printable characters in the
program's output, but also the non-printable ones, and using the total to
decide where to insert a line break. Text that fits entirely on one line in a
real Windows console is sometimes broken midway through the line, or followed
by a blank line that should not be there, when run in an xterm using Wine.
I am attaching a batch file that reproduces the problem. It should print 3
lines. The second line is identical to the others with the addition of some
non-printable escape sequences. These characters should either occupy no width
in the terminal (making the line length match the others) or be rendered as
visible placeholder characters (as older Windows versions do). To see Wine
handling it incorrectly, run it in an 80-column xterm or a similar terminal.
Ideally, the output should look like this, with the head of line 2 in red:
79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789
79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789
79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789
In wine, the output looks like this:
79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789
79 chars _123456789_123456789_123456789_123456789_123456789_123456789_12
3456789
79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789
Bug 49780 is related, but IMHO does not excuse this behavior. Regardless of
whether virtual terminal sequences are supported, Wine should either print a
character or not count it toward the length of a line when deciding where to
wrap it.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=58500
Bug ID: 58500
Summary: 64-bit "Plain Vanilla Compiling" fails
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: build-env
Assignee: wine-bugs(a)winehq.org
Reporter: depaoli.renzo(a)gmail.com
Distribution: ---
Building Wine-10.12 "64-bit only" shows a number of issues and fails in the end
during "make install" when trying to copy a non-existing file.
Test-Environment:
- Host providing RAMdisk as SharedDrive for build
- VirtualBox 7.1.10 r169112 VM with
- 8 cores
- Debian 12 bookworm 64-bit & KDE
- user "vbox"
- no previous Wine installation (neither cxoffice or others)
- SharedDrive mounted as /home/vbox/RAMdisk
--
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=57691
Bug ID: 57691
Summary: wine-mono: ASan gets triggered in
mono_path_canonicalize with strcpy-param-overlap.
Product: Wine
Version: 10.0-rc6
Hardware: x86-64
OS: Linux
Status: NEW
Severity: minor
Priority: P2
Component: mscoree
Assignee: wine-bugs(a)winehq.org
Reporter: bernhardu(a)mailbox.org
Distribution: ---
Created attachment 77881
--> https://bugs.winehq.org/attachment.cgi?id=77881
asan_2025-01-18_17-11-19_.1748
Hello, I tried getting wine being built with ASan (PE side) enabled. [1]
And tried running on this build the wine conformance tests.
One place where ASan gets triggered is in mono\mono\utils\mono-path.c [2]:
90 if (dest != lastpos) strcpy (dest, lastpos);
ERROR: AddressSanitizer: strcpy-param-overlap
A few lines above (line 74) there is the possibility of the strings
overlapping mentioned and a memmove used.
Attached file contains the full output of one ASan event.
Would it be valuable to replace the `strcpy (dest, lastpos);`
by a `memmove (dest, lastpos, strlen(lastpos) + 1)`?
[1]
https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2024-12-29/README.md
[2] https://gitlab.winehq.org/mono/mono/-/blame/main/mono/utils/mono-path.c#L90
--
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.