https://bugs.winehq.org/show_bug.cgi?id=53898
Bug ID: 53898
Summary: Programmer's File Editor MDI window contents
incorrectly refreshed after closing an MDI document
Product: Wine
Version: 7.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: wine_bugzilla(a)sctb.ch
Distribution: ---
Created attachment 73439
--> https://bugs.winehq.org/attachment.cgi?id=73439
Corrupted window.
I've been using Programmer's File Editor (PFE), a text editor from 1999, with
WINE, since the beginning of time.
There has always been a problem that when the editor has multiple MDI windows
open, and a single window has been maximized (so it fills the entire editor),
and that window is closed, the window which replaces it does not correctly
refresh the editor display - the content is visually garbled.
Minimizing and restoring the editor induces a correct refresh.
Screenshot attached of a garbled window, and then the same window after a
min-restore induced refresh (so you can more easily see the corruption).
--
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=54065
Bug ID: 54065
Summary: Windower 4 with FFXI Online has no keyboard input
Product: Wine
Version: 7.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: dinput
Assignee: wine-bugs(a)winehq.org
Reporter: reaper2021(a)protonmail.com
Distribution: ---
Created attachment 73616
--> https://bugs.winehq.org/attachment.cgi?id=73616
error log
Keyboard input in FFXI with Windower 4 has been broken for a long time. It
fails in 7.20, and all the way down to 5.0rc2 or earlier (I stopped testing
there).
Keyboard input works in wine-staging-5-0rc5, and no longer works in
wine-staging-5-0-rc6.
My installation for which I posted the log uses dxvk and dgVoodoo, but the
problem also occurs without that.
Steps to reproduce:
1. make a 32 bit prefix, windows version seems noncritical (7 or 10).
2. install official FFXI distribution from
http://www.playonline.com/ff11us/download/media/install_win.html
(install hangs for a seemingly long time at some step, disk space check if I
recall, just wait)
3. winetricks dotnet462 gdiplus (without dotnet, windower will not work.
Gdiplus just makes the fonts in the windower console look nicer, it's not
absolutely required for reproduction.)
4. install windower 4.3 from https://www.windower.net/ , to
$WINEPREFIX/drive_c/windower4.3/
5. wine $WINEPREFIX/drive_c/windower4.3/Windower.exe
At this step, you'll need an FFXI subscription and character to log in and get
to the point where you see that the keyboard 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.
https://bugs.winehq.org/show_bug.cgi?id=52987
Bug ID: 52987
Summary: comctl32:tooltips - test_customdraw() fails
systematically on some Windows 10 machines
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
comctl32:tooltips - test_customdraw() fails systematically on some Windows
machines:
tooltips.c:251: Test failed: 0: Failed to get current tool 0.
tooltips.c:258: Test failed: 0: Unexpected hwnd CCCCCCCCCCCCCCCC.
tooltips.c:259: Test failed: 0: Unexpected hinst CCCCCCCCCCCCCCCC.
tooltips.c:260: Test failed: 0: Unexpected uId cccccccccccccccc.
tooltips.c:261: Test failed: 0: Unexpected lParam cccccccccccccccc.
tooltips.c:251: Test failed: 1: Failed to get current tool 0.
tooltips.c:258: Test failed: 1: Unexpected hwnd CCCCCCCCCCCCCCCC.
tooltips.c:259: Test failed: 1: Unexpected hinst CCCCCCCCCCCCCCCC.
tooltips.c:260: Test failed: 1: Unexpected uId cccccccccccccccc.
tooltips.c:261: Test failed: 1: Unexpected lParam cccccccccccccccc.
[... all 6 iterations fail ...]
https://test.winehq.org/data/patterns.html#comctl32:tooltips
Also this impacts both test_customdraw() calls: the one after
test_create_tooltip(FALSE) and the one after test_create_tooltip(TRUE) though
the latter is more random. When the latter fails there is an extra couple of
failures in test_TTN_SHOW():
tooltips.c:261: Test failed: 5: Unexpected lParam cccccccccccccccc.
tooltips.c:1216: Test failed: TTN_SHOW parent seq: the msg sequence is not
complete: expected 004e - actual 0000
tooltips.c:1216: Failed sequence TTN_SHOW parent seq:
tooltips.c:1216: 0: expected: msg 004e - actual: nothing
v6util.h:92: created cc6.manifest
tooltips.c:251: Test failed: 0: Failed to get current tool 0.
[...]
tooltips.c:1216: Test failed: TTN_SHOW parent seq: the msg sequence is not
complete: expected 004e - actual 0000
However the failure pattern is strange:
* The failures mostly happen on the cw-gtx560 and cw-rx460 machines. But
w1064v1709-64 has the same failures so it's not a real hardware vs. VM issue.
* The failures happen on Windows 10 1709, 21h1 and 21h2, but not on 1507, 1607,
1809 or 2004. 1909 had failures on March 21 and 22 but not in the month since
then. So it does not really seem related to the Windows version.
* cw-gtx560-21H1 and cw-rx460-21H1 never had failures in the 32-bit tests but
the failures happen in 32-bit on cw-gtx560-1709 and cw-rx460-1709. So it's not
a bitness issue and it should not be a machine configuration issue either.
The failure on line 251 indicates that there is no tooltip at all. Maybe there
is a window that has the focus and prevented the tooltip from opening? (that
window if any is not visible in the final screenshot)
If it is a focus issue, skipping when the windows does not have the focus could
avoid the failures.
--
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=30826
Bug #: 30826
Summary: Gigasoft's ProEssentials demo crashes on startup
Product: Wine
Version: 1.5.5
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Classification: Unclassified
To reproduce,
wget http://www.gigasoft.com/PE7-Pro-Setup.exe
wine PE7-Pro-Setup.exe
cd .wine/drive_c/ProEssentials7/DEMO
wine PEDemo.exe
Click the popup window to make it go away.
Unhandled exception: page fault on read access to 0x5050ff98 in 32-bit code
(0x7ed36a26).
Or, sometimes:
Unhandled exception: page fault on read access to 0x00000048 in 32-bit code
(0x7ed2ea26).
The backtrace seems the same either way:
Backtrace:
=>0 get_log_fontW+0x16(font=0x720041, graphics=0x154780, lf=0x32e92c)
[dlls/gdiplus/font.c:486]
1 get_font_hfont+0x10e(graphics=0x154780, font=0x720041, hfont=0x32eb58)
[dlls/gdiplus/graphics.c:2139]
2 GdipDrawString+0x2c1(graphics=0x154780, string="Bollinger Upper",
length=0xf, font=0x720041, rect=0x32eba8, format=0x149e28, brush=0x154b68)
[dlls/gdiplus/graphics.c:5210]
486 lf->lfHeight = -em_size_to_pixel(font->emSize, font->unit,
font->family->dpi);
Installing corefonts doesn't help.
--
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=54013
Bug ID: 54013
Summary: Cannot install Trimble Sketchup Pro 2022 at all
Product: Wine
Version: 7.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: gdpo22(a)orange.fr
Distribution: ---
Created attachment 73589
--> https://bugs.winehq.org/attachment.cgi?id=73589
Trying to install sketchup without sed solution
After downloading the sketchup pro 2022 trial, the sketchup installer displayed
a lot of error windows "Invalid descriptor" with an "ok" button. After 6 or 7
click on "ok", the install terminates with a final window error of trimble
saying that the installation cannot complete. (see attachement)
The same with 7.0 wine stable version.
Then I succeeded to install by applying a dirty solution I have seen on a
forum:
sed 's/GetFinalPathNameByHandleW/QetFinalPathNameByHandleW/'
SketchUpPro-2022-0-354-126.exe > hacked_installer.exe
But when I try to click on 'connexion' button from welcome screen, nothing
happens.
--
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=48734
Bug ID: 48734
Summary: How to Survive crashes when starting a new game
Product: Wine
Version: 5.0-rc1
Hardware: x86
URL: https://store.steampowered.com/app/250400/How_to_Survi
ve/
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: z.figura12(a)gmail.com
Regression SHA1: 94822bae5fed8a3bbda00adb4e79652cd9374309
Distribution: ---
Created attachment 66616
--> https://bugs.winehq.org/attachment.cgi?id=66616
terminal output
The game was started in windowed mode to work around bug #48732.
When I start a new single-player game from the menu, Wine crashes when
attempting to play the first video. I think it's 'prologue.avi' which should be
playing at this point.
Cutscenes didn't work properly before the regression, only a black screen was
shown and pressing <Space> or <Esc> made it possible to skip the video. Now
Wine crashes.
The crash was introduced by
commit 94822bae5fed8a3bbda00adb4e79652cd9374309
quartz/vmr9: Create the rendering window when the filter is created.
To reproduce the problem select <Local Game> in the main menu, then <Story
Mode>, <1 Player>, choose a character and difficulty level. After a short
loading animation Wine crashes.
Tested in wine-5.3-181-geb63713f60.
--
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=51134
Bug ID: 51134
Summary: Support redirecting GetOpenFileName and
GetSaveFileName through
org.freedesktop.portal.FileChooser
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: from_wine_bugzilla(a)ssokolow.com
Distribution: ---
While not all options in the OPENFILENAME structure can be supported via the
org.freedesktop.portal.FileChooser interface, providing the option to redirect
an application's request for a common Open/Save dialog through the XDG chooser
system would have two beneficial effects on non-OSX POSIX systems:
1. Better integration, since the application run under Wine would use the
native desktop file pickers, complete with the user's Places sidebar bookmarks
and any other customizations they've enacted.
2. More practical security, since Wine could then be run in a filesystem
sandbox, with the portal host mounting files/directories into the sandboxed
environment on demand.
I'd suggest a three-state option exposed through winecfg's Desktop Integration:
1. Opportunistically (Qt's approach to integrating support for XDG portals into
QFileDialog provides precedent for making this the default. Uses the
portal-based file chooser unless an application requests a combination of
OPENFILENAME settings that cannot be represented by the portal API.)
2. Forced (An option for power users to set on a per-application basis to
intentionally sacrifice the application's customizations in favour of better
integration with the understanding that things may break.)
3. Never (An option for users who prefer consistency between their Windows
applications over consistency with the rest of their desktop or have deleted
the Z: mapping and configured their Wine prefix around the idea of only working
with drive letters.)
These high-level preferences could also apply equally well to any other
platform's native file chooser, should integration with it be implemented.
The D-Bus API in question is documented at
https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.fre…
While it is outside the scope of this feature request, it may also be possible
to use the TrashFile() method of this API to integrate with the host desktop's
Trash.
--
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=54463
Bug ID: 54463
Summary: wbemprox: wrong version value is returned from
win32_operatingsystem on win10 (regression)
Product: Wine
Version: 8.1
Hardware: x86-64
URL: https://github.com/PowerShell/PowerShell/releases/down
load/v7.0.3/PowerShell-7.0.3-win-x64.msi
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: wmi&wbemprox
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
CC: hans(a)meelstraat.net
Distribution: Debian
Following powershell script returns wrong version on win10 (winetricks dotnet48
is required):
$searcher = [wmisearcher]'Select version From win32_operatingsystem'
$searcher.scope.path = "\\.\root\cimv2"
$searcher.get()
Result:
__GENUS : 2
__CLASS : Win32_OperatingSystem
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
Version : 6.3.18362
PSComputerName :
In wine 8.0 it reports correctly:
__GENUS : 2
__CLASS : Win32_OperatingSystem
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
Version : 10.0.18362
PSComputerName :
This bug results in Chocolateley downloading tons off MB's off updates because
it believes version is <win10.
--
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=54713
Bug ID: 54713
Summary: dinput:device8 - test_mouse_keyboard() fails on some
Window 7 locales
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: dinput
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
dinput:device8 - test_mouse_keyboard() fails on some Window 7 locales:
device8.c:684: Test failed: IDirectInputDevice8_Acquire failed: 0x80070005
device8.c:686: Test failed: IDirectInputDevice8_Acquire failed: 0x80070005
device8.c:690: Test failed: GetRegisteredRawInputDevices returned 1,
raw_devices_count: 3
device8.c:691: Test failed: Unexpected raw device flags: 0
device8.c:692: Test failed: Unexpected raw device flags: 0
See https://test.winehq.org/data/patterns.html#dinput:device8
This has been happening on Windows 7 since 2023-01-06:
* 2023-01-06 on w7u-pt-PT 32-bit
* 2023-01-27 on w7u-adm 32-bit
* 2023-03-03 on w7u-de 32-bit
But on 2023-03-16 this seems to have become systematic on w7u-el, w7u-es and
w7u-pt-PT. A bisect shows that the failure rate seems to have increased with
the commit below:
commit 07753da93ce1f78c710f666e193a0434eb99699b
Author: Rémi Bernon <rbernon(a)codeweavers.com>
Date: Wed Mar 15 21:04:01 2023 +0100
dinput/tests: Remove BuildActionMap / SaveActionMap mouse and keyboard
tests.
--
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=54106
Bug ID: 54106
Summary: taskschd:scheduler - test_GetTask() fails on Windows 7
when it has insufficient privileges
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: taskschd
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
test_GetTask() fails on Windows 7 when it has insufficient privileges:
scheduler.c:802: Test failed: DeleteTask error 0x80070005
scheduler.c:798: Test failed: 1: expected 0, got 0x800700b7
scheduler.c:798: Test failed: 2: expected 0x80070002, got 0
scheduler.c:802: Test failed: DeleteTask error 0x80070005
scheduler.c:802: Test failed: DeleteTask error 0x80070005
scheduler.c:814: Test failed: RegisterTask error 0x800700b7
scheduler.c:960: Test failed: DeleteTask error 0x80070005
scheduler.c:962: Test failed: DeleteTask error 0x80070005
scheduler.c:965: Test failed: expected ERROR_FILE_NOT_FOUND, got 0x80070005
scheduler.c:993: Test failed: DeleteFolder error 0x80070091
This can be seen on the w7u_adm VM.
When run as part of the full WineTest run this test crashes in
test_FolderCollection() which prevents seeing this failure in the nightly
WineTest runs.
See https://test.winehq.org/data/patterns.html#taskschd:scheduler
But this set of failures is impacting merge requests such as MR!1732 and
MR!1736.
--
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.