From: jont AT harlequin DOT co DOT uk (Jon Thackray) Subject: yes, why @NN?!(was :Re: .def files for stdcall functions ) 16 Sep 1997 03:49:02 -0700 Message-ID: <199709161021.LAA19170.cygnus.gnu-win32@zaphod.long.harlequin.co.uk> References: <199709151536 DOT QAA09339 AT zaphod DOT long DOT harlequin DOT co DOT uk> To: "'GNU-Win32'" 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- AT 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 AT 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 AT mm > as though it were foo AT 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 AT cygnus DOT com" with one line of text: "help". - 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".