http://bugs.winehq.org/show_bug.cgi?id=28467
Summary: Chromium Browser restore button doesn't work
Product: Wine
Version: 1.3.28
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fracting(a)gmail.com
1. Download chromium from
http://build.chromium.org/f/chromium/snapshots/Win/95816/chrome-win32.zip
unpack chrome-win32.zip, cd to the directory.
2. start chrome.exe with --no-sandbox, works around Bug 21232
$ wine chrome.exe --no-sandbox
Notice that the chrome window is decorated by the Linux native window manager.
Is it a bug? On windows, chrome have no traditional "window bar".
Now there is two "Maximal" button: one is drawn by Linux native window manager,
the other is drawed by wine chrome browser it self.
3. Click on the "Maximal" button which is drawn by Linux native window manager,
then chrome browser switch to maximal mode as expect.
This time, the Linux native window bar is disappear.
4. Click on the "Restore" button of wine chrome browser. However it doesn't
work. Wine chrome switch to normal mode for a second, then switch back to
maximal mode automatically.
I use ubuntu 11.04 , with traditional gnome desktop, gnome 2.32.1 .
There is some ways to work around:
I. Instead of clicking on the native "Maximal" button in step 3, try to click
the wine chrome "Maximal" button, then everything works as expect.
II. Do not set "Allow the window manager to decorate the windows" in winecfg,
then everything works as expect.
III. Do not set "Allow the window manager to control the windows" in winecfg,
then everything works as expect.
--
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=56647
Bug ID: 56647
Summary: ntdll-Junction_Points prevent rustup from correctly
installing a toolchain
Product: Wine-staging
Version: 9.8
Hardware: x86-64
URL: https://rustup.rs/
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lorenzofer(a)live.it
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ArchLinux
Created attachment 76423
--> https://bugs.winehq.org/attachment.cgi?id=76423
return STATUS_NOT_A_REPARSE_POINT instead of STATUS_INVALID_PARAMETER
Hi.
With the recent rustup 1.27.0 using wine-staging with the
ntdll-Junction_Points patches, the toolchain installation doesn't complete
properly, failing to write to the settings.toml under the prefix home .rustup
directory info.
A bug with the same root cause is also present on rustup 1.26.0 where while the
installation was completing properly, it was failing to remove the
.rustup/tmp/* directories, causing issues with subsequent installations.
Both bugs express the same behavioral pattern with few differences. I
investigated the directory bug firstly, so I will detail this, and confirmed
that the problem and the expected solution are the same.
Rustup (or one of it's dependency managing files) get the handle of the
temporary directory using CreateFileW and then checking if it's a reparse point
using DeviceIoControl with FSCTL_GET_REPARSE_POINT.
The directories (and the file) aren't reparse points at all, so the readlink
fails returining EINVAL.
This EINVAL is then mapped to an NT_STATUS using errno_to_status that map
EINVAL to STATUS_INVALID_PARAMETER.
However this mapping is incorrect for FSCTL_GET_REPARSE_POINT as in this case
applications that handle this case like rustup try to handle this case by
epxecting STATUS_NOT_A_REPARSE_POINT.
Returning STATUS_NOT_A_REPARSE_POINT in this case allow rustup to work (both
versions )
Attaching a patch to show the change in the file.c code (and restored also the
out_buffer check)
--
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=57456
Bug ID: 57456
Summary: Wine wayland scaled window is positioned on the left,
not centered
Product: Wine
Version: 9.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winewayland
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
Distribution: ---
Created attachment 77451
--> https://bugs.winehq.org/attachment.cgi?id=77451
Vampire: The Masquerade - Redemption intro video scaled
When fullscreen resolution is set to something low and different from aspect
ratio of the monitor, winewayland scales it up, but positions it on the left,
rather than in the middle of the screen and leaves the mismatching area
transparent.
This happened for example in the intro video of Vampire: The Masquerade -
Redemption. The video is 640x346 and my screen is 2560x1440.
See attached screenshot for how it looks.
It would be better if the scaled window was positioned in the middle, with some
black bands for areas that are caused by mismatch in aspect ratio.
Even better if this behavior could be configurable, i.e. where to position,
what to use for bands, like transparent, solid color / what color, etc.
--
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=56707
Bug ID: 56707
Summary: AppDB PHP8 rewrite
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jnewman(a)codeweavers.com
Distribution: ---
The current codebase is not compatible with PHP8. We are stuck on 7.4.
The main issue is how all the objects are setup. PHP8 requires you define a
constructor as __construct, but the AppDB is using the old method of naming the
constructor the same as the object itself. While you could just rename all
those to __construct, there are places in the objects where the code refers to
$this->className(), these would need to be changed to $this->__construct() or
parent::__construct if called from a child class
There are other PHP8 issues to be solved as well. Things like some built in
functions changing how the null type is handled.
--
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=36692
Bug ID: 36692
Summary: Bad performance when combineng SetEvent /
WaitForSingleObject for synchronizing worker threads
Product: Wine
Version: 1.6.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: milasudril(a)gmail.com
In a 2d simulation program, each worker thread has its own pair of events. One
event is used to signal master thread that the worker thread is ready. The
other is used by the master thread to signal that the worker thread may
continue.
In Master thread:
while(!m_stop)
{
auto proc_ptr=processors.begin();
while(proc_ptr!=processors.end())
{
// Call SetEvent on "start" event object owned by the object pointed
// to by proc_ptr
proc_ptr->frameNext();
++proc_ptr;
}
proc_ptr=processors.begin();
while(proc_ptr!=processors.end())
{
// Call WaitForSingleObject on "ready" event object owned by
// the object pointed to by proc_ptr
proc_ptr->wait();
++proc_ptr;
}
++framecounter;
}
In worker thread:
while(!m_stop)
{
// Wait for master thread signaling start event (Calls
WaitForSingleObject)
start.wait();
m_model->process(m_framecounter,m_buffers[0].first
,m_buffers[0].second,m_offset);
swap(m_buffers[0],m_buffers[1]);
// Signal master thread that we are ready for next frame (Calls SetEvent)
ready.set();
}
On Wine, the framerate is half of that on Windows 7 on the same machine
Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz. Also there seems to be a huge
different workload on differnt cores when running under Wine.
I realize that SetEvent/WaitForSingleObject are heavy functions on Windows too
as they need kernel assistance, so it might be hard to make it perform better.
--
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=43766
Bug ID: 43766
Summary: Safrosoft RoX - Level editor doesn't start
Product: Wine
Version: 2.17
Hardware: x86-64
URL: http://www.autofish.net/shrines/rox/
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ArchLinux
Created attachment 59268
--> https://bugs.winehq.org/attachment.cgi?id=59268
wine log
The game's level editor crashes with a messagebox:
"Run-time error '481': Invalid picture"
Getting an oleaut32.dll from win7, copying it into wine's system32 folder and
adding a dll override fixes the issue.
--
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=57537
Bug ID: 57537
Summary: Steuersparerklärung 2024 fails to install
Product: Wine
Version: 9.22
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Found while testing a report from the forums:
https://forum.winehq.org/viewtopic.php?t=39775
Ran in a clean WINEPREFIX, used trial version and express installation. It
gives a messagebox with
> Die Installation von >>Steuersparerklärung 2024<< konnte nicht durchgeführt werden! Prüfen Sie bitte, ob die notwendigen Installationsvoraussetzungen erfüllt sind
Translated:
The installation of >>Steuersparerklärung 2024<< could not be completed! Please
check whether the necessary installation requirements are met
--
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=56681
Bug ID: 56681
Summary: 3d games continue receiving mouse input while not
focused
Product: Wine
Version: 9.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winewayland
Assignee: wine-bugs(a)winehq.org
Reporter: pmargeti34(a)gmail.com
Distribution: ---
Wine wayland windows seem to get the mouse input even if the application window
is not focused. 3D game world continues to respond to mouse input as if the
game still had focus.
To reproduce:
-launch a 3d game in wayland mode (warframe in my example)
-open another application and make sure it has focus
-observe that when the mouse cursor is over the game window, game still
receives input
--
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=44900
Bug ID: 44900
Summary: Colour problem with builtin gdiplus
Product: Wine
Version: 3.5
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: jeremielapuree(a)yahoo.fr
Distribution: ---
Created attachment 60981
--> https://bugs.winehq.org/attachment.cgi?id=60981
Good looking with a native gdiplus
With a builtin gdiplus, there is a problem with coloring the cases of channel.
Problem does not occur with a native gdiplus dll. Compare the two screenshot:
the first one with native dll, the second one with the builtin dll.
Note the behaviour in a real Windows 10 box is the behaviour of the native dll.
So, there is a problem with the builtin 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=56667
Bug ID: 56667
Summary: World of Tanks: Unplayable due to extreme CPU usage /
bottlenecking
Product: Wine
Version: 9.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xxx43615xxx(a)gmail.com
Distribution: ---
In short, rendering graphics is now heavily CPU-bound for some reason,
resulting in unusably low performance. As far as I can tell, this is not caused
by DXVK or my graphics drivers. I don't think I should fully repeat myself
here, please read the details in my forum thread:
https://forum.winehq.org/viewtopic.php?t=38875
The game can be installed through Wargaming's launcher, EU version available
here after registration (free):
https://worldoftanks.eu/en/game/download/
--
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.