Not Balancing the Stack?
Umm, considering how few problems Delphi seems to have calling .DLLs in general, I'd say the trouble is actually in your call translation. One of three possibilities:
* Forgot to make it a function (even if you never use the result, prototyping it as procedure instead of function will cause a stack problem (most missing ones I see are forgetting to return an HRESULT)
* Using or not using const, var or out
* One of the parameters is prototyped incorrectly (especially with strings and long strings)
If you ever manage to get a Delphi compile with symbols on, you'd find out that all those 'stupid-looking instructions' like MOV EAX, EAX are actually padding for 32-bit alignment - they occur after the RET and before the entry point of the next . I don't know why they don't use NOP, but it looks like they're trying to use no-effect instructions that take up a single line in a CPU view (NOP for a pad of 1 byte, MOV EAX,EAX for a pad of 2 bytes, and LEA EAX,[EAX+0x0] for 3 bytes).
Umm, considering how few problems Delphi seems to have calling .DLLs in general, I'd say the trouble is actually in your call translation. One of three possibilities:
* Forgot to make it a function (even if you never use the result, prototyping it as procedure instead of function will cause a stack problem (most missing ones I see are forgetting to return an HRESULT)
* Using or not using const, var or out
* One of the parameters is prototyped incorrectly (especially with strings and long strings)
If you ever manage to get a Delphi compile with symbols on, you'd find out that all those 'stupid-looking instructions' like MOV EAX, EAX are actually padding for 32-bit alignment - they occur after the RET and before the entry point of the next . I don't know why they don't use NOP, but it looks like they're trying to use no-effect instructions that take up a single line in a CPU view (NOP for a pad of 1 byte, MOV EAX,EAX for a pad of 2 bytes, and LEA EAX,[EAX+0x0] for 3 bytes).