https://bugs.winehq.org/show_bug.cgi?id=56753
Bug ID: 56753
Summary: Full Tilt! Pinball (Maxis) - crash on pirates table
with "denormal float operand"
Product: Wine
Version: 9.9
Hardware: x86-64
URL: https://www.mobygames.com/game/4476/full-tilt-pinball/
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nikolas.gur(a)stud.uni-due.de
Distribution: ArchLinux
Created attachment 76538
--> https://bugs.winehq.org/attachment.cgi?id=76538
backtrace the game generates
This is about the full game with 3 Tables also known as Pinball 95, not the
Demo (Space Cadet) included with Windows XP.
Downloaded from https://oldgamesdownload.com/full-tilt-pinball/ (Version
Windows 3.x (1996) - 107.01MB):
md5sum Full_Tilt_Pinball_Win3xO_Version_EN.zip
8cfdcc43898cbb72da175649af7a3db9 Full_Tilt_Pinball_Win3xO_Version_EN.zip
There is a game crash specifically on the Pirates.exe table. I was playing the
other 2 tables cadet.exe and dragon.exe for several minutes but couldn't get
the crash reproduced there.
There are at least two elements on that table that cause a "Unhandled
exception: denormal float operand" when hitting, see the attached screenshots:
1) The right part with the parrot
2) The 5 yellow dominos in a row in the top part
Play for a few seconds and you should hit one of these elements more or less
automatically, and the game should crash. I also couldn't get this reproduced
on neither on the 3 tables of the sequel (Full Tilt! 2 Pinball 1996).
--
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=56749
Bug ID: 56749
Summary: Installation impossible d'harmony assistant
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nardale(a)free.fr
Distribution: ---
Bloque sur l'installation d'harmony assistant 998c-x64 pour windows.
Ecran noir
--
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=53511
Bug ID: 53511
Summary: Basic Windows (Size) Constraints do not work during
resize.
Product: Wine
Version: 6.0.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dev(a)sartrack.nz
Distribution: ---
I am the developer of the SARTrack software (for Windows) for Search and
Rescue.
My Windows-XP compatible program which has multiple 'Forms' (Windows) which can
be opened, and is written in the latest Delphi Pascal compiler.
When running under Wine on a laptop PC with a *ScaleFactor of 2* (two):
- Randomly, the reported 'Constraints.MinWidth' and Constraints.MinHeight are
not scaled (so, set to its original ScaleFactor of '1'. Result: Window starts
to small. Other identical windows in the program *do* have the right
ScaleFactor for the 'Constraints' values. (Timing issue during Create?)
- During resizing of any window, Constraints do not work. Can resize smaller
until nothing left of the window.
- When Width or Height are smaller than the Constraints.MinWidth and
Constraints.MinHeight, the 'OnResize' is no longer called. This means it does
detect that it has reached the limits, but still the window is resized past
these limits.
Bart, New Zealand
--
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=33982
Bug #: 33982
Summary: Steam windows can be resized to 1x1 despite minimum
size
Product: Wine
Version: 1.6-rc2
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: adys.wh(a)gmail.com
Classification: Unclassified
Steam's windows can be resized to 1x1. On Windows they can't. The minimum size
for the main steam window is supposed to be 900x600 and for chat windows
396x351 according to tests.
Using openbox 3.5.0
--
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.
http://bugs.winehq.org/show_bug.cgi?id=13076
Summary: untangle: resize fails
Product: Wine
Version: 0.9.61.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: wine(a)wnoise.ofb.net
After any of the games in Simon Tatham's portable puzzle collection is resized,
it only redraws the portion of the window that is the original size.
Under windows, these games rescale to fit in the new window size.
These may all be downloaded at
http://www.chiark.greenend.org.uk/~sgtatham/puzzles/
and have full source available.
--
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=37864
Bug ID: 37864
Summary: When I resize a maximized MDI window it assumes the
new size instead of remaining maximized
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: ryampolsky(a)yahoo.com
Distribution: ---
Created attachment 50431
--> https://bugs.winehq.org/attachment.cgi?id=50431
Screenshot showing a maximized MDI child after resizing 'unmaximizes' it.
My app is a 'smart terminal' that supports multiple sessions in MDI windows.
The size of the MDI child windows can be changed by the app running on the
server, so at the end of each transaction, if the app has changed the window
dimenensions, I resize the window. If my MDI window is maximized, this has no
effect on a Windows system (except that if I later unmaximize the MDI child, it
will display at the correct new size). But on recent WINE builds (Linux and
Mac), when I resize the MDI child, the window assumes the new size, even though
it's techincally in the 'mdi maximized' state (i.e., the MDI buttons are still
there on the menubar. If I switch between MDI children, they get redrawn
correctly maximized (including the one I just resized).
I coded a workaround in my app where I don't resize the window if it's
maximized, and that seems to work okay under WINE (though I guess the new size
info is getting lost). In any case, that verifies that the problem is
definitely happening in response to my resize operation.
F.Y.I., my resize operation uses SetWindowPlacement() to change the position
and size of the window - specifically because I don't want it to affect the
window if it's minimized or maximized. Only if it's in the normal state.
It's been a long time since I wrote this code, but again, it's always worked on
all versions of Windows. I have a feeling it might have worked a while back in
WINE - though I rarely run maximized, so I may have just recently noticed a bug
that's always been there...
Here's the basic code logic. SizeWindowForScreenDimentions calls
SetWindowPlacement based on the size calculated for the new row/column grid.
The code below has the workaround that prevents the problem in WINE. Also
attached a screenshot showing the unmaximized children with the MDI buttons
still on the menubar.
// If base screen dimensions don't match prior dimensions, resize the window
here.
// (unless mdi-maximized, in which case, doing this unmaximizes in WINE)
if (!mdi_maximized) {
if ((rows != old_rows) || (cols != old_cols)) {
SizeWindowForScreenDimensions(scr, rows, cols, &resizeable);
}
}
// In case window was hidden under an initial popup, show it now.
ShowWindow(scr->hScreenWnd, SW_SHOW);
--
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=7007
Ken Sharp <imwellcushtymelike(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |imwellcushtymelike(a)gmail.co
| |m
--- Comment #21 from Ken Sharp <imwellcushtymelike(a)gmail.com> ---
This seems to work for me with Wine 9.9. Can someone else check this?
--
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=52515
Bug ID: 52515
Summary: Resizing/maximizing foobar2000 has stale rendering
errors (more in Light Blue theme)
Product: Wine
Version: 7.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: nyanpasu64(a)tuta.io
Distribution: ---
Created attachment 71815
--> https://bugs.winehq.org/attachment.cgi?id=71815
Screenshot of list header, scrollbar, and resize handle rendering incorrectly
- Install foobar2000 v1.6.9.
- (optional) In winecfg, switch to Light Blue theme, then open foobar2000.
- In "Quick Appearance Setup", pick "Album List + Properties".
- Add some files to the playback list (preferably enough for a vertical
scrollbar).
- (Optional) Press Ctrl+N to show playlist tabs.
- Resize and enlarge the window slowly horizontally. Then shrink the window
horizontally, and tile or maximize the window (expanding it quickly).
When resizing the window slowly, you will get vertical lines in the sort
header, and stale resize handles in the window's bottom right corner (faintly
visible). When maximizing the window, a scrollbar will mistakenly render in the
song list (which remains when resizing the window further, moves when you
scroll the song list, and gets cleared when you select/deselect the songs
behind it). I also saw entire stale tabs to the right of real tabs, but was
unable to replicate this bug.
On (No Theme) and Light "Classic Blue", when maximizing, the glitched scrollbar
rendering occurs as well. When resizing slowly, the stale resize handles are
*more* visible, but the vertical lines do not occur.
Confirmed on Xfce and KDE Plasma X11, with X11/Wine running at 96 and 120 DPI.
Video at https://youtu.be/jch76UQpn2w.
I assume this is a Wine rendering bug, but perhaps it could be a foobar2000
redrawing bug, or an interaction between Wine and foobar2000's redraw events.
Operating System: Arch Linux
Kernel Version: 5.16.4-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2 (proprietary drivers
470.103.01)
--
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=53805
Bug ID: 53805
Summary: Photoshop is crashing... and it's annoying.
Product: Wine
Version: 7.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: choord(a)protonmail.com
Distribution: ---
Created attachment 73312
--> https://bugs.winehq.org/attachment.cgi?id=73312
This is only the backtrace gived by WineHQ
I want to use Photoshop with Wine, as it is the only program I really know well
about. I come from Windows and I really need help because I can use a little
bit Photoshop, but after some minutes, or on clicking on some buttons (it can
be random), the application just crash, which make it useless for making
picture editing.
Thanks for your reply, and if you know how to fix this problem, please reply to
my email adress ! (choord(a)protonmail.com)
--
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.