https://bugs.winehq.org/show_bug.cgi?id=44597
Bug ID: 44597
Summary: Window rendering completely breaks after interacting
with the “Desktop Integration” section of winecfg with
enabled GTK3 themeing
Product: Wine-staging
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alexander-winehq(a)xmine128.tk
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
Created attachment 60584
--> https://bugs.winehq.org/attachment.cgi?id=60584
Changes in HKCU registry
# Background & Steps to reproduce
Window rendering will show bizare artifacts, up to becoming totally useless
(tiny transparent window frames that cannot be interacted with), after
following the below steps:
1. In WINE staging enable GTK3 themeing
2. Open `winecfg` again (things should be themed now)
3. Select the “desktop integration” tab
4. Change the “theme” from “GTK-3” to “(No Theme)” and click “Apply”
5. Do the above two times for noticable rendering issues and crashes
6. Do the above three (or more) times to break *any window rendering in WINE*
(see attachment 2)
# Underlying issue
I'm not exactly sure what `winecfg` happens to do here, but it somehow manages
to calculate and store some completely wrong values for several entries inside
the
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
registry key (see attachment 1) that then result in this behaviour.
# Workaround
Open `${WINEPREFIX}/user.reg` in a text editor and delete the entire
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
registry key section before launching WINE 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.
https://bugs.winehq.org/show_bug.cgi?id=45586
Bug ID: 45586
Summary: Empyrion Dedicated generates err:seh:setup_exception
stack overflow
Product: Wine
Version: 3.13
Hardware: x86-64
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: kovus(a)soulless.wtf
Created attachment 62007
--> https://bugs.winehq.org/attachment.cgi?id=62007
wine debug output
Empyrion Dedicated server ("nographics" as they call it) generates an
err:seh:setup_exception when you try to run it.
0009:err:seh:setup_exception stack overflow 2896 bytes in thread 0009 eip
000000007bc9188d esp 0000000000130ac0 stack 0x130000-0x132000-0x230000
Per a suggestion from https://forum.winehq.org/viewtopic.php?f=2&t=30972, I'm
posting the requested information here.
Wine 3.13 (built from the FreeBSD ports tree as "wine-devel")
64-bit
Fresh .wine folder (deleted and recreated with defaults when running winecfg).
Commands used to generate the attached output (tcsh)
setenv WINEPATH .
setenv WINEDEBUG +timestamp,+tid,+all
wine64 EmpyrionDedicated.exe -batchmode -nographics -logFile Logs/temp.log | &
tee ~/wine_empyrion_server_log.txt
The error mentioned in the subject is on line 617399 of the attached log.
After that, EmpyrionDedicated goes into what appears to be an infinite loop, so
the file ends when the program gets ctl+c'd.
--
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=45551
Bug ID: 45551
Summary: InstallSheld exits with 0x80004002, cannot find
SECURITY.MySetFileSecurity
Product: Wine
Version: 3.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: haakobja(a)gmail.com
Distribution: ---
Created attachment 61964
--> https://bugs.winehq.org/attachment.cgi?id=61964
+relay debug log
Hi!
I'm trying to install a game I have, but the InstallShield installer crashes
when it cannot find the SECURITY.MySetFileSecurity method.
I get the following error message in the Wine logs:
0032:err:ole:ClientIdentity_QueryMultipleInterfaces
IRemUnknown_RemQueryInterface failed with error 0x80004002.
--
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=31741
Bug #: 31741
Summary: python-2.7.3.amd64.msi fails to install
Product: Wine
Version: unspecified
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: tahoar(a)gmail.com
Classification: Unclassified
I tried installing Python 64-bit 2.7.3 on wine1.5-amd64. The installer loads
but will not progress after the introduction page. When clicking "continue",
the installer does nothing. Clicking "cancel" exits the installer.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=5129
--- Comment #26 from unxed <unxed(a)mail.ru> ---
Created attachment 62027
--> https://bugs.winehq.org/attachment.cgi?id=62027
"copy to"/"move to" problem after using native comctl32.dll
--
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=1865
George Creel <george(a)creel.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |george(a)creel.net
--
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=45316
Bug ID: 45316
Summary: [Mansions of Madness] When character is missing from
font it is not rendered, while on windows it is
rendered with default font instead
Product: Wine
Version: 3.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: konserw(a)gmail.com
Distribution: ---
Created attachment 61601
--> https://bugs.winehq.org/attachment.cgi?id=61601
sample screen from mansions of madness
When character is missing from custom application's font it is not rendered at
all, so it is hard to read words with such characters.
On windows such characters are rendered with default font (times new roman?)
instead.
I know it's applications fault and windows does ugly workaround, but at least
text is readable.
In particular I stumbled on this when I've tried "Mansions of madness" with
polish translation - application's fancy font doesn't have polish letters, like
ąśćżźłę - in screenshot attached first option should read "Język: Polski"
instead of "Jzyk: Polski"
"Mansions of madness" are companion-app for board game and it is free on steam.
First I've encountered this bug on Ubuntu Bionic x64 and wine-development from
repository.
For this bug I've reproduced this bug on Arch Linux x64 and wine-3.9
(Staging)(clean 32bit prefix, steam from winetricks, no overrides)
--
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=45563
Bug ID: 45563
Summary: winecfg about tab text is not respecting custom theme
text color.
Product: Wine
Version: 3.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: mt_talpur(a)yahoo.com
Distribution: ---
Created attachment 61985
--> https://bugs.winehq.org/attachment.cgi?id=61985
text color is black it should use theme color
winecfg about text color is not changing it remains always black no matter what
color scheme applied in wine.
--
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=44373
Bug ID: 44373
Summary: cmd's %0 path variables (e.g. %~dp0) don't match those
of Windows (w.r.t. case and quoting)
Product: Wine
Version: 3.0-rc6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: cmd
Assignee: wine-bugs(a)winehq.org
Reporter: ryan.prichard(a)gmail.com
Distribution: ---
I'm filing this issue at Fabian Maurer's suggestion, after filing
https://bugs.winehq.org/show_bug.cgi?id=44369.
When %0 starts with a quote character, Windows tends to evaluate the %0 path
variables (%~d0, %~p0, ...) strangely. I think the Wine behavior makes more
sense, but it could also make sense to match Windows bug-for-bug.
Test program (you might have to fix up the C:\bin for your machine):
C:\>mkdir Bin
C:\Bin\ShowArg0.Cmd:
@echo [%0] -------------------- [%~d0] [%~p0] [%~n0] [%~x0]
C:\Bin\RunScript.Cmd
@echo off
setlocal
set PATH=C:\bin;%PATH%
cd \
echo --- Wine and Windows roughly do the same thing.
call showarg0
call SHOWARG0
call showarg0.cmd
call SHOWARG0.CMD
call C:\bin\showarg0
call C:\bin\showarg0.cmd
call c:\bin\showarg0.CMD
call showarg0".cmd"
call showarg0."cmd"
call showarg0.c"md"
call s"ho"warg0.cmd
call s"ho"warg0
call "C:\bin\showarg0.cmd"
call "c:\bin\showarg0.CMD"
echo --- Wine and Windows diverge here.
call "showarg0"
call "SHOWARG0"
call "showarg0.cmd"
call "SHOWARG0.CMD"
call "showarg0".cmd
call "sho"warg0.cmd
call "sho"warg0
call "C":\bin\showarg0.cmd
call "C:"\bin\showarg0.cmd
call "C:\"bin\showarg0.cmd
call "c:\"bin\showarg0.CMD
call "C:\bin\showarg0"
(I edited the script output to align the columns.)
Windows behavior (tested on XP and Win10.0.16299.125):
C:\Bin>RunScript
--- Aside from case, Wine and Windows roughly do the same thing.
--- ... Using c:\bin in PATH
[showarg0] ----------------- [c:] [\Bin\] [ShowArg0] [.Cmd]
[SHOWARG0] ----------------- [c:] [\Bin\] [ShowArg0] [.Cmd]
--- ... Using C:\bin in PATH
[showarg0] ----------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[SHOWARG0] ----------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0.cmd] ------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[SHOWARG0.CMD] ------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[C:\bin\showarg0] ---------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[C:\bin\showarg0.cmd] ------ [C:] [\Bin\] [ShowArg0] [.Cmd]
[c:\bin\showarg0.CMD] ------ [c:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0".cmd"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0."cmd"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[showarg0.c"md"] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[s"ho"warg0.cmd] ----------- [C:] [\Bin\] [ShowArg0] [.Cmd]
[s"ho"warg0] --------------- [C:] [\Bin\] [ShowArg0] [.Cmd]
["C:\bin\showarg0.cmd"] ---- [C:] [\Bin\] [ShowArg0] [.Cmd]
["c:\bin\showarg0.CMD"] ---- [c:] [\Bin\] [ShowArg0] [.Cmd]
--- Wine and Windows diverge here.
["showarg0"] --------------- [C:] [\] [showarg0] []
["SHOWARG0"] --------------- [C:] [\] [SHOWARG0] []
["showarg0.cmd"] ----------- [C:] [\] [showarg0] [.cmd]
["SHOWARG0.CMD"] ----------- [C:] [\] [SHOWARG0] [.CMD]
["showarg0".cmd] ----------- [C:] [\] [showarg0"] [.cmd]
["sho"warg0.cmd] ----------- [C:] [\] [sho"warg0] [.cmd]
["sho"warg0] --------------- [C:] [\] [sho"warg0] []
["C":\bin\showarg0.cmd] ---- [C:] [\C":\bin\] [showarg0] [.cmd]
["C:"\bin\showarg0.cmd] ---- [C:] [\"\bin\] [showarg0] [.cmd]
["C:\"bin\showarg0.cmd] ---- [C:] [\"bin\] [showarg0] [.cmd]
["c:\"bin\showarg0.CMD] ---- [c:] [\"bin\] [showarg0] [.CMD]
["C:\bin\showarg0"] -------- [C:] [\Bin\] [showarg0] []
Behavior on wine-3.0-rc6:
C:\Bin>RunScript
--- Aside from case, Wine and Windows roughly do the same thing.
--- ... Using c:\bin in PATH
[showarg0] ----------------- [c:] [\bin\] [showarg0] [.CMD]
[SHOWARG0] ----------------- [c:] [\bin\] [SHOWARG0] [.CMD]
--- ... Using C:\bin in PATH
[showarg0] ----------------- [C:] [\bin\] [showarg0] [.CMD]
[SHOWARG0] ----------------- [C:] [\bin\] [SHOWARG0] [.CMD]
[showarg0.cmd] ------------- [C:] [\bin\] [showarg0] [.cmd]
[SHOWARG0.CMD] ------------- [C:] [\bin\] [SHOWARG0] [.CMD]
[C:\bin\showarg0] ---------- [C:] [\bin\] [showarg0] [.CMD]
[C:\bin\showarg0.cmd] ------ [C:] [\bin\] [showarg0] [.cmd]
[c:\bin\showarg0.CMD] ------ [c:] [\bin\] [showarg0] [.CMD]
[showarg0".cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd]
[showarg0."cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd]
[showarg0.c"md"] ----------- [C:] [\bin\] [showarg0] [.cmd]
[s"ho"warg0.cmd] ----------- [C:] [\bin\] [showarg0] [.cmd]
[s"ho"warg0] --------------- [C:] [\bin\] [showarg0] [.CMD]
["C:\bin\showarg0.cmd"] ---- [C:] [\bin\] [showarg0] [.cmd]
["c:\bin\showarg0.CMD"] ---- [c:] [\bin\] [showarg0] [.CMD]
--- Wine and Windows diverge here.
["showarg0"] --------------- [C:] [\bin\] [showarg0] [.CMD]
["SHOWARG0"] --------------- [C:] [\bin\] [SHOWARG0] [.CMD]
["showarg0.cmd"] ----------- [C:] [\bin\] [showarg0] [.cmd]
["SHOWARG0.CMD"] ----------- [C:] [\bin\] [SHOWARG0] [.CMD]
["showarg0".cmd] ----------- [C:] [\bin\] [showarg0] [.cmd]
["sho"warg0.cmd] ----------- [C:] [\bin\] [showarg0] [.cmd]
["sho"warg0] --------------- [C:] [\bin\] [showarg0] [.CMD]
["C":\bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd]
["C:"\bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd]
["C:\"bin\showarg0.cmd] ---- [C:] [\bin\] [showarg0] [.cmd]
["c:\"bin\showarg0.CMD] ---- [c:] [\bin\] [showarg0] [.CMD]
["C:\bin\showarg0"] -------- [C:] [\bin\] [showarg0] [.CMD]
I see two differences:
- In most cases, when a path starts with a quote, Windows somehow doesn't
parse the path correctly and/or doesn't find the batch file in the PATH.
- As long as Windows *does* find the batch file, it uses the canonical case
for the path, filename, and extension. It doesn't canonicalize the drive;
instead it uses the drive from the PATH or %0. I also tested a SMB share on XP
and Win10 (\\nAs\nAs and \\NaS\NaS), and Windows didn't canonicalize the server
name or share name. (Maybe it never does.)
--
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=45576
Bug ID: 45576
Summary: Disabling game controllers does not work
Product: Wine
Version: 3.13
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ahyattdev(a)icloud.com
Disabling game controllers in control panel has no effect. It says you need to
restart the applet to see the change take affect but it never ends up
preventing the controllers from showing up in the connected controller list.
I am not sure if this is macOS specific or not, I have not tested this on
Linux.
--
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.