#5 switch for direct api calling!

[Anonymous]

Something i miss in masm is a switch that tells assembler to use direct api calling instead of indirect as default in masm32 packade inc files.

RIght know the code will get generated with a jump table at end of code section! Only way i found howto get around this is
1. use Win32Inc files but no many use them and don't work in all cases with masm32 macros
2. convert all inc files from PROTO statement to EXTERNDEF statements.

both are not optimal since it requires those sets of inc files to assemble correctly with direct api calling so my suggestion is that a switch in assembler would be nice where you can choose wich one you wanna use, like the switch for STDCALL/C/PASCAL calling method.

so user will then have two choices either direct (call dword ptr [IPT-address] or call dword ptr [jmp-table-address].

Hope you get my point ;)

[Nobody/Anonymous]

I got the point. There's a problem, however: how is the assembler supposed to distinguish between (stdcall) functions which are located in a dll and (stdcall) functions which are contained in another object module and linked statically? For the latter exists no IAT function table. In C headers there is the _declspec(dllimport), but in the Masm32 headers there's no equivalent attribute currently.

So if the Masm32 headers aren't to be changed, one would have to implement additional stuff, for example:

include \masm32\include\windows.inc
option dllimport
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
include \masm32\include\gdi32.inc
option nodllimport

That's probably a lot for such a minor issue, and additionally it's incompatible.

japheth

[Nobody/Anonymous]

Ok i see!

i got idea from this thread: http://www.masm32.com/board/index.php?topic=11541.0

[Nobody/Anonymous]

Using MASM has a big disadvantage: one is depending on the pre-compiled LIB files because
they are crippled with the decorated names. I think rebuilding is very complicated or it isn't even possible.
Therefore I'm still using TASM 5.3 and WATCOM tools, because it is more versatile. With this I avoid many annoyances.
JWASM/TASM doesn't need to know if a function is imported from an OBJ file or a DLL. To achieve this the interface between all modules has to be unified.
I do this by avoiding the creation of decorated names as follows:

1)
I create an import library from the required DLLs, for example:
wlib /q /n /pa imports +-kernel32.dll +-user32.dll

2)
I make the include statements in the source ASM, for example:
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib imports.lib

3)
I could compile the ASM source by disabling name decoration:
JWASM -zt0 -zcw -<some_other_options> source.asm

3a)
If required, I compile an appropriate C source for using in my ASM program, forcing a self-made header file to be included with the "fi" switch to define an undecorated __stdcall:

#pragma aux default "*" \
parm routine [] \
value struct struct caller [] \
modify [eax ecx edx]

3b)
I convince WATCOM not to declare annoying __imp__... DLL-imports, changing
WATCOM\h\nt\winnt.h, line 47, to:

#define DECLSPEC_IMPORT // __declspec(dllimport)

(This generates "normal" externs in an obj file which can be linked together with the defined ones from the previously created import.lib)

4)
I link the OBJ files with wlink (options may be incomplete):
wlink form win nt run win=4.5 file source_asm,sources_c lib imports

[Nobody/Anonymous]

Using MASM has a big disadvantage: one is depending on the pre-compiled LIB files because
they are crippled with the decorated names. I think rebuilding is very complicated or it isn't even possible.
Therefore I'm still using TASM 5.3 and WATCOM tools, because it is more versatile. With this I avoid many annoyances.
JWASM/TASM doesn't need to know if a function is imported from an OBJ file or a DLL. To achieve this the interface between all modules has to be unified.
I do this by avoiding the creation of decorated names as follows:

1)
I create an import library from the required DLLs, for example:
wlib /q /n /pa imports +-kernel32.dll +-user32.dll

2)
I make the include statements in the source ASM, for example:
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib imports.lib

3)
I could compile the ASM source by disabling name decoration:
JWASM -zt0 -zcw -<some_other_options> source.asm

3a)
If required, I compile an appropriate C source for using in my ASM program, forcing a self-made header file to be included with the "fi" switch to define an undecorated __stdcall:

#pragma aux default "*" \
parm routine [] \
value struct struct caller [] \
modify [eax ecx edx]

3b)
I convince WATCOM not to declare annoying __imp__... DLL-imports, changing
WATCOM\h\nt\winnt.h, line 47, to:

#define DECLSPEC_IMPORT // __declspec(dllimport)

(This generates "normal" externs in an obj file which can be linked together with the defined ones from the previously created import.lib)

4)
I link the OBJ files with wlink (options may be incomplete):
wlink form win nt run win=4.5 file source_asm,sources_c lib imports

[japheth]

The OPTION DLLIMPORT feature has been implemented in v2.06. Using this option it is easily achieved to selectively enable "direct API calling".