Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !
- Posted by mattlewis (admin) Apr 24, 2009
- 1165 views
It looks like return_type is being stored in esi. I notice that Bernie's code modifies esi. I'm not sure whose responsibility it is to restore esi, but the problem appears to be that Watcom thinks that it's Bernie's job to restore any registers. That also helps explain why, when I took the address of return_type, it started working againbecause Watcom stopped putting return_type in a register that gets clobbered.
My code does not have any thing to do with changing the return type.
If you will note that the return type is set up in the define_c_func by a C_ULONG which is NOT controlled by my program code but internally by Euphoria.
No matter what is done to the ESI register internally in my code; it should not effect the external Euphoria code.
The return VALUE will on each pass; return a different pointer. The only thing that I am storing in my is the program is at ptr: dd 0 location in my code which keeps the pointer for the next pass.
Bernie,
Please re-read what I wrote. Your code changes esi. Watcom is storing the variable return_type in esi. Therefore, as far as the call_c code is concerned, your code is changing return_type.
See, for example (from your code):
#8B,#35,#A1,#AD,#D1,#83,-- mov esi, [@ptr] ; get current ptr
Matt
