From: root@jacob.remcomp.fr (root)
To: colin@bird.fu.is.saga-u.ac.jp (Colin Peters)
Cc: gnu-win32@cygnus.com
Subject: Re: .def files for stdcall functions
Date: Fri, 12 Sep 1997 06:09:00 -0000 [thread overview]
Message-ID: <m0x9V50-000ALFC@jacob.remcomp.fr> (raw)
In-Reply-To: <01BCBF89.A3905060@gbird0>
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".
next prev parent reply other threads:[~1997-09-12 6:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-09-11 23:07 .def files for stdcall functions (was: linking problems with the minimalist version) Colin Peters
1997-09-12 4:40 ` Gunther Ebert
1997-09-12 6:09 ` root [this message]
1997-09-12 22:41 ` yes, why @NN?!(was :Re: .def files for stdcall functions ) J Russell Smyth
1997-09-15 8:41 ` Jon Thackray
1997-09-16 3:26 ` Jon Thackray
1997-09-15 7:35 .def files for stdcall functions marcus
1997-09-17 17:00 dahms
1997-09-17 17:55 Stephan Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m0x9V50-000ALFC@jacob.remcomp.fr \
--to=root@jacob.remcomp.fr \
--cc=colin@bird.fu.is.saga-u.ac.jp \
--cc=gnu-win32@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).