Manalink C/ASM Dll

[Ghost]

yea the deckdll file which i gave the c for is only a little bit known. in the original game there wasent an option for a new cardset so mok originally added the extra red button on the left. when he did this he recreated the whole file and thus changed the system so he could code it better to what he knew which was asm i believe.

Cool, thats pretty useful and might still help us understand more stuff. Also, working together with the original might give us insight on before and after those changes.

i helped some peeps change the .pic files of the deckbuilder to .bmps cause the game was already using .bmp's in it already but the code was in magic.exe. so the jump was added so that is also why you can no longer open up just the deck builder alone. it needs code from magic.exe to run the bmps. as for changing the deckbuilder there was only cosmetic differences changed.

oh, so thats why the jump was added? i thought it related to the 2000 limit. (someone mentioned a previous limit then a jmp to bring it to 2000, which seems very strangely arbitrary to not simply go to "over 9000" =))

the fallen empires land and whatnot was already in the game just not enabled. fallen empires was later coded into the manalink.csv but never really coded except for some cards now.

Just curious, after the enable where would those cards appear? I mean the ones that were already hidden in the game.

And the ones you coded in manalink.csv they appear under the red button? and when you say coded you mean the entire listing is there but not the actual mechanics of the cards or neither the listing? You see Im not really familiar with your version, I'll turn on my desktop pc and take a look, IF it didnt went down with the burnt HD =(

Ghost.

[gmzombie]

i believe its both for the manalink.csv due to it not being in the game cause its not coded. it will however show up in the manalink.csv. that was me who said it. here is the info i got on the update
"I have made these changes by editing the raw assembly code for the Magic game, and tested stability myself for Single Player and sealed games. Although I've tried to be thorough, there are almost certainly things I've missed, which is bound to increase the number of 'random' crashes.
- I am sure that the 30,000 limit in the new array size will not be acheivable. I can see that there are other limits in the game that will likely kick in at more like 3,000 cards or possibly even less. Still, this mod has definitely created more usable space!"
that was from skymarshal and unfortantly when manalink.de went down a couple years back we lost him. that site never came back and we havent heard from him since. Harry pitfal was the other one who helped get through the first limit but he is off doing other projects now and has no time for manalink.

[gmzombie]

http://home.comcast.net/~gmzombie/deckoriginal.rar
pre mok magic deck.exe asm and c
http://home.comcast.net/~gmzombie/dueloriginal.rar
pre mok duel.exe asm and c
http://home.comcast.net/~gmzombie/deckdlloriginal.rar
pre mok deckdll.dll asm and c
http://home.comcast.net/~gmzombie/magicoriginal.rar
pre mok magic.exe asm and c

here is the pre mok game asm and c disassembly.

[foolosopher]

Hi guys, I just saw the message from gmzombie and run to our topic, which sure stirred things up. Ghost welcome on board .Now to work.
I had a very quick look at your comments so I 'll be brief for now.
I have little knowledge of asm that's why I disassembled the .exe to c, so as to be able to work with it.
From what I got from IDA there is a lot of code with errors but it's in c or pseudo c and many of the errors are mostly due to conventions of IDA when disassembling.
BUT if you check the code you can find many functions that have card names so I guess we can skip all that code for now (good idea gmzombie ).
Another major error producer (to me at least) is __usercall. From what I found so far there are about 1500 __usercall function declarations, which use asm notations that produce errors.
Anyway I found a way to circumvent or even fix them by replacing them with wrapper functions that simply omit the asm notations. Unfortunately the declarations of these functions are commented out, so it's taking me some time to replace all that. Oh, placement of the wrappers reduces the errors but adds warnings, but I 'll deal with these later.
For decompilation I used the last stable version where multiplayer over the net was working decently March 29 2009.
The idea of working on vanilla code is good also. Anyway, I 'll get back on it tomorrow as I have to get some sleep for now. So... goodnight for now

[foolosopher]

OK you got my curiosity going, so I tried to compare pre and post mok dis-codes (in c) that gmzombie uploaded, BUT its a LOT of lines that are also displaced while being disassembled causing the files to appear much more different than they actually are.
If you know a really good file comparing program now's the time to say it. I 'm using the compare utility of notepad++. Araxis Merge is quite good and has a 30 day trial.
I also split the files into chunks of 10000 lines each.
Anyway we need to come up with a plan and stick to it if we are to make our effort worthy (and convince more to help us).
So I would propose this (suggestions are welcome):

dedicate a section at the wiki to post our findings and instructions

1)for achieving functional c code,
- work mostly with the c code
- keep debugging (partly done, long way to go)
- focus mostly at first in magic.exe-c-asm
- remove cluter card code where possible
- rewrite non-functional code where required
- re-insert removed cluter card code
- examine and connect to the dlls, other libraries

2)for finding the 2000 limit
- compare pre and post mok c code
--share the chunks between ourselves (Ghost,mzombie, me-foolosopher, other volunteers ). Keep in mind that since the code is scattered we should look between diferent chunks after we have tidied up our chunks a bit.
- look for 2000, 7d0 occurences, relative function calling etc. (partly done)
- testing, researching, testing, researching,

3) other mods (after achieving functional c code)
- improve AI
- whatever else we can think of...

OK this is me brainstorming, but it was more or less what I had in mind, but like I said at the beginning suggestions are welcome.
One thing, I haven't tried to compile the produced asm, I just know that the exe->asm produced no errors.
I also found a perl script that is supposed to produce C++ code from produced IDA asm, but haven't tested it.

[foolosopher]

One more thing,
I found several functions starting with j_..., is it possible that jatill had something to do with this or am I imagining things?

[jatill]

One more thing,
I found several functions starting with j_..., is it possible that jatill had something to do with this or am I imagining things?

Nope, I didn't do that.

[Ghost]

Hi guys, I just saw the message from gmzombie and run to our topic, which sure stirred things up. Ghost welcome on board .Now to work.
I had a very quick look at your comments so I 'll be brief for now.
I have little knowledge of asm that's why I disassembled the .exe to c, so as to be able to work with it.

Hi foolosopher, good to hear from you again.
I dont have much experience with asm either, though I can clumsily navigate myself through it, C do speed things up a lot. I do believe though we are a long way from recompiling C code, let alone producing functional C code, it will probably be broken from the start and need even more treatment later. So I suggest we try to send that asm version through an assembler(since it got no errors, but compare it to the original for differences), and once we have modifications to test from our study of the C code, we grab the equivalent addresses and change the code we can compile. To exemplify how that can already produce results, simply take that variable you found which is probably closer to the 2000 limit, we can grab it's address and simply test changing it and not break the asm, perhaps it would already increase the limit! (A vector declaration in asm is probably a memset in a loop with a 7d0 to 0 counter, the variable address should be the same.)

From what I got from IDA there is a lot of code with errors but it's in c or pseudo c and many of the errors are mostly due to conventions of IDA when disassembling.
BUT if you check the code you can find many functions that have card names so I guess we can skip all that code for now (good idea gmzombie ).

Yep, Im also planning on really learning to code cards before delving further into this (or while we do it, since it's clearly a long term project), so I can understand better how they got this to work, the addresses involved, etc. Since there are already tutorials, it seems the less resistance route. And I also get to work on another pet project of mine which I find there is more people also interested =) take a look: viewtopic.php?f=56&t=1823
Also, the card codes will not be wasted once we jailbreak the game =)

Another major error producer (to me at least) is __usercall. From what I found so far there are about 1500 __usercall function declarations, which use asm notations that produce errors.
Anyway I found a way to circumvent or even fix them by replacing them with wrapper functions that simply omit the asm notations. Unfortunately the declarations of these functions are commented out, so it's taking me some time to replace all that. Oh, placement of the wrappers reduces the errors but adds warnings, but I 'll deal with these later.

Thats why i think it's going to break once you're done, we should change the already working thing, and use the C code to know where to change.

Does this decompiler has some manual or faq, where can i read about those conventions you mention? It would help elucidate stuff like this and the j_ thing you mention on your next post =) (and probably stuff we dont even know are problems yet)

Ghost

[Ghost]

OK you got my curiosity going, so I tried to compare pre and post mok dis-codes (in c) that gmzombie uploaded, BUT its a LOT of lines that are also displaced while being disassembled causing the files to appear much more different than they actually are.

Yep, I managed to know which variables you were talking about because they were just 4, so they correlated exactly just displaced a bit.

If you know a really good file comparing program now's the time to say it. I 'm using the compare utility of notepad++. Araxis Merge is quite good and has a 30 day trial.

In fact I do, there is freediff which I believe is pretty good for what we need, and I also have this diffDoc, which seems to be very robust but I never tried to actually use it. (it also complains about expired trial even though I just installed it -- its old lol -- so a new download or crack might be needed)

I also split the files into chunks of 10000 lines each.
Anyway we need to come up with a plan and stick to it if we are to make our effort worthy (and convince more to help us).
So I would propose this (suggestions are welcome):

I mostly agree with you, here are some thoughts:

dedicate a section at the wiki to post our findings and instructions

Sorely needed. But we must remember to actually update it, and a way to organize it.


>>> "1)for achieving functional c code, "

This is a long term goal, I believe the 2K limit have higher priority (and is contained by it anyway, we will stumble on it before achieving this, so it really doesnt matter)

>>> " - work mostly with the c code"

I agree, but this work will inevitably generate theories that we will want to test (or be left wondering with lack of understanding), they can only be tested with the asm code now, since we are inside the goal of achieving functional C. =)

>>> " - keep debugging (partly done, long way to go)"

yep, looong way...

>>> " - focus mostly at first in magic.exe-c-asm"

Ok.

>>> " - remove cluter card code where possible"

Yes, i guess I'll code a few to see whats going on.

>>> " - rewrite non-functional code where required"

thats problematic, we dont really know what we should write. I like your original idea better, wrap the asm equivalent inside the function. (finding the asm equivalent should be easy enough)

>> " - re-insert removed cluter card code"

Dont see much of a difference either way though.

>> " - examine and connect to the dlls, other libraries"

As above, this also seems something for later, perhaps together with the 3rd goal below.

>>> "2)for finding the 2000 limit "

Now we're talking, thats the original motivation =) The quicker we can get out of that C labyrinth the better =)

>>> " - compare pre and post mok c code"

Yes, btw, I tried looking for 30.000 and didnt found anything. I forgot looking for the Hex equivalent though.

>>> " --share the chunks between ourselves (Ghost,mzombie, me-foolosopher, other volunteers ). Keep in mind that since the code is scattered we should look between diferent chunks after we have tidied up our chunks a bit."<<<

Exactly, if we do split it, we must "second guess" the others work to guarantee we arent missing anything or to understand better. BUT I dont think we should split it yet, the lead is pretty narrow, there isnt much parallelism we can exploit now. If we find like 1000 memsets that need to be changed from 7d0 to 30K, then ok.. Also, if we cant test those changes by compiling and running the asm, it would be just theoretical work...

>>>" - look for 2000, 7d0 occurences, relative function calling etc. (partly done)
- testing, researching, testing, researching,
"<<<

exactly, and testing can only be done by hexing the .exe or dll or compiling the asm. otherwise only the "research" is left.

>>>"3) other mods (after achieving functional c code)
- improve AI
- whatever else we can think of...
"<<<

hehehe, I will not even think about this now =)

>>>"OK this is me brainstorming, but it was more or less what I had in mind, but like I said at the beginning suggestions are welcome."<<<

Yep, i agree, we apply the scientific method =) study the phenomena, generate theories, and test them to improve our understanding and generate better theories =)

One thing, I haven't tried to compile the produced asm, I just know that the exe->asm produced no errors.

Thats why it is our best bet right now.

I also found a perl script that is supposed to produce C++ code from produced IDA asm, but haven't tested it.

Wow, that would be awesome to speed things up!! Hope it works!

Ghost

[gmzombie]

well to test the 7d0 to 30k we could use a prog like ollydbg or ida i believe which will let us change asm inside the exe an run the program with the changed items. this is how we started to change the bmps in the game.

[Ghost]

Beautiful! That's exactly what I advocate using the asm for, and if this works we probably dont even need to compile it anymore, we can focus on the C code or use the asm only to bypass the errors, if the perl script works.

Do you have links we can get those from? This could be the start of the wiki page for this project...

I'll begin by finally downloading and installing the latest version of manalink =)
BTW, long time ago I downloaded a collection of card art from the Magic WorkStation project, do you think those art downloads for manalink2.0 are the same, or should I just redownload them?

oh, I forgot to reply to this:

Harry pitfal was the other one who helped get through the first limit but he is off doing other projects now and has no time for manalink.

Perhaps he could at least remember a bit of what he did, brief stuff like if he changed many arrays or few, if he changed actual functions or more towards declarations.. shouldnt take more than 5 minutes I guess... and might really cut down on the time and effort we need to figure it out.

Ghost.

[Snacko]

One more thing,
I found several functions starting with j_..., is it possible that jatill had something to do with this or am I imagining things?

functions starting with j_ are jump functions which don't do anything by themselves and just jump somewhere else, most of the time these are functions imported from some library

[Ghost]

The 80MB version of the game I mentioned is actually archived by the good people here too! =) it's very small and is the latest official version there is (i.e. pre-Mok).
here it is: viewtopic.php?f=25&t=898

People also archived the original game CD (DotP) AND the Spell of the Ancients CD. If we get stuck, those might give some insight into how they changed the original game and where those changes occurred. For instance, new cards (the official way to do it =)), and we could probably read what new features that version added.

I read somewhere that the last manalink version (1.3.2 right?) made spell of the ancients obsolete (unlocked everything it did, etc), but it's a full CD, what exactly there is there then? videos? animations, card art?

Ghost.

[foolosopher]

OK some resources to get you going:

Converts IDA ASM dumps to C++ (correction python script)
http://siyobik.info/index.php?module=pastebin&id=213

IDA resources
http://my.safaribooksonline.com/book/so ... 1593271787

http://www.hex-rays.com/compare.shtml
www.hex-rays.com/idapro/ida51news.pdf

IDA Plugins: INQUISITION - The Decompiling Plugin
Inquisition is a Local-Assembler-To-PseudoC syntax-guided-translator.
http://www.openrce.org/downloads/detail ... ing_Plugin

[gmzombie]

The 80MB version of the game I mentioned is actually archived by the good people here too! =) it's very small and is the latest official version there is (i.e. pre-Mok).
here it is: viewtopic.php?f=25&t=898

People also archived the original game CD (DotP) AND the Spell of the Ancients CD. If we get stuck, those might give some insight into how they changed the original game and where those changes occurred. For instance, new cards (the official way to do it =)), and we could probably read what new features that version added.

I read somewhere that the last manalink version (1.3.2 right?) made spell of the ancients obsolete (unlocked everything it did, etc), but it's a full CD, what exactly there is there then? videos? animations, card art?

Ghost.

I have every instance of original and post mok work for this game. the 1.3.2 unlocked what they had. mok originally made a patch to unlock some other cards and then after that made the manalink 2.0. yes there is video and whatnot in the full cds...i have images of them if needed