EXE Jump Tables

[BlackVortex]

I haven't read the whole thread, but I just want to add that goasm+golink don't use import jump table. The calls to the API point directly to the import table.   :cheekygreen:

that's because Jeremy is a genius.

IDA loses the ball, it doesn't recognize/resolve imports correctly on the GoTools executable I tried   :green2

And I thought it was a very advanced analyzer/disassembler (I absolutely never use it)  :P

[hutch--]

Fortunately MASM users have the choice of either.  :bg

[BlackVortex]

Fortunately MASM users have the choice of either.  :bg

How ? You mean the MS linker has an option for that ?

EDIT: Oh, I see custom macro weirdness. Goddamnit I hate macros   :eek

[dedndave]

well - Vortex has one method - i think i have a better one, though

[UtillMasm]

i hate macro and the damnit english.
:wink

[hutch--]

 :bg

> How ? You mean the MS linker has an option for that ?

No, ML.EXE, pick your prototype type, get the style of calling you want, either direct or indirect. Ain't MASM great !  :P

[dedndave]

i hate macro and the damnit english.
wink

that's "damned English" - lol
and - we are all glad ms is not in Beijing
writing code in Chinese - instructions actually WOULD execute - it'd be like a death sentance on every line

somehow, i don't imagine UtillMasm is much of a swearer

[rags]

No, ML.EXE, pick your prototype type, get the style of calling you want, either direct or indirect. Ain't MASM great !

Hutch (or anyone) , how does a function's prototype affect whether the function is called directly or indirectly through a jump table?
How is a function prototyped to get a direct call to the api?

[hutch--]

Mike,

Without knowing the mechanism and how MASM was written, the best I can offer is that when you use one type of prototype, the assembler produces the code for an indirect call, when you use another type of prototype you get a direct call.

[sinsi]

indirect

Code Select Expand


ExitProcess proto :dword


direct

Code Select Expand


p1 typedef proto :dword

EXTERNDEF _imp__ExitProcess@4:PTR p1
ExitProcess TEXTEQU <_imp__ExitProcess@4>


I think the library defines which one will be used - if you declare using _imp__ prefix then direct will be used.

[Vortex]

i hate macro and the damnit english.
:wink

Why do you hate macros? Don't you use invoke? It's a macro.

[BlackVortex]

I started the macro hating trend, so I will respond.  I hate macros that I don't know about. Invoke rocks my socks !

When I use macros and then look at my disassembled code when debugging, I see all kinds of weird crap between my nice code. It feels so out of place, like it's not my code. Also, their implementation feels weird and unituitive, so I've never learned how to create even the simplest macro.

[dedndave]

I started the macro hating trend, so I will respond.

that's not fair - i have been no big fan of them for a long time - lol
actually, macros can be your friend
the problems stem from using macros created by someone other than yourself
some of them are helpful in getting a program up and running
but, i would prefer to replace many of them with my own code at the end of the day
this is true for any kind of program that i intend to distribute
for programs of my own use, or for forum discussion/distribution - the macros are great
we all speak the same "macro" language in here
i also have to say - i have learned a lot by looking at how the macros were written

[rags]

Thanks Hutch and Sinsi for the explanations. :U

[hutch--]

BlackVortex,

There is a trick to it, read the documentation for the macro, look at how its written and if you don't like it, improve it. The action with macros is multifold, at the simplest its just a shortcut to get something done, at its most sophisticated it put the programmer in charge of language design without having some compiler designer holding your hand telling you what you can and cannot do.