yes, why @NN?!(was :Re: .def files for stdcall functions )

Tue Sep 16 03:26:00 GMT 1997

Jon Thackray writes:
 > J. Russell Smyth writes:
 > > Colin Peters wrote:
 > > 
 > > > 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.
 > > 
 > > I too have wondered about this .. as I have been attempting to create
 > > dll's that
 > > can be used with other languages, mainly Visual Basic, I have found this
 > > frustrating
 > > and annoying! to create a dll for use with VB and gcc, I must create all
 > > functions with
 > > the @NN and alias all of them to non-@NN names for VB! One quickview of
 > > 
 > > ANY M$ dll shows that microsofts dll's do not contain this info, where
 > > cygwin does,
 > > causing great grief for other-language-programmers.
 > > 
 > > This problem is also encountered with LCC which I use extensively...
 > 
 > This isn't really a GCC thing. Microsoft produced the @nn stuff to
 > indicate the stack usage of procedures which are called by the pascal
 > calling convention, since such procedures clean their own stacks
 > before returning (using the carefully provided ret n instruction on
 > the x86 architectures). Since the callee rather than the caller is
 > cleaning the stack, even though the callee created the stack, it is
 caller
 > important that they agree on how much stack should be cleaned. This is
 > the bit gcc is doing. Now, I suspect that the problem you have is the
 > dll export and import tables don't match up, because one has the @nn
 > stuff in it and one doesn't. This isn't a link time issue, it's a load
 > time issue, and apart from convention, there's no reason for the
 > symbols in the export tables to bear any textual relationship to the
 > link time names of the functions they refer to. Indeed, link time
 > symbols of the form _foo@nn are typically translated into load time
 > references of the form foo, ie a leading _ and the trailing @nn are
 > stripped. This can lose the safety of being sure you don't call foo@mm
 > as though it were foo@nn. Anyway dlltool, which creates the export and
 > import tables, has an option (-k) to strip the trailing @nn. You
 > probably need to use this somewhere.
 > -
 > For help on using this list (especially unsubscribing), send a message to
 > "gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".