One reason for jmp-ing to a supposed-to-be a called function is when the jmp
is at the end of a procedure.. let me be clearer with an example,

proc SomeFunc
    ; some code here...
    jmp OtherFunc
endp SomeFunc

this can be written instead of

proc SomeFunc
    ; some code here...
    call OtherFunc
    ret
endp SomeFunc

why? because that when you call a function, the ip register (or eip) of the
next instruction is pushed on the stack and a ret instruction just restore
it to ip/eip... so the program is coming back to where the function has been
called. so only jmp-ing to a function will avoid a ret !.. you can also see
that when you debug with turbo de{*filter*}.. see by yourself.. there are surely
other reasons why the compiler does that, but I don't know any of them..
like I just said, the code generated depends on the compiler and language
you use... so a 4k messagebox Windows program can be 10k with a linker and
640 bytes with another..

Quad

  The thing you are calling is in a DLL.  Its location is not known
until the loader attaches your program to that DLL.  At that time,
the loader patches a *single* location in your program for each
entry point you call in the DLL.  Since you might call the same
entry point more than once, it needs a level of indirection to
have all calls use the same patched address.

  If the compiler knew that the call was to a DLL and wanted to
use that knowledge it could "call dword ptr [???]" to represent
the indirection within one instruction.

  If the compiler doesn't do that (since you used TASM, not a
compiler, I think it is in your control) then the call must
look like an ordinary direct call.  The linker can't change
a direct call to an indirect call, so it must create an
indirect jmp for the direct call to go to.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/

Subject: Re: Tasm32 and Win exefiles
Date: Monday, January 25, 1999 6:34 PM

This is not entirely correct....The system loader places the
<<patched>>address in a data section location to keep the code section read
only. The fix-up then occurs in a private location for each process on the
system, and the code sections can be shared across processes.  The number of
references to each fixed-up location is irrelavent -- it can be one to one,
or many to one.  The criteria is which section is modified by the loader.

Karl M