A __declspec(dllimport) equivalent in MASM32?

[Liquid]

Like the title says, is there one?

In other words, is there any option in MASM32 to achieve a result similar to what __declspec(dllimport) in C++ does?

Thanks in advance,
Lars

[hutch--]

Hi Lars,

Welcome on board. I moved the post so you would get a wider range of answers. My C is too rusty to answer your question but a rough guess is you want to prototype a DLL function and call it in MASM. If this is so its easy to do, write a MASM format prototype and include the library from the DLL if its available. If it not you can create an import  library yourself. Alernatively if you don't want to do this you can direct call it with LoadLibrary() / GetProcAddress().

[ramguru]

I'm not sure, if this is what you want...

Code Select Expand


funcx TYPEDEF PROTO CDECL :DWORD,:DWORD,:DWORD,:DWORD
funcy TYPEDEF PTR funcx


.data?
    funcPTR funcy ?


.code
...
   invoke GetProcAddress,...
   mov    funcPTR, eax
   invoke funcPTR, var1, var2, var3, var4
...

P.S. code works OK in POASM not sure about MASM

[Vortex]

It works in Masm.

[Liquid]

Thanks for the quick replies, but that wasn't precisely what I meant.

__declspec(dllimport) hints the C compiler backend that the function called resides in an external DLL and therefore a pointer call is to be generated, rather than a jump stub loaded from the associated import library.
I'll try to explain a little more clearly using Iczelion's tutorial no. 3 - "A Simple Window" - as an example.


If you compile this tutorial's code and open up the resulting executable in a disassembler of some sort you'll find the IAT (Import Address Table) at RVA 2000; 0x00402000.
It exists of a list of DWORD sized variables that the loader will fill in with the offsets for their respective API functions as soon as their associated DLLs have been loaded in memory.

Not far above this, at offset 0x00401138, you'll find an array of jump stubs.
That is, instructions like such:

Code Select Expand

jmp_kernel32.dll!ExitProcess:
  jmp [kernel32.dll!ExitProcess]
jmp_kernel32.dll!GetModuleHandleA:
  jmp [kernel32.dll!GetModuleHandleA]
...
  ...

In the actual code, the API's are called like such:

Code Select Expand

0x0040101E:
  call jmp_kernel32.dll!ExitProcess

In C++, if one uses __declspec(dllimport) the compiler backend will not load those stubs, but instead create API calls like such:

Code Select Expand

0x0040101E:
  call [kernel32.dll!ExitProcess]


The question; Can this be achieved in MASM32?

[drizz]

The question; Can this be achieved in MASM32?

of course it can. you just have to change the include file so all function prototypes look like this.

Code Select Expand

;barebone example
.686
.model flat,c
option casemap:none
includelib kernel32.lib

PROTO@4 TYPEDEF PROTO STDCALL :DWORD
EXTERNDEF STDCALL _imp__ExitProcess@4:PTR PROTO@4
ExitProcess EQU <_imp__ExitProcess@4>

.code
start:
int 3
invoke ExitProcess,eax
end start


there are two ways of doing that:
1) by downloading and using japheth's includes, the easy way (japheth.de)
2) using/making a tool that generates such include files (i've made such tool)

[hutch--]

There is a tool in masm32 called L2EXTIA that creates an alternative include file format that creates prototypes in the form that drizz has mentioned. MASM can do the default PE format of the jump table at the end of the exe, direct calls with this type of prototype and it can call an address manually that you obtain from virrtual tables or GetProcAddress().

[AkinforASM]

Thank you very much for all these answers  :U

I've always been trying to understand how this process (i.e. externaldef process) is achieved but apparently failed to phrase my question in proper format by using correct terminology to make myself be understood. Regards.

[Liquid]

Sorry for the late reply, but this seems to be what I was looking for indeed.

Thanks for the help. :-)

[Cobra]

People in here always seem to help others. It's a nice place to come.

What's the difference speed and/or size wise declaring the functions that way?

[hutch--]

Cobra,

Masm support two different function call techniques, a lookup table at the end of a PE file which is the normal PE spec and it also supports direct address function calls by using the different prototype for the function. The original PE design was created that way for size efficiency where you only have one location for a function address even if it is called from many places within the EXE file.

Of the two methods I personally prefer the original PE design as function calls are not fast enough to worry about but you have the alternative method if you think there is some advantage in using it, even though there rarely ever is.