http://bugs.winehq.org/show_bug.cgi?id=8947
jeremielapuree(a)yahoo.fr changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From jeremielapuree(a)yahoo.fr 2007-15-07 04:26 -------
Exact. Bug is fixed in wine-0.9.41.
One can close this bug as fixed.
Joaopa
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8960
------- Additional Comments From vanessaezekowitz(a)gmail.com 2007-15-07 04:24 -------
Hi all. I'm Abe's wife and the admin for our computers . I am an (inactive) open-source programmer
(old 8-bit computers only), and from that standpoint, I have to say this: I am thoroughly disappointed
at the way this issue was handled. Rather than ask for a regression test or just more details - even
a date when the bug first became apparent - you closed the bug, marked it as invalid, and mad it to
sound as though this never worked. This is NOT how the FOSS community is supposed to work;
developers always kept telling us users to file bug reports and keep on top of them, but when we do,
we're essentially told to kiss off.
So, rather than get all up in arms, I took the initiaive and did a sort of regression test myself. We
currently have two machines - Abe's box has v0.9.41 installed, mine ran 0.9.37 initially. There are
many differences between the two machines, but both have the same motherboard and use nVidia
cards. Neither card's driver supports GLX in 8bpp mode, and apparently, neither of them ever has.
So... using my machine as a testbed, starting with v0.9.37, with no windows files of any sort
installed, I created a fresh new Drive-C directory (/home/vanessa/Drive-C), configured wine to use it,
turned both D3D accelleration settings to "hardware" just to see if it breaks things, established an
800x600 virtual desktop, and told wine not to use my window manager to control the windows
display. Following this, I ran `wineprefixcreate` and then installed the game from the CD.
When the installer finished, I openend a second X session with the command: `X -depth 8 :2`,
exported my DISPLAY variable to point to that display, opened a terminal and started twm on that
display, switched my console over to that screen, and then ran the game from the terminal.
Here is a summary of my findings from that regression test, using my machine as the test bed, and
using the game as I first installed it under wine v0.9.37:
v0.9.37: PASS. I get the same GLX errors that Abe got, wine desktop opened, game intro video
started playing (in monochrome, but should be in color), then a normal-looking game splash screen
appeared inside when I hit a key. The game select menu and the various tables all worked fine.
v0.9.38: PASS. Exactly the same results as with v0.9.37.
v0.9.39: FAIL. I get a few GLX errors, different from before, The wine desktop appeared, then
closed. No part of the game's graphics ever appeared - not even the splash screen.
v0.9.40: FAIL. Appeared to be exactly the same results as with v0.9.39.
v0.9.40: FAIL (with both D3D hardware accel settings turned off). Same as the first v0.9.40 test.
v0.9.40: FAIL (with both D3D hardware settings turned off, and DirectDrawRenderer explicitly set to
"gdi"). Same as the first v0.9.40 test.
v0.9.41: FAIL (on Abe's box, did not test on mine). Appears to be the same issue as v0.9.39/40.
Attached to this report is an error log covering all four tests (divided into sections of course). Just to
be sure, I went back to v0.9.38. PASS - the game works fine.
Again I stress - the commercial version of Microsoft Pinball Arcade RUNS just fine WITHOUT GLX in
v0.9.38 or earlier, which means you guys broke something in v0.9.39. A bug is defined as a feature
that doesn't yet work, or that once implemented, quits working for no apparent reason.
This appears to have nothing at all to do with the 0.9.15->0.9.16 transition, as that took place nearly
a year ago (September 2006).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7512
------- Additional Comments From amurphy7701(a)yahoo.com 2007-15-07 03:10 -------
With the last 0.9.41, and the UNICODE corrections that might be committed,
Imgburn doesn't even launch anymore!
I get a "Internal Error: SubClassUnicodeControl.Control is not Unicode." error
from Imgburn, before it crashes.
It seems that wine Unicode code is still not fully Windows compliant.
On the console, nothing but read access violation and a CPU register dump.
I must say that it was tested on a fresh install (new .wine dir).
By the way, when running in Windows 98 profile, Imgburn launches well (but is
unusable because SPTI is not available on 98).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8963
Summary: Burn/verify don't work anymore
Product: Wine
Version: 0.9.40.
Platform: PC
URL: http://www.imgburn.com/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: test
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: amurphy7701(a)yahoo.com
A new bug appeared on the last versions of wine (at least 0.9.40, 0.9.41 is
affected by another bug preventing imgburn to launch).
The app launches well, the bug appears on the moment you push the burn button,
in Verify and Write modes.
At this moment, the app prepares the buffer, and is meant to prepare the
hardware to do the task. The log window is filled normally, but the main
windows, that is supposed to get in "burning mode" display, resets itself and
abort the operation.
Usually, just after this reset, a popup appears, about an access violation. This
popup multiply itsef so the only thing left to do is to kill the process.
>From the log the wine complains about some CDROM commands.
Maybe a recent change in the SPTI handling broke imgburn under wine.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8625
------- Additional Comments From amurphy7701(a)yahoo.com 2007-15-07 02:47 -------
I just tested with freshly released 0.9.41, and the bug is still here.
Windows 2000 profile, on a clean install (.wine recreated from scratch).
0.9.34 still is the last exploitable wine version for this useful piece of software.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8960
------- Additional Comments From aezekowitz(a)gmail.com 2007-15-07 01:44 -------
I'll guess I'll stick to a dual boot. It's clear that I'm not getting my message
across, or you folks just don't care about older software. FYI here is the URL
for the game in question: http://www.microsoft.com/games/pinball/sysreq.htm.
Bear in mind, I am using the full commercial version, not the freebie download.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8960
vitaliy(a)kievinfo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Additional Comments From vitaliy(a)kievinfo.com 2007-15-07 00:51 -------
closing again. Wine's DDraw/D3D/OpenGL _does_ require GLX. If your hardware
doesn't support it - then you can not run those programs in Wine.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.