.def files for stdcall functions

root root@jacob.remcomp.fr
Fri Sep 12 06:09:00 GMT 1997


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@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@0
and a wrong call like
	hwnd = GetActiveWindow(HWND_DESKTOP);
should generate an assembly of
	call	_GetActiveWindow@4

Since _GetActiveWindow@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@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@cygnus.com" with one line of text: "help".



More information about the Cygwin mailing list