Fix decompilation of "msgcmd.cpp" about devilution HOT 10 CLOSED

wtf is this??? it pushes esi at the beginning of the function and pops it at the end... :/

This is a convention used to store caller registers. The push in the beginning of the function (the function prologue) stores the value of the esi register, and the pop at the end of the function (the function epilogue) restores the original value of the esi register. This makes it possible to use the esi register within the function, and still retain the value of the esi register as expected by the caller function.

from devilution.

The more I look, the uglier it gets.
Those SMemAlloc and SMemFree calls with the ".?AUEXTERNMESSAGE@@" tag? They come from a const type_info class, at offset 0x49F070. That means in the original code there must be a call to typeid(X) where X is an instance of struct EXTERNMESSAGE. Now here's the weird thing: the string .?AUEXTERNMESSAGE@@ would normally be accessed by calling the type_info::raw_name() function, but instead it's being accessed directly. I double-checked the <typeinfo> header for VC6 and char _m_d_name[] is definitely a private member of class type_info, so I think the only way this could happen is if they redefined type_info locally (or something equally dumb e.g. (const char*)&typeid(sgChat_Cmd)+8) - which means we will probably have to use the same ugly hack to reproduce it exactly and break compatibility with compilers other than MSVC.

from devilution.

wtf is this??? it pushes esi at the beginning of the function and pops it at the end... :/

from devilution.

Well yeah, I know that :P The problem is that ESI appears to be passed as an argument for some functions, and being used as a return value for others. This messes up the decompiler since it assumes EAX as return and fastcall convention.

It shouldn't be hard to fix, especially since we can use PvPGn to emulate battle.net to test chat commands. That should also help fill in the remaining struct fields. Timed messages are also broken, but the code never appears to be executed anyway.

from devilution.

Well yeah, I know that :P

Hehe, yea. I felt I stated something rather basic after posting. Oh well :)

from devilution.

Which function uses esi as a return value?

from devilution.

https://reverseengineering.stackexchange.com/questions/2673/what-x86-calling-convention-passes-first-parameter-via-esi

TLDR: Probably link time optimization

Edit: This might also concern #111

from devilution.

ChatCmd::extern_msgs might be a union. Complex types as parameters to fastcall functions aren't passed in registers, they get pushed on the stack like normal. This is what msgcmd_delete_server_cmd_W expects because it cleans it up when returning ("retn 4").

from devilution.

Had another look and I now think these might be __thiscall (i.e. c++ member) functions. This would make sense since the SMemAlloc/SMemFree calls are using -2 (SLOG_OBJECT) for their logline argument.

from devilution.

Now what's the summary?

from devilution.