I've followed the instructions described in the Iczelion tutorial
" How to Create your own MASM Import Libraries" http://win32assembly.programminghorizon.com/importlib.html (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.
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 (http://msdn.microsoft.com/en-us/library/hyx1zcd3(v=VS.71).aspx). 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:
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.
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/ (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
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
LIBRARY OpenAL32
EXPORTS
alBuffer3f
alBuffer3i
alBufferData
alBufferf
alBufferfv
looking at the readme file...
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
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 (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 :biggrin:
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:
#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.
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 :dazzled: 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
QuoteSo 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 :biggrin:
dedndave
Quoteoops - 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.
Hi Drakasm,
About name decoration, Agner Fog has a very nice document :
QuoteCalling conventions for different C++ compilers and operating systems
http://agner.org/optimize/calling_conventions.pdf
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 :::
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/ (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)
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 (http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx)
:biggrin:
Best wishes to you all.
Hi Drakasm,
I am glad to know that it worked for you.
Also worked with Iczelion's Method but the openal32.lib file generated is bigger ?
Quote from: Drakasm on February 03, 2013, 12:04:32 AM
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 :
QuoteIn 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
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
Guys you are wells of knowledge !!!!!!!!1
it's all Erol
he knows all about these file formats
i just know how to find his website :lol:
Something that is being missed here, the size of the import library simply does not matter, it is only the size of the code entry that matters. You may save a small amount of disk space but it ain't like it matters with terabyte sized drives. The size of the binary is not effected by the library size.
it may matter for someone on a laptop :P
Then why not spell out how trivial it is to save disk space instead of the inference that it somehow effects the binary.
we never said the larger format doesn't work
somewhat obvious that it does - lol
however, if given a choice between a file that is 10 kb and one that is 100 kb...
if they both provide the same functionality, i'll take the one that is 10 kb
the reason we need terabyte drives is some people like to bloat whenever they can :biggrin:
let me provide a realistic example where it is nice to have a smaller import library....
one of the masm32 import libraries is missing a function that i want to use
in this example, i will use ntdll.lib, because i know there is a desired function missing - NtOpenKeyEx
now, i can use GetProcAddress
which is ok, but it is an unneeded call and a lot of text to set up a prototype
or - i can create an import library and add it to the project - yielding a cleaner, more consistent result
now - do i want a big file or a small one ?
when i want to share the project with others, a smaller file is better...
less server storage space and bandwidth
less user bandwidth everytime someone downloads it
i don't know that the guy at the other end isn't using a laptop, where file space is treasured
this is just an example, of course
there may be cases where many functions and/or libraries come into play
i am inclined to ask the opposite question
why not replace Inc2L with Def2Lib ?
Erol probably would not object
inc2l is 16 kb
Def2Lib is 5.5 kb
but, here's the real pay-off
the propensity for build errors should be reduced
building the libraries during masm32 installation is somewhat processor intensive
by reducing the file sizes, you reduce the build time and, thus, the likelihood of resulting errors
Def2Lib is flawless and fast :t
Quote from: dedndave on February 03, 2013, 01:54:11 AMthe propensity for build errors should be reduced
building the libraries during masm32 installation is somewhat processor intensive
by reducing the file sizes, you reduce the build time and, thus, the likelihood of resulting errors
that implies Software should take care of unstable systems? - does not sound logical.
Quote from: dedndave on February 03, 2013, 01:54:11 AM
Def2Lib is flawless and fast :t
Since I'm generally rather sceptical when I hear such claims I downloaded the current version ( v1.1 ) and did a brief test.
Result: found 2 errors:
1. field timestamp in the import entries is fix 1.
2. the module name always ends with ".dll", even if the module name in the LIBRARY statement ends with ".exe".
error 1 looks minor, but these days you never know - some AV programs might find it suspicious if they don't find a valid timestamp.
well, the os is what it is :P
we aren't going to fix it - we want to use it
but, that doesn't mean we have to stroke it's fur backwards, either
i understand why Hutch uses Inc2L
for one thing, it translates from INC to LIB without the intermediate step of a DEF file
this probably reduces the time spent building the libraries, as well
for another thing, it's his own tool, so he has control over it
due to the newly supported unicode prototypes, it needs a little update, anyways
(refer to the threads on Process32First, et al)
i am sure Hutch is aware of it, and probably has a plan to update things, as time permits
Erol also has a tool called Inc2Lib
for whatever reason, it does not appear on his download page - probably an oversight
http://vortex.masmcode.com/files/inc2lib14.zip (http://vortex.masmcode.com/files/inc2lib14.zip)
it appears to suffer from the same little issue with regard to parsing the newer unicode prototypes
and, it uses PoLink to create the import libraries
not quite as nice as his newer Def2Lib, which creates them directly, but still creates the smaller libraries
i seem to recall Erol saying something about an upgrade of the Def2Lib tool into a newer Inc2Lib
so, we can look forward to that
my point was, that there are advantages to smaller files that go beyond disk space
Japheth,
i believe Hutch fixes problem 1 with a little program called "Touch.exe"
his Inc2L program also allows for exe's, drv's, etc
inc2l ntoskrnl.inc exe
i don't see that Erol's tool has a switch for that one
Quote from: dedndave on February 03, 2013, 04:03:07 AM
i don't see that Erol's tool has a switch for that one
I'm still surprised a little because the ".dll-instead-of-.exe" problem was already reported by nidud a few months ago ( with ntvdm.lib / ntvdm.exe ) - and the bug still isn't fixed in def2lib? Vortex, there's a job to be done! What are you waiting for?
he probably plans to fix that issue with the newer Inc2Lib
address all the problems at once :biggrin:
but, i wasn't going to poke the crocodiles with a pointy stick
i will let these guys fix things at their own pace
otherwise, they have no reason for not expecting me to do it - lol
the main point i was trying to make was with regard to the unmentioned advantages of smaller files
Hi Dave,
def2lib does not depend on other tools and it's able to build import libraries from a .def file. inc2lib depends on an external tool, a linker to output the libs. This is why I stopped worked on inc2lib. Maybe, I can reconsider creating a new version of inc2lib
Both of the short and long format for import libraries are usable. def2lib adopts the short format.
Hi Japheth,
nidud already tested the correct version of ntvdm.lib :
http://masm32.com/board/index.php?topic=1086.msg10209#msg10209
A quick fix solved the dll / exe issue. I will have to release a new version of def2lib.
many thanks for all your great tools, Erol :t