http://bugs.winehq.org/show_bug.cgi?id=10112
Summary: BitBlt between 8 bit color index DIBs wrong
Product: Wine
Version: CVS/GIT
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-x11driver
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: alexd14(a)hushmail.com
Created an attachment (id=8678)
--> (http://bugs.winehq.org/attachment.cgi?id=8678)
test case
BitBlt from one 8 bit DIB to another 8 bit DIB produces wrong results. I'll
attach a simple test case that illustrates the problem. What it does: creates
two 8 bit, color index dib sections with a color table where color index 1 =
red, 2 = blue, 3 = green. Then it fills first DIB with 1 (red) and second with
2 (blue). It then does a BitBlt with SRCPAINT (OR) ROP from first DIB to
second. Finally, this DIB is drawn in a window, and a hex value of the first
pixel is drawn over it for convenience.
In such BitBlt Windows, apparently, operates on DIB pixels as color index
values w/o palette lookup; 1 OR 2 == 3, so it fills destination DIB pixels with
3, and, consequently, it is displayed as a green rectangle.
In Wine, this operation works like actual RGB values (red and blue) from
palettes are getting combined, and it's displayed as a magenta rectangle.
Probably, because wine seems to convert it to truecolor pixmaps internally.
Pixels as stored in memory become zeros.
Real app affected by it: igonwin.exe in bug #201
(http://bugs.winehq.org/show_bug.cgi?id=201). I don't have other apps that use
color index dibs to test, but I think any apps that use such DIBs AND "fancy"
ROPs (XOR, AND, OR etc) may be affected.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10910
Summary: winealsa and PulseAudio
Product: Wine
Version: 0.9.51.
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-binary
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: atari(a)gabo.pl
winealsa is unable to work with PulseAudio.
This is my /etc/asound.conf:
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
This is registry entries for Alsa configurations:
REGEDIT4
[HKEY_CURRENT_USER\Software\Wine\Alsa Driver]
"AutoScanCards"="N"
"AutoScanDevices"="N"
"DeviceCount"="1"
"DeviceCTL1"="pulse"
"DevicePCM1"="pulse"
"UseDirectHW"="N"
And I get this error in wine log:
err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element
I tracked it in wine source code to file dlls/winealsa.drv/alsa.c
With following comment:
/* Setup and find an element id that exactly matches the characteristic we want
** FIXME: It is probably short sighted to hard code and fixate on PCM
Playback Volume */
Unfortunetly I know to little about Alsa to fix it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=11109
Summary: dream of mirror online crash
Product: Wine
Version: 0.9.52.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: petifrancais(a)gmail.com
Created an attachment (id=10143)
--> (http://bugs.winehq.org/attachment.cgi?id=10143)
txt contenant les erreurs en console
The game game domo crash after the logo "GameTribe"
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=11077
Summary: does not find a serial port while running this
application under wine
Product: Wine
Version: unspecified
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: only4john(a)gmail.com
Environment: wine under Ubuntu 7.10
Hardware Device: IRISYS 1001 thermal imager
(http://www.entherm.com/Irisys/IRISYS%20Thermal%20Imager.htm)
Driving Application: http://only4john.googlepages.com/Imager3309.exe
The Driving Application can not find serial port while running the application
under wine, while the PC has a serial port.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=11419
Summary: Installation of Intel Indeo Video freezes
Product: Wine
Version: 0.9.54.
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: ole
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: elicoten(a)live.co.uk
Installation gets upto "searching for components: Netscape", and about 9% on
the progress bar then freezes. Cannot be installed.
--
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=11239
Summary: Steam Games No Longer Start - bisected the cause to
ntdll
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: philcostin(a)hotmail.com
The following patch, introduced on Jan 15th 2008 has resulted in Steam games
being unable to start.
bd352bcd1c98ed91bdb337e73cddfd8ceac095d6
err:seh:setup_exception nested exception on signal stack in thread 004f eip
7efc20b3 esp 7ffdb770 stack 0x241000-0x350000
--
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=10273
Summary: satisfy SafeDisc 2.x heuristic API analyzer by
"adjusting" API exports/entry statistics of wine
builtins
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8924)
--> (http://bugs.winehq.org/attachment.cgi?id=8924)
Patch which should fix SafeDisc 2.x copy protection api analyzer issue
Hello,
if not interested in technical details goto (2) ;-)
I made this a separate bug report like
http://bugs.winehq.org/show_bug.cgi?id=9925 (SafeDisc 1.x stopper) because
SafeDisc has many flavors that differ in various technical ways and can't be
discussed/handled in a single SafeDisc "metabug" like
http://bugs.winehq.org/show_bug.cgi?id=219
SafeDisc Major version based separation allows better tracking of "completion"
state (1.x/2.x/3.x/4.x).
-----------
(1)
It took me a couple of days to get an idea what SafeDisc 2.x really does with
the API exports and to find a way to cope with it...
Various anti-debugging techniques and nasty runtime code obfuscation made this
journey somewhat challenging.
Parts of SafeDisc 2.x analyze the API code of the following system libraries:
kernel32.dll (wine builtin)
user32.dll (wine builtin)
gdi32.dll (wine builtin)
cdasdtst.dll (developer backdoor?)
The latter one is probably a "developer backdoor", used to verify their
code/algorithms (not needed to be present).
For each of these libraries all named exports are taken into account.
A number of API entry opcode sequences are read and used for statistical
analysis (number depends on type of encountered opcodes).
>From what I've seen there is some kind of "behavioural probability" of each API
entry calculated, with typical opcode sequences having a "weighting".
Just think of advanced heuristic detection methods of antivirus scanners and
you get the idea ;-).
Anyway, wine's builtin libraries differ in their signatures from windows entry
code and to make things worse, wine's +relay/+snoop feature heavily interferes
with the analyzer results. :-(
First I made some experiments with additional (dummy) function exports, small
__asm__ wrappers with opcode sequences to see how the distribution of opcodes
influences the analyzer results.
The result was rather disappointing.
I needed a large number of exports to gain some results but not significantly
enough to get below the "bad" threshold.
Then I came across the magic "0" value. As soon as I used this value either as
first .byte on API entry or init value for data export, the entry scan was
short circuited.
This value seemed to have the highest influence of all code/data sequences
used.
I added quite a number of data exports - aliased to initialized "0" value -
safe enough to let even wine's +relay work (remember: relay code influences
analyzer).
If you look at the patch don't get mad ;-)
You will see a crapload of named "__wine_safedisc2" data exports/aliases added
to wine builtin kernel32, user32 and gdi32.
For the record: http://bugs.winehq.org/show_bug.cgi?id=9926 which talks about
"problematic" gdi32 data exports (pfnPalette stuff) in SafeDisc 3.x.
SafeDisc 2.x code triggers SEH upon exported function pointers too but this is
gracefully handled. No harm at all.
I wonder if this is really a problem in SafeDisc 3.x ...
I thought about other possible solutions but found no one easier to implement
to prove my findings without hurting wine too much :-)
Making wrappers of the whole kernel32, user32, gdi32 named exports API just to
please the entry analyzer is not an option to me.
Another way could be the relocation of export table upon module loading,
expanding it at runtime by adding the required number of "statistics fakers"
(data exports with zero init).
This requires modifying the ntdll loader .. though i'm not sure if this
approach breaks other applications/braindamaged PE protection stuff which
expect certain conditions to be met (tables present at specific sections/memory
areas).
------------------------------
(2)
Well, take it as proof of concept. Play with it.
I tested my patch with a few SafeDisc 2.x games I have original media.
No cracks/no-cd patches were used.
Only official game patches were used.
Battlefield 1924 (1.6x) - SafeDisc 2.6/2.8
Road To Rome (BF1942 expansion) - SafeDisc 2.8
Battlefield Vietnam - SafeDisc 2.9
All of these work fine for me with the patch applied.
Please test this patch on many SafeDisc 2.x games as possible and report your
results (works or works not).
Make sure you have original media mounted and drive/data is visible within
wine.
If it fails for first time, the media might not ready yet, try again then (I
experienced this sometimes).
Use this link to verify what SafeDisc Version is used:
http://www.120search.net/ (alcohol software copy protection database)
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9798
Summary: bioshock demo needs glsl enabled
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8240)
--> (http://bugs.winehq.org/attachment.cgi?id=8240)
crash log with glsl disabled
Hello,
Bioshock demo crashes if glsl is not enabled.
Attached are relevant traces made with:
WINEDEBUG=+seh,+tid,+d3d,+d3d_shader wine ./Bioshock.exe -dx9
Using following registry settings enables bioshock demo to run:
--- snip ---
HKEY_CURRENT_USER/Software/Wine/Direct3D
UseGLSL = "enabled"
--- snip ---
Optional: OffscreenRenderingMode = "fbo"
==================
Addendum:
wine --version
wine-0.9.45-406-g2ba3247
Currently uses secuROM hack (http://bugs.winehq.org/attachment.cgi?id=8235
) to run, see http://bugs.winehq.org/show_bug.cgi?id=7065
Be sure to include "-dx9" command line to work around directx 10 issue.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10225
Summary: SafeDisc 2.x triggers async device ioctl status code
propagation bug in wine server
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8843)
--> (http://bugs.winehq.org/attachment.cgi?id=8843)
relevant trace which shows ioctl status code propagation bug
Hello,
while testing my proof-of-concept patch which makes SafeDisc v2 (yuck!) finally
work, I stumbled across a nasty ioctl status code propagation (completion) bug
in wine server.
Wasted several hours on it .. I was suspecting SD issue whole time, but its a
wine server bug :(
Attached is relevant trace (WINEDEBUG=+seh,+tid,+relay,+ntoskrnl,+server wine
./BfVietnam.exe)
Before the bug is triggered, the SafeDisc security driver makes several device
ioctl requests which return 0xC0000001 (unsuccessful) on purpose, e.g. reading
debug Drx registers with index that does not exist.
This is intended to fool reversers :-)
The next operation - checking IDT entries should succeed - but does not (as
seen from calling client).
The kernel driver completes the operation successfully and returns
irp.IoStatus.u.Status == 0 with xxxx bytes in output buffer.
I verified it several times by debugging the kernel driver.
Upon driver ioctl call return, get_next_device_request() is triggered again in
ntoskrnl event loop which sets the return data (and status code) ->
set_ioctl_result().
This queues an APC, waking up the client (alertable state).
The client process device ioctl completes with 0 (FALSE) which is wrong.
Further debugging showed that ioctl_completion APC (dlls/ntdll/file.c) returns
the errornous status code in get_ioctl_result() when woken up by server.
This error is then propagated in server_ioctl_file() to result in wrong
NtDeviceIoControlFile() return code.
What puzzled me is that "ioctl->status" is correctly set by set_ioctl_result()
(=0) but get_ioctl_result() - called within client context - yields the
previous error code (0xC0000001 of failed request).
This is either a problem of global vs. thread local error status (global_error
vs. current->error/thread) or the ioctl call data is the wrong one.
The following patch works for me, letting SD 2.x continue - though i'm not sure
if it's right:
--- snip ---
diff --git a/server/device.c b/server/device.c
index 46b2796..8fe8f7c 100644
--- a/server/device.c
+++ b/server/device.c
@@ -528,7 +528,7 @@ DECL_HANDLER(get_ioctl_result)
ioctl->out_data = NULL;
}
}
- set_error( ioctl->status );
+
list_remove( &ioctl->dev_entry );
release_object( ioctl ); /* no longer on the device queue */
}
--- snip ---
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10293
Summary: sequentially running games/apps with different SafeDisc
versions fails
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8945)
--> (http://bugs.winehq.org/attachment.cgi?id=8945)
Patch which fixes various isses regarding kmode driver unload/reload
Hello,
currently wine's kernel mode driver cleanup/unloading facility has several
issues when it comes to applications/games that unload and reload different
driver versions on the fly.
Example: run multiple SafeDisc 2.x, 3.x and 4.x games sequentially.
Symptoms: game either hangs/crashes/exits silently
Usually the SD security driver is placed in
"c:\windows\system32\drivers\secdrv.sys"
If a SafeDisc protected program encounters a driver version that is
incompatible it does the following:
- stop the current security service (should unload the driver)
- unpack own security driver from resources to temp storage and move the binary
to "c:\windows\system32\drivers\secdrv.sys", overwriting the previous
- restart the service (loads the new driver)
This currently fails for various reasons:
(1)
The driver binary is loaded using LoadLibrary() -> the matching FreeLibrary()
is missing on service stop.
This leads to sharing violation when the driver binary going to be replaced
(CopyFile fails).
(2)
No driver unload routine called. Very problematic.
Various objects (symlinks) created by driver entry are not freed.
When the driver is reloaded the init routine usually fails with "object
exists".
(3)
Driver state objects (driver_obj, driver_extension) have undefined state due to
static storage.
Raises all sorts of problems because the driver entry routine does not init all
fields.
---------
Attached is a patch which fixes these problems, allowing to sequentially run
programs with different SafeDisc Versions.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.