Import Libraries

[Drakasm]

I've followed the instructions described in the Iczelion tutorial  " How to Create your own MASM Import Libraries" http://win32assembly.programminghorizon.com/importlib.html .
I'am interested in making the functions using invoke so i could benefit from the Masm check and the other benefits coming from the use of invoke instead of pushing all the parameters to the stack.
In the attachments i have included all the files i've created  from a OpenAL32.dll.

My problem is :

• The project assembles but if i use a function with invoke i get an : error A2006: undefined symbol
• Using the function with push - call everything works fine and the program run's perfectly.

                                   

What i'am doing wrong ?
Many thank's in advance.

[MichaelW]

The problem may be that the DLL is exporting undecorated names and the linker is looking for decorated names. You can check the exported names by simply opening the DLL in a text editor. You should be able to solve this problem by modifying the DEF file that you use to build the import library, per the information here. Basically, you use the decorated name for entryname and the undecorated name for internalname, as was done in this DEF file for the Microsoft GZIP DLL:

Code Select Expand


LIBRARY gzip.dll
EXPORTS
_Compress@32=Compress
_CreateCompression@8=CreateCompression
_CreateDecompression@8=CreateDecompression
_DeInitCompression@0=DeInitCompression
_DeInitDecompression@0=DeInitDecompression
_Decompress@28=Decompress
_DestroyCompression@4=DestroyCompression
_DestroyDecompression@4=DestroyDecompression
_InitCompression@0=InitCompression
_InitDecompression@0=InitDecompression
_ResetCompression@4=ResetCompression
_ResetDecompression@4=ResetDecompression


Another possible explanation for the DLL exporting undecorated names is that the DLL is using the cdecl calling convention. If you are not certain that the DLL is using the stdcall convention, after you get the library working you need to try comparing the stack pointer before you call a function in the DLL (that has at least one parameter) to the stack pointer after the call returns. If the caller is using the correct calling convention then the values should match.

[dedndave]

i didn't look at Iczelion's method
but, i would use Erol's Def2Lib tool to create an import library

http://vortex.masmcode.com/

in the Def2Lib package, Erol has included a few example DEF files
here are the first several lines for the DEF file for Kernel32

Code Select Expand

LIBRARY kernel32
EXPORTS
"_ActivateActCtx@8"
"_AddAtomA@4"
"_AddAtomW@4"
"_AddConsoleAliasA@12"
"_AddConsoleAliasW@12"

here are the first several lines from your DEF file for OpenAL32

Code Select Expand

LIBRARY OpenAL32
EXPORTS
alBuffer3f
alBuffer3i
alBufferData
alBufferf
alBufferfv

[dedndave]

looking at the readme file...

Code Select Expand

The optional -nod switch instructs the tool to create import libraries without decoration.
For this output mode, the symbols in module definition files should not be decorated:
LIBRARY kernel32
EXPORTS
"ActivateActCtx"
"AddAtomA"
"AddAtomW"
"AddConsoleAliasA"
"AddConsoleAliasW"

he also has a tool that will create the DEF file for you

[dedndave]

searching the old forum, i found one that may work for you by Yves...
http://www.masmforum.com/board/index.php?topic=16016.msg142657#msg142657

oops - that is for C++

you may want to browse page 2 of that thread   

[MichaelW]

In the header files from the OpenAL 1.1 SDK, all of the functions I bothered to look at were preceded with AL_APIENTRY, defined as:

Code Select Expand


#if defined(_WIN32)
#define AL_APIENTRY __cdecl
#else
#define AL_APIENTRY
#endif


So the functions apparently use the cdecl calling convention, and for that reason the function names in the DLL are not decorated. The attachment includes a DEF file and import library, and your include file with all instances of "STDCALL" replaced with "C", and a small test app that verifies that one of the functions is callable, with the DLL in my working directory. And although the function returns an error on my Windows 2000 test system, I was able to verify that it does use the cdecl calling convention.

[Drakasm]

I appreciate your interest  MichaelW and i thank you for this. :t
Before i bother the forum members i usually have come to a dead end or i'am getting crazy about a problem.
This one was great, at least for my possibilities related to my level of assembly knowledge.
After a week and a half of Inferno based on Iczelion tutorial , decorating - undecorating creating def and inc files and having the same
problem.
At last   

So the functions apparently use the cdecl calling convention, and for that reason the function names in the DLL are not decorated. The attachment includes a DEF file and import library, and your include file with all instances of "STDCALL" replaced with "C", and a small test app that verifies that one of the functions is callable, with the DLL in my working directory. And although the function returns an error on my Windows 2000 test system, I was able to verify that it does use the cdecl calling convention.

Yes they use the cdecl calling convention that's why there were all this problems.
With Jwasm and the OPTION DLLIMPORT i can use invoke after i have defined the prototypes c and without the problem of including
OpenAL32.lib.

I'am going to figure out OpenAL_test.zip.  :t  Thank you again 

dedndave

oops - that is for C++

you may want to browse page 2 of that thread

Grazie dedndave : in the past i have downloaded those files but there was a problem because these files are not fully usable.
I believe they must be modified i'am working on it.
Thank you very much for your reply, is always great for us newcomers when assembly knowledge is shared.

[Vortex]

Hi Drakasm,

About name decoration, Agner Fog has a very nice document :

Calling conventions for different C++ compilers and operating systems

http://agner.org/optimize/calling_conventions.pdf

[Drakasm]

Problem solved  :t  !!!!!!!!!!!!!!!!!
Thanks to you all.  :P
Making a report for other people who may use or complete those functions
I've worked with the OpenAL32.def file which has this format :::

Code Select Expand

LIBRARY OpenAL32
EXPORTS
"alBuffer3f"
"alBuffer3i"
"alBufferData"
"alBufferf"
"alBufferfv"
"alBufferi"
"alBufferiv"

Then i have downloaded The  Module definition file to MS COFF import library converter Version1.1   http://vortex.masmcode.com/  from Vortex's Utilities and Tools . :t  Thanks Vortex !!!

Using the command line : def2lib openal32.def  was generated the openal32.lib file

The Include file is in the attachments. (openal32.inc)

Code Select Expand

alcGetIntegerv PROTO C :DWORD,:DWORD,:DWORD,:DWORD
alcGetProcAddress PROTO C :DWORD,:DWORD
alcGetString PROTO C :DWORD,:DWORD
alcIsExtensionPresent PROTO C :DWORD,:DWORD
OpenAL uses cdecl calling convention.  Thanks MichaelW !!
  :t
Inserting those files in the Masm32 directories lib and include respectively and adding in the masm32rt.inc
include \masm32\include\openal32.inc
includelib \masm32\lib\openal32.lib
We can benefit from those functions.

Many Many Thanks to MichaelW Vortex dedndave  which helped to solve this mystery :lol:

For the correct execution of the function's make sure that OpenAL32.dll is present on your system.
Personally i've downloaded the installer from : http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx

Best wishes to you all.

[Vortex]

Hi Drakasm,

I am glad to know that it worked for you.

[Drakasm]

Also worked with Iczelion's Method but the openal32.lib file generated is bigger ?

[Vortex]

Also worked with Iczelion's Method but the openal32.lib file generated is bigger ?

Bigger import library is an expected result as the linker builds the library according to the long format :

In an import library with the long format, a single member contains the following information:
   Archive member header
   File header
   Section headers
   Data that corresponds to each of the section headers
   COFF symbol table
   Strings
In contrast, a short import library is written as follows:
   Archive member header   
   Import header
   Null-terminated import name string
   Null-terminated DLL name string

This is sufficient information to accurately reconstruct the entire contents of the member at the time of its use.

http://msdn.microsoft.com/library/windows/hardware/gg463125

[dedndave]

yah - someday, when i have nothing else to do - lol
i may go through and re-create all my import libraries with Erol's Def2Lib tool   :t

[Drakasm]

Guys  you are  wells of knowledge !!!!!!!!1

[dedndave]

it's all Erol
he knows all about these file formats

i just know how to find his website   :lol: