The assembler I'm using (FAsm) require that the import table be created in the
source code. No biggy, but I don't whether an API call is in the kernal32.dll
or user32.dll. Is there a list of all API calls and there location. If it also
contains a short discription I'll also be able to see and use (I have the Win32.hlp) them.
Here is an example of the import section:
section '.idata' import data readable writeable
dd 0,0,0,rva kernel_name,rva kernel_table
dd 0,0,0,rva user_name,rva user_table
dd 0,0,0,0,0
kernel_table:
ExitProcess dd rva _ExitProcess
dd 0
user_table:
MessageBox dd rva _MessageBoxA
dd 0
kernel_name db 'KERNEL32.DLL',0
user_name db 'USER32.DLL',0
_ExitProcess dw 0
db 'ExitProcess',0
_MessageBoxA dw 0
db 'MessageBoxA',0
Hi,
The Win32.hlp does actually tell you which import library
contains the API function, it's just sort of hidden under
the "Quick Info" button at the top of the page for each API
description.
You could also use something like the resource explorer Exescope
(should be easy to find with a search). Just open up each
system dll, check the Export heading and you'll get a complete
listing of all the functions.
Kayaker
Thanks again. Doing a find on QuickInfo list all of the functions and clicking on
the Quick Info link gives me what I need. Eventually I would like to write a perl script to create the import section (into an include file).
I agree, eet, it would be quite nice to have
the import table under our hands. Another
thread here is concerned with how to modify
the IAT at run time. With a smarter linker,
the IAT could just become part of a data
section, solving that problem. But a script
which generates a macro or an include file
would be good too.
Find win32api.csv it is what you seek. It's in the WinSDK, and I think it might be in the include directory of the MASM32 package - not certain of this?
Thanks bitRATE. It is in the /masm32/lib directory. I'll have to write a perl script just to format it.
How do you want it? I could do it in Excel in a couple seconds! I don't know perl, yet. :)
No thanks. PERL is powerful data processing language. With 10
lines of code I can parse the file and format it into an html
table. I could also blob everything together into a 'one liner'.
I was kidding: I don't know perl, but I do know it's powerful at these kinds of tasks.
the iat can point to the data section ...
the iat is created by the loader ... if a prog is created
the loader will look for all imports in the pe.import.section
and calculate the iat so i think you can not ~code~ the
iat ... you can but i will be overwritten.
but then... why do you guys want to change the imports of your
OWN file ??????? i think there is no need for doing such
things.
The import table contained in the exec is text data. Windows replaces part of it with the actual
call location. In MASM, when you do an
invoke MessageBox call With macros that control can be regained quit easily, and you can add UNICODE support to MASM. Check out Controled Compilation by Elicz (MASM/NASM). Skipping the extra jump is only the useless trouble that Hutch makes it sound like because it's not standardized. Check out Elicz's Page for even more goodness.
Fair question, _drcmda. Suppose you want to support a variety of hardware. When the program loads, it can find what hardware is present and choose imports accordingly.
The "IAT" is just one of five parts of the "import table". It is the part that gets filled in with addresses by the linking-loader, as _eet was saying. It may appear in any section (masm puts it in .rdata with the rest of the import table). Contrary to the vague documentation out there, the IAT does not need to be initialized in the file. It doesn't need an image in the file at all. To see a demonstration of that, look at www.hammick.com/hcs/hello_g.exe with a PE disassembler.
I will look at perl, for sure, and at bitRake's suggestions, thx guys.
This message was edited by Larry Hammick, on 6/23/2001 2:42:30 AM
it insn't the invoke call which is responsible
for the importsection it's just the linker if
you call a dll.function the linker creates the
entry in the import section for that... in this
section the name/ordinal and the address of that
api call are stored ... at runtime the loader will
take all these informations and create the iat
whose position and size is stored in the dataarray
and CAN be modified. and sure you don't need a
import section (if don't have a import sec you don't
have the iat) you can do all this stuff very easy
at runtime with GetProcAddress and GetModuleHandle
(these two functions are working alway because the
kernel is mapped in EVERY module at runtime so you
can decide use other system-specific hardware dll's
at runtime, too.
I have had this discussion with EliCZ over the advantage of reducing
a single jump by directly calling a function in a DLL, sytem or
otherwise and it still reduces down to saving a jump for code that
is far slower than the asm code that calls it.
Manually coding the addresses of every called function is easily done
with LoadLibrary() and GetModuleHandle() but unless you need the
practice, it performs no better, if you have multiple calls to the
same function, your code gets bigger and its one hell of a lot more
messing around for no point, it just does not perform any better.
If you are looking for real speed when calling a DLL, write it
yourself, get the absolute address of the start label of the function
and call it directly using registers for parameters. If you want
to pass a lot more parameters, pass them in the address of a structure
in the EAX register.
If you are after performance, don't mess around with botch ups that
give you no advantage in performance terms, are far more error prone
and deliver slightly larger code.
Regards,
hutch@pbq.com.au
Wayne Radburn's skeleton-collection also shows how to avoid these two-step jumps. See his nifty stuff at
http://www.magma.ca/~wjr