The Masm Jump Table, it the cause of many greviences against Masm. So why is it there at all?

Basically I'd just like to understand the advantages and disadvantages of Masms Jump Table for functions.

Was it just the easiest way of doing things or did the boys at Microsoft feel it was the best way of doing things? :confused:
Posted on 2001-11-11 15:57:52 by Eóin
Jump table, huh? Are you talking about the way DLL imports are handled,
or have I missed something completely?
Posted on 2001-11-11 18:23:34 by f0dder
If you are talking about the import jump table, you can get rid of it by using hutch's L2EXTIA utility to recreate the INC files. I did this when he first released it, and haven't had any problems.

It does require a MACRO in every program that uses the new INC files. I added the macro to the end of WINDOWS.INC, and just make sure that it is always my first INC.

Posted on 2001-11-11 19:04:51 by S/390
I remember reading about that when a post like this happened a couple of months ago... Never got a chance to play with it, but glad to here its got a good track record, cause im definitely interested in the "findings".

Hutch, Is this going to be included in your next release as well?

Posted on 2001-11-12 00:21:09 by NaN

Stuck it in its own directory with a text file that says what it does and I added the macro into the file to support it.

Posted on 2001-11-12 01:43:10 by hutch--
It would be nice to know.
From where this L2EXTIA can be downloaded?
Posted on 2001-11-12 04:37:18 by Desirous
Hummm, there was a thread on the MASM32 forum that had a download link, but I can't seem to find it now. Either the link vanished when hutch moved his site, or I need to go to bed...


Posted on 2001-11-12 05:10:10 by S/390
I found the thread but I could not find the link for the zip file so I am posting it again.

Posted on 2001-11-12 06:06:59 by hutch--
Hutch: I was wondering if you just added the tool to the masm32 package, or also made a seperate dir for the includes? As it wouldn't matter for the size of the package, the installation could generate the includes twice, frist for the \include\ folder for the normal includes, and then again but in the other style in a dir like \exinclude\ or something...

Posted on 2001-11-12 07:31:59 by Thomas
Yes, Hutch, please do so ! I like your tool and it has become a standard-include in my projects !

(I'm feeling myself more free with it :grin: )

Greetings, CALEB
Posted on 2001-11-12 08:39:51 by Caleb
Appologies, I was referring to the import jump table, sorry.

I wasn't looking fora way to remove it, though it is intresting to see that there is a way.

I was just wondering why is it there. Is there an advantge to calling imports that way?
Posted on 2001-11-12 12:36:38 by Eóin
Well, with the way implicit imports are done, you need to have a
table of function pointers - the IAT. Now, you can call these directly
(call dword ptr ), or you can use the "jumpy"
normaly approach (call j_messagebox, where j_messagebox does
the direct call). The reason for the "jumpy" approach is that it fits
in very well with the traditional C approach of header/library files,
and require no knowledge from the programmer/compiler to handle
the linking. Direct calls are possible in C too, with the use of macros
to redefine symbols a bit. Not pretty if you code it by hand, but
the declspec(dllimport) or whatever makes it prettier.

As for avoiding the funcptr table totally... you'll have to use loadlibrary/getprocaddress,
or your own base-scanner and importer. The only advantage of
loadlib/gpa is that you can do dynamic DLL loads, which are useful
for eg. plugins or big dlls you only use temporarily.

I say stick with implicit importing, and only use loadlibrary/getprocaddress
when there's a clear advantage (plugins, using new OS functionality
only if it's available, etc).
Posted on 2001-11-12 12:44:19 by f0dder
I personally don't have any problems with the API lookup table in the generic format of MASM produced EXE files but enough people were interested in the idea so I wrote the utility to create the include files in that format.

As far as MASM32, I have put the utility in its own directory so that advanced programmers who are interested can create their own directory of include files with it but I don't want to make things any more difficult for programmers who are starting with MASM32 by confronting them with multiple formats for include files so I have retained the standard MASM format in the include directory.

I have actually played with a variation that made the include files with the "invoke" statement embedded in the prototype and it allows you to use the API directly with just a parameter list behind it like in a high level language but there is a problem in that other procedures that are local in code or in libraries cannot use it because they are not imports so i did not persist with it.

Posted on 2001-11-12 18:20:27 by hutch--