http://bugs.winehq.org/show_bug.cgi?id=7065
Stefan Dösinger <stefandoesinger(a)gmx.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stefandoesinger(a)gmx.at
--- Comment #30 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2007-09-27 12:09:43 ---
The hack works for me with Settlers 2 TNG, nice work
--
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=7065
--- Comment #29 from Anastasius Focht <focht(a)gmx.net> 2007-09-27 12:09:23 ---
Created an attachment (id=8235)
--> (http://bugs.winehq.org/attachment.cgi?id=8235)
securom hack/patch
Hello,
upon request I attached a small patch (hack) to fix secuROM show stoppers.
This is considered "hack" and only intended for testing purposes.
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=4729
Dan Kegel <dank(a)kegel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #21 from Dan Kegel <dank(a)kegel.com> 2007-09-27 11:46:06 ---
It's back! All of Photoshop 6, CS, and CS2 now
have this hang. To reproduce, start the app, do File / New
to create a new image, draw a bit with the brush tool,
then resize the layers window by dragging an edge.
Bammo, all of X locks up.
The regression seems to be caused or exposed by the fix
to bug 9697. Reverting that patch makes this bug go
away again.
--
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=8770
Baum ranger <baumhaus691(a)onlinehome.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |baumhaus691(a)onlinehome.de
--- Comment #22 from Baum ranger <baumhaus691(a)onlinehome.de> 2007-09-27 10:55:14 ---
Roderick Colenbrander asked earlier if that would be an openGL or an Network
problem. It seams to be a problem with Bnet (network). When ever I play an
offline game or on the LAN Warcraft works like a charme. But when I start a
Bnet-Game it crashes during the loading process. Doesn't matter if I try it in
OpenGL-Mode or in D3D-Mode.
My system:
- Ubuntu Feisty 7.04
- Intel Graphic
- Different Wine Versions (right now 0.9.44)
- Different desktop environments (Gnome/KDE/XFCE)
Anybody got something about this issu?
I realy want to play on the Bnet again! It is driving me nuts.
I realised that many people who have this issu seam to have ubuntu feisty.
--
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=8089
Brian Polidoro <polidobj(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |polidobj(a)yahoo.com
--
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=7065
--- Comment #28 from Anastasius Focht <focht(a)gmx.net> 2007-09-27 10:28:49 ---
Hello,
the issue you see is directx 10 related (dxgi.dll).
If you don't believe, run with +seh,+tid,+loaddll,+relay to see yourself where
the exception comes from.
Again: Not a secuROM issue.
Please make sure you start the bioshock demo either with "-dx9" command line
switch or disable load of builtin "d3d10.dll" (winecfg)!
There are enough dx9 bugs waiting to be fixed ... ;-)
Please do not use this bug id if you are NOT absolutely sure it's secuROM
related.
Open separate bug reports for each game bug you now encounter.
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=7065
--- Comment #27 from Luke Bratch <l_bratch(a)yahoo.co.uk> 2007-09-27 10:23:42 ---
Apologies, I did not try with -dx9, which does indeed get it as far as failing
on DX stuff.
--
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=7065
--- Comment #25 from Luke Bratch <l_bratch(a)yahoo.co.uk> 2007-09-27 10:08:25 ---
Thank you very much for your work Anastasius!
I have tested this with both the Bioshock Demo and the Crysis Beta.
Crysis Beta loads flawlessly (and is stopped later on by network issues, that's
another story) now.
Bioshock Demo however doesn't even seem to get as far as DX bugs, I'll attach
my output, I wonder if this is different to what you get?
--
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=7065
--- Comment #24 from Anastasius Focht <focht(a)gmx.net> 2007-09-27 09:31:47 ---
Hello,
ok, I tested more game demos which suffer from same issues mentioned in this
bug report.
Most of the game demos employ late securom versions (7.x) but I think I got all
show stoppers for now.
Beware: some demos suffer/die very quickly due to wined3d/dx related bugs.
Don't blame me on it ;-)
I tested my workarounds with the following demos mentioned in this bug report:
"Bioshock" (dies due to dx bugs, even with "-dx9")
"World in Conflict" (same, dies due to dx bugs)
"Tomb raider anniversary"
"UFO: Afterlight"
=====
The 800x error codes are related to PEB/process flags and heap flags checked by
securom protection.
It's not much fun to debug the code due to obfuscation and code splicing
techniques. Anti-debugging tricks everywhere to make life a misery.
Down to the metal ... what does the protector actually complain about?
I removed obfuscation instructions and added some comments for better
understanding of the code snippets.
"NtGlobalFlag"
--- quote ---
mov eax, fs:[18h] ; get TEB
mov eax, [eax+30h] ; get PEB
mov eax, [eax+68h] ; PEB->NtGlobalFlag
test eax, 70h ; if set -> debugged (FLG_HEAP_ENABLE_FREE_CHECK |
FLG_HEAP_ENABLE_TAIL_CHECK |
FLG_HEAP_VALIDATE_PARAMETERS)
--- quote ---
This is fine so far.
Wine does not use this field (unlike windows loader) and initializes it to
zero.
"Heap Flags":
--- quote ---
mov eax, fs:[18h] ; get TEB
mov eax, [eax+30h] ; get PEB
mov eax, [eax+18h] ; PEB->ProcessHeap
mov eax, [eax+0Ch] ; ProcessHeap->Flags
test eax, 60h ; if set -> process is debugged (remark: bit 1 is even set when
not debugged = HEAP_GROWABLE)
--- quote ---
"Force Flags":
--- quote ---
mov eax, fs:[18h] ; get TEB
mov eax, [eax+30h] ; get PEB
mov eax, [eax+18h] ; PEB->ProcessHeap
mov eax, [eax+10h] ; ProcessHeap->ForceFlags
test eax, eax ; if set -> process is debugged
--- quote ---
If one is really interested in the meanings/workings of these flags, read up
MSDN documention about global flags/loader (pietrek columns) and play with the
neat "gflags.exe" utility which comes with debugging tools for windows.
Basically the flags are all set by loader when a process is initialized.
Because of the flags, debug heaps and the like are used for tracking down app
heap related problems.
PEB.NtGlobalFlag = 0x0 if the process is not debugged.
PEB.NtGlobalFlag = 0x70 if debugged (FLG_HEAP_ENABLE_TAIL_CHECK |
FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS)
(can be overridden by registry settings, read MSDN or play with gflags.exe)
If PEB.NtGlobalFlags == 0x0 (not debugged) then
PEB.ProcessHeap.Flags = 0x0 or 0x2 (HEAP_GROWABLE)
PEB.ProcessHeap.ForceFlags = 0x0
If PEB.NtGlobalFlags > 0x0 (process debugged) then some flags are copied to
PEB.ProcessHeap.Flags > 0x2 (HEAP_GROWABLE | xxxx flags)
PEB.ProcessHeap.ForceFlags > 0x0 (flags copied here too)
=============
Ok, to make securom happy about the 800x error we have to do the following:
Make sure PEB.ProcessHeap.Flags and PEB.ProcessHeap.ForceFlags exist as fields
in wine internal process HEAP structure and initialize them accordingly.
This is the comment from wine "dlls/ntdll/heap.c":
--- quote dlls/ntdll/heap.c ---
/* Note: the heap data structures are based on what Pietrek describes in his
* book 'Windows 95 System Programming Secrets'. The layout is not exactly
* the same, but could be easily adapted if it turns out some programs
* require it.
*/
--- quote dlls/ntdll/heap.c ---
Uhm well .. talk about "easily adapted" ;-)
Unfortunately parts of code make assumptions about the HEAP structure
layout/field offsets when creating and initializing heaps/subheaps e.g.
HEAP_CreateSubHeap() and HEAP_InitSubHeap().
Just adding some fake variables to HEAP structure to force the field offsets
does NOT work without further code changes (SUBHEAP is expected to be the first
field member)!
To test the findings with minimal (non intrusive) code changes, use the SUBHEAP
structure itself.
Just pad the structure with DWORD's to leave room for these fields:
--- snip dlls/ntdll/heap.c ---
typedef struct tagSUBHEAP
{
/* HACKHACK */
DWORD pad1; /* ofs+0 */
DWORD pad2; /* ofs+4 */
DWORD pad3; /* ofs+8 */
DWORD Flags; /* [ofs+0C] = 0 to make securom happy */
DWORD ForceFlags; /* [ofs+10] = 0 to make securom happy */
DWORD align8;
/* HACKHACK */
DWORD size; /* Size of the whole sub-heap */
DWORD commitSize; /* Committed size of the sub-heap */
DWORD headerSize; /* Size of the heap header */
...
--- snip dlls/ntdll/heap.c ---
In a real implementation the "/* HACKHACK */" fields would belong to (primary)
HEAP structure.
You can use the space of DWORD pad1-3 as you like, just make sure the DWORDs at
offsets 0xC and 0x10 exist.
The additional "align8" DWORD is used for alignment. Some wine code barfs if
alignment is not forced (HEAP_FindFreeBlock).
Due to default initialization these fields get initialized to zero and that
makes securom happy.
Well - at least for this case :|
==================
Now having worked around 800x errors, we jump into next one:
--- snip ---
"A required security module can not be activated. This program cannot be
executed (7000)" Error
--- snip ---
This error occurs when SecuROM has found one or more CD/DVD emulation tools
running.
Well thats not the case in wine. Further tracing/debugging shows that securom
populates some registry keys:
"HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi" ...
and
"HKEY_LOCAL_MACHINE\System\MountedDevices" ...
The latter one does not exist.
Simply creating the Key "MountedDevices" makes securom happy.
==================
And? Well. That's all - the game should start now ;-)
Be aware I did not test any "retail" stuff which comes with real CD/DVD media,
just the "media-less" demos.
Have fun filing bug reports for real game issues (hint:
WINEDEBUG=+d3d,+d3d_shader,...")
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.