wine, apihooks, and diablo 2

[Vladimir Vukicevic]

Howdy.. I've been trying to get the battle.net aspect of Diablo 2
working with wine in the past few days.  I've been attempting to do so
with both transgaming's latest winex CVS HEAD and also wine's CVS HEAD,
to similar results.  As you probably know, right now Diablo 2 runs just
dandy assuming you only want to play single-player.  There are two ways
to play multiplayer: the normal d2 way, executing Diablo II.exe with the
D2 Play CD in the CDROM, or using a "no-cd" patch.  Neither of these
approaches currently work with wine. (Currently, to play, you appear to
have to use the "no-cd" patch in any case, but you end up only using
half the patch -- I'll explain below.)

If I attempt to play with the CD, using "wine -- 'Diablo II.exe'" (with
or without -win argument to D2), after a few seconds, the CPU is spiked
and no output occurs.  Watching a +trace output shows that it is
executing Game.exe (the main game driver), but then things go wonky.
(Incidentally, I can't figure out how to get a debugmsg flag on
processes created from a wine process.. is there a config option?)  It
certainly hasn't started looking at the cdrom (as per strace).

The no-cd case is more interesting.  There are typically two parts, one
a driver called 'DLoad.exe' and then the game-replacement, called
'game_crk.exe'.  To play single player, 'game_crk' can be invoked
directly (with a -win arg if necessary), and things work great.
However, on attempting to play on battle.net, it complains that it can't
recongize the version.  This is where DLoad is required.  From examining
DLoad, it appears to use the ApiHooks toolkit, available at
http://www.anticracking.sk/EliCZ . This basically provides the
programmer with a simple way to insert his or her own wrapper between an
app and functions it calls in a DLL.  Simple enough, it seems.  However,
to do so, it takes advantage of VirtualAllocEx to allocate memory in the
target process, which wine seems to not support. (It also calls
VirtualAlloc with a flag value of 0x8001000 -- the 0x8000000 part being
unknown.  I couldn't find any info on MSDN, so I just hacked wine to
strip this bit out if it sees it -- anynoe know anything about this?)

so, I'm wondering if anyone has any insight or pointers into either of
these two issues, or any suggestions on which one would be easiest to
tackle.  I would prefer to tackle the first one (the with-CD case)
initially, as it seems a bit simpler and cleaner.  But we'll see.

thanks,
    - Vladimir