ret

[raleeper]

               invoke   DrawText, hdc,ADDR dbgw,12, ADDR rect, tfmt
00000268  68 00000150      *       push   +000000150h
0000026D  68 0000051C R   *       push   OFFSET rect
00000272  6A 12      *       push   +000000012h
00000274  68 0000052C R   *       push   OFFSET dbgw
00000279  FF 75 FC      *       push   dword  ptr ss:[ebp]+0FFFFFFFCh
0000027C  E8 00000000 E   *       call   DrawTextA
00000281  E8 00000004         call   erbeep

               ret
00000286  C9         *       leave 
00000287  C2 0010      *       ret    00010h

This is part of a subroutine in my WndProc

The coding of "ret" as C9 C2 010 is wrong.

There is no problem with erbeep, which is global.

By trial I've found a workaround - insert an NOP after the invoke - inelegant to say the least.

What's going on?

[MichaelW]

The coding looks correct to me. Try posting your source.

[raleeper]

MichaelW - "The coding looks correct to me. Try posting your source."

Well, it's coding correctly now, with ret as C3, and no workaround, so I must have been making some dumb mistake.

The source is at http://raleeper.com, but I haven't yet figured out how to make it easy to access.

Thanks.

[MichaelW]

Ok, looking at your source I think I see what you are doing. For a subroutine C3 is the correct encoding, and you can force this encoding by using RETN instead of RET.

[raleeper]

Ok, looking at your source I think I see what you are doing. For a subroutine C3 is the correct encoding, and you can force this encoding by using RETN instead of RET.

I tried retn with no success when I was having the problem.  Now the simple ret works.

[raleeper]

The problem - ret coded as C9 C2 10 and no return/crash - popped up again after I made changes in the subroutine.

This time nop didn't work, but retn did.

So you were right.  Thanks.

[BogdanOntanu]

hihihihi
What a  joke...

Since when do assemblers encode a RET wrongly? eh?

That encoding might serve a purpose ...  ;)

[raleeper]

ret - Wrapup

The masm32 assembler, while processing a proc, assumes that any "ret" is an exit from the proc, although this assumption can be overridden by using "retn", or "retf", and procs can be nested.

It does this for policy reasons (subroutines other than declared procedures are "disparaged").

This is guesswork to a large extent, but I believe it is accurate.

[BogdanOntanu]

ret - Wrapup

The masm32 assembler, while processing a proc, assumes that any "ret" is an exit from the proc, although this assumption can be overridden by using "retn", or "retf", and procs can be nested.

Slightly wrong....

MASM does offer PROC as a feature. This feature does help you with automatic handling of LOCAL variables, USES handling, parameter count and type checking (if PROTO is used) and the clearing of the stack according to defined calling convention.  Honestly it does help quite a lot and like any helper it does have some caveats.

Of course you can always code all this by hand... and maybe you should do so until you fully understand the help  and usage of PROC.

I am unsure if you can really overwrite all this with a RETN... in fact with a USES clause a series of POP's should precede any RET. Maybe you can but why? The idea is that you are playing with fire and for no real reason

In order to nest PROC's ?... What kind of  a joke is this? Why should anybody want to nest PROC's?

Just in order to create problems?  IF you really really want to nest them then you should be doing it manually and look into ENTER and LEAVE opcode description in Intel manuals. AFAIK ENTER was designed for this.

It does this for policy reasons (subroutines other than declared procedures are "disparaged").

Wrong!
MASM  does this in order to help you... you are trying to "bend/abuse" it's help for a purpose it was not designed to serve...

You can always code "nested procedures" by hand...

[japheth]

> I am unsure if you can really overwrite all this with a RETN... in fact with a USES clause a series of POP's should precede any RET

Yes, you can. There is no "hidden "code inserted with RETN.

> In order to nest PROC's ?... What kind of  a joke is this? Why should anybody want to nest PROC's?

I don't "nest" PROCs, but use the RETN to exit "local" functions like this:

Code Select Expand



main proc uses esi edi
    mov eax,1
    call localfunc1
    ret
localfunc1:
    xchg eax,edx
    retn
main endp


> Just in order to create problems?

What problems? There is nothing wrong using local functions IMO.