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

[Jon Thackray]

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".