Craploads of Bugs

[AMadMonk]

Okay, I've found a million tiny bugs that add up over time to crash bugs and other aberrant behavior.

99.9% of them are calling convention bugs.

For instance, the DInputDataDetour needs to have both the detour function AND the trampoline function pointer prototyped as __stdcall.

From what I can see all of the /commands fn pointers should be protoed as __cdecl.

/click has to be called from within a class method invocation context or you'll get weird, random bugs (I think this is the source of the "1 in a million /click doesn't work" bug).

I believe chat hook should be __stdcall. The project defaults to __cdecl at the moment so that ends up being a problem.

Basically the thing to do when troubleshooting these is to look at the called code and try to deduce if it's __stdcall, __cdecl or a class method invocation (__thiscall, I believe, but you can't prototype as __thiscall).

__stdcall/__cdecl bugs are easy to fix, but __thiscall problems are thornier. I believe that the need for __thiscall is why the command hook is wrapped in a class (to preserve the this pointer). Also note GetMaxMana -- it's mostly just an inline asm function called with ecx (this) preset. That's what you need to do in /click too, but using clsSpawns instead of the char info thingy.

I have these fixed on my MQ (and it's a MILLION times more stable and reliable) but my MQ is so radically different from release MQ now that I don't know if I can merge back. SO just passing along the joy.

One thing to try that catches stack corruption RIGHT away is to compile with the /RTCs flag set. This enables runtime stack checking, and a calling convention mismatch (like all of the bugs I've been finding) will immediately trip a debug break. So compile /RTCs and run it in the debugger -- you should find that virgin 1024 release crashes instantly. That's the DInputDataDetour calling convention mismatch. Then you have to go down the line ironing the rest out...

[rizwank]

Ok.
If you understood that, good for you.
I think i got about half of it.
If it made no sense to you, please dont post asking for explainations, it will be included in a soon to be released CVS.

[Fippy]

Well I didnt even need to duck to let that one go by.

AMM what have ya got that is so radically different ??

Perl stuff or stuff from the dark side ??

[Cheese]

Good stuff monk, I've not been using any of those features in my codebase. but ya, keeping seperate codebases is a pain isnt it. Would help if we could split eqlib.cpp some and make it a bit cleaner, but I aren't going to start bossing Plaz about with his own project. Personally I just do a diff every MQ update to check out new features / fixes and take what's good.

I'll look into the calling too, i've not had any stability problems with my code but as I said I don't really use much right now.

[eqjoe]

Monk... if your code is different maybe its time for a fork?

Look at what happened with SINS and ShowEQ. In the long run, the ShowEQ guys liked some of the SINS code and integrated it into ShowEQ.

Just an idea... I would love to see what you have come up with.

[Madman]

splits could be good but I would have to say the joint effort that the team here has made is awsome and I for one would hate to see it split because even though I know nothing of pearl. I know it would be good to have 2 gurus working on 1 project than 2 ppl working on 2 seperate ones. but thats just my 2cp

[eqjoe]

/agree with Madman

I just wish I could figure out how to build the project using VS6. Until I lay hands on a copy of VSNET, there is no reason to look past the binarys.

:)

[rizwank]

No need to fork. perl and MQ# work ok together and with the new #perl on off switch in the code, there is no reason go down that path.

if you have code mods send em to me or amm and we will diff em into the CVS if they are good... eqlib has been divided up some and can be cleaned up some more... both in code structure and implementation, so feel free to contribute :)

Cannot be compiled in VS6.
Many smart people have spent many hours trying.
Just get a edu copy of VSnet

[Cheese]

Hmm I dont see why it cant be compiled on VS6, I'll dig up a VS6 copy later

[rizwank]

Detours doesnt like VS6. The project files dont like VS6. Detours doesnt like VS6.

[Domosan]

Heck, you can compile it under VS6, I've done so!

Of course, once you run it and then launch EQ it will crash in about 15 seconds...but you sure as heck can compile the durn thing.


Domo

[rizwank]

bah. cant use html in sigs dude.

need bbcode.

[Cheese]

Detours existed long before VS7, as for project files.. makefiles :)

Havent gotten any time recently with illness, work, going away but will see what I can do to look at it if people cant get VS7

[xyilla]

369.9

[xyilla]

мето