Subject: RE: code generation and dll name resolution
From: [email-masked] (Alessandro Forin)

9 Dec 1996 20:29:48 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <c=US%a=_%p=msft%l=[email-masked]>
Original-To: "'Josef Burger'" <[email-masked]>
Original-Cc: "[email-masked]'" <[email-masked]>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 92 TEXT
Original-Sender: [email-masked]

Short answer: you need to fix your include file.

Long answer.
I assume you are not familiar with "__cdecl" versus "__stdcall" calling
conventions.
Otherwise, I misunderstood you and pls forgive&ignore.

The __cdecl calling convention uses the caller-pops-the-stack rule.
The __stdcall calling convention uses the callee-pops-the-stack rule.
Therefore its important to know (a) by how many bytes the stack gets
popped
in an __stdcall function and (b) that caller and callee agree on who
does what.

One solution to these issues is to use different link-time names for the
two
calling conventions.  For a function signature like
	int foo(int) {...}
MS and compatible compilers will create link names as follows:
	_foo		this is the __cdecl link name
	_foo@4		this is the __stdcall link name

Notice that the number after the "@" is NOT a DLL ordinal as you seem to
imply,
it is just the number of bytes to pop the stack off.

The compiler is instructed to use one or the other calling convention as
follows:

	int __cdecl foo(int)
	int __stdcall foo(int)

What if you dont say anything ?
MS compilers can be told on the command line to use one or the other
calling convention, the default is otherwise __cdecl.

Note that for "varargs" functions (such as printf) only
caller-pops-the-stack
is possible.  MS compilers will enforce this (when they see the
ellipsis).

Further info:
- VC++ generates more complicated link names that cover the whole
type signature of a method.  These are called "decorated names", there
is a
utility in the CD that will "undecorate" a link name back to its C
prototype.
Needless to say, the idea here is that humans dont deal with the
resulting,
long, and impossible names...

- As far as I know, this issue is specific to the x86 architecture.  
 Other architectures (MIPS Alpha PPC..) only support one calling
convention.

- There are other x86 calling conventions, such as __thiscall,
__fastcall...

sandro-

>----------
>From: 	Josef Burger[SMTP:[email-masked]]
>Sent: 	Monday, December 09, 1996 9:32 AM
>To: 	[email-masked]
>Subject: 	code generation and dll name resolution
>
>[ I'm using b16 ]
>
>Background:  I'm compiling something that uses the winsock-2 api
>instead of winsock.  I built a link library for ws2_32.dll, added
>the extra declarations for winsock2 to the headers, and tried
>to build.  It compiles ok, but it fails to link.
>
>The link fails because the compiled code references names such as
>'ntohs@4' or 'connect@12' instead of 'ntohs' or 'connect'.  Aha,
>I say, I must rebuild my dll link library with name@offset style
>names.  That doesn't work ... because the 'name@offset' compiled
>by the compiler is the name@offset for the winsock-1 dll!
>
>I though the link libraries for the dlls are supposed to isolate
>normal code from the 'offset in dll' stuff????
>
>How do I tell the *compiler* to generate plain 'name', or
>'name@offset' for functions in the winsock-2 dll I'm trying to link
>against, INSTEAD of the the winsock-1 names@offset???
>
>thanks!
>bolo
>-
>For help on using this list, send a message to
>"[email-masked]" with one line of text: "help".
>
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".