From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Thackray To: "'GNU-Win32'" Subject: yes, why @NN?!(was :Re: .def files for stdcall functions ) Date: Mon, 15 Sep 1997 08:41:00 -0000 Message-id: <199709151536.QAA09339@zaphod.long.harlequin.co.uk> References: <01BCBF89.A3905060@gbird0> <34198046.9789F5D2@voicenet.com> X-SW-Source: 1997-09/msg00281.html 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 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".