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

    ExitProcess dd rva _ExitProcess
    dd 0
    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
Posted on 2001-06-21 21:57:00 by eet_1024
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
Posted on 2001-06-21 23:43:00 by 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).
Posted on 2001-06-21 23:54:00 by eet_1024
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.
Posted on 2001-06-22 00:41:00 by Larry Hammick
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?
Posted on 2001-06-22 11:54:00 by bitRAKE
Thanks bitRATE. It is in the /masm32/lib directory. I'll have to write a perl script just to format it.
Posted on 2001-06-22 12:51:00 by eet_1024
How do you want it? I could do it in Excel in a couple seconds! I don't know perl, yet. :)
Posted on 2001-06-22 13:17:00 by bitRAKE
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'.
Posted on 2001-06-22 13:39:00 by eet_1024
I was kidding: I don't know perl, but I do know it's powerful at these kinds of tasks.
Posted on 2001-06-22 14:39:00 by bitRAKE
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.
Posted on 2001-06-22 20:41:00 by _drcmda
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
, a
really occurs. The invoke also creates the import section for you. At the time of assembly, the text is stored. But upon loading windows has put the correct info there. Why code in assember in the first place? Party because of the level of control offered. The masm invoke does alot, but also removes come control from the programmer. Control is proportional to work needed to accomplish the task.
Posted on 2001-06-22 21:27:00 by eet_1024
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.
Posted on 2001-06-22 22:27:00 by bitRAKE
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 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
Posted on 2001-06-22 23:58:00 by Larry Hammick
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.
Posted on 2001-06-23 04:32:00 by _drcmda
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,
Posted on 2001-06-23 05:21:00 by hutch--
Wayne Radburn's skeleton-collection also shows how to avoid these two-step jumps. See his nifty stuff at
Posted on 2001-06-26 09:15:00 by Larry Hammick