Mail Archives: cygwin/1997/09/12/06:22:40
Mr colin peters writes:
>
> The problem is not something you are doing wrong, as such, nor is it linked
> to Mingw32 really. The problem is that impdef does not generate (and cannot
> as far as I can figure out) .def files with that all important @NN suffix
> on stdcall (or PASCAL or WINAPI) functions.
You are right here. From the dll, there is no way to know the number of
parameters passed.
>
>
> Unfortunately there is no way, that I can see, to automatically determine
> this information (what number goes after the @) from the contents of a
> DLL. You must parse the header file! (Please correct me if I'm wrong...
> I'd love to be wrong about this.)
There is a way:
In the lcc-win32 package, you have that nice utility 'pedump'. If you have
the import *library* (the .lib that goes with the dll) you are *saved*!!!
Do the following:
1) pedump /A mylib.lib >ww
2) Edit that file 'ww'
You will see at the beginning of the file a list of all functions exported
from the library WITH THE DECORATED NAMES!, i.e. functionfoo AT 16 for instance.
You will have to edit that file to suit the needs of the ascii file that
dlltool swallows, but this is no big deal... just a matter of erasing
unnecessary stuff.
I have specially modified pedump so that it will dump .libs, with this
objective in mind.
>
> My beef with all this is: why does GCC do it this way at all? What purpose
> does the @NN serve? After all, GCC knows how to generate the correct
> function call given a prototype, it *generates* the @NN, so it doesn't
> need it to know what to do. I don't think any other compilers add on @NN
> to the names of WINAPI functions like this. Why doesn't GCC just use the
> plain function name and call it with PASCAL calling convention? Someone
> please enlighten me.
The _stdcall calling convention means that the called function cleans up the
stack. Since the compiler knows the number of arguments the rationale behind
this is that a call to a _stdcall function would fail to link.
For instance:
extern _stdcall GetActiveWindow(void)
and then a call of
hwnd = GetActiveWindow();
should generate an assembly of
call _GetActiveWindow AT 0
and a wrong call like
hwnd = GetActiveWindow(HWND_DESKTOP);
should generate an assembly of
call _GetActiveWindow AT 4
Since _GetActiveWindow AT 4 doesn't exist, the link would fail.
But much more important, this convention FORCES you to use the standard
header files, since if they are NOT used, the link will fail.
The problem is, if you do not use the header files, the compiler will
generate a NORMAL c call:
For instance:
Without header files
C code: IsWindowEnabled(hwnd);
ASM code: push hwnd
call _IsWindowEnabled
add $4,%esp <<<<<<<<<<<<<<<<<<<<<< adjust the stack
With header files:
extern _stdcall IsWindowEnabled(HWND);
C code: IsWindowEnabled(hwnd);
ASM code: push hwnd
call _IsWindowEnabled AT 4
No stack cleanup is necessary.
If you have made a mistake and not included the header file, the consequence
is that the program will NOT LINK! You are saved from hours of debugging
trying to catch where the stack goes wild...
If gcc wouldn't follow this calling convention and generate the normal names,
gdb would get more usage, right, but what a pain in the *** !!!
I think that windows did it RIGHT here. Of course to say this is not politically
correct in this group... :-) but is my opinion anyway!
Use pedump, and be saved.
It can be found at
http://www.remcomp.com/lcc-win32
--
Jacob Navia Logiciels/Informatique
41 rue Maurice Ravel Tel 01 48.23.51.44
93430 Villetaneuse Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -