Mail Archives: cygwin/2000/03/21/13:02:27
------=_NextPart_000_0028_01BF9367.AB8AFB30
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This message follows to the one I posted on March 16.
Following the explanations Mumit Khan kindly gave, I managed to link =
dinamically a cygwin GCC compiled DLL from a VC compiled exe, and using =
__stdcall calling specifier, it worked fine with ordinary C methods. One =
of the methods returned an object whose class derived the ICommon =
interface... well, a correct instance was returned, but then I noticed =
that there are some differences between VC and GCC when dealing with =
method calling:
=20
First of all: VC stores the object pointer in ecx before it calls =
the method itself, and it seems that GCC do the same in ebx.
VC uses the eax register as storage for the returning value... I =
think GCC uses the stack.
Virtual tables differ in method pointer placement in VC and GCC: =
when calling to one method from VC using a certain offset from the =
vtable it jumps to another method whose assembly it's easily =
recognisable (the release method), but it'snt the one it was supossed to =
call!!!
=20
So I wonder if is there any way of forcing both compilers to work in =
the same way.
Thanks for reading this.
Tony Sanchez
------=_NextPart_000_0028_01BF9367.AB8AFB30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2> This message =
follows to the=20
one I posted on March 16.</FONT></DIV>
<DIV><FONT size=3D2> Following the explanations Mumit =
Khan=20
kindly gave, I managed to link dinamically a cygwin GCC compiled DLL =
from a VC=20
compiled exe, and using __stdcall calling specifier, it worked fine with =
ordinary C methods. One of the methods returned an object whose class =
derived=20
the ICommon interface... well, a correct instance was returned, but then =
I=20
noticed that there are some differences between VC and GCC when dealing =
with=20
method calling:</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> <FONT =
color=3D#000000>First of=20
all: VC stores the object pointer in ecx before it calls the method =
itself, and=20
it seems that GCC do the same in ebx.</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> VC uses the eax =
register as=20
storage for the returning value... I think GCC uses the =
stack.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> Virtual tables =
differ in=20
method pointer placement in VC and GCC: when calling to one method from =
VC using=20
a certain offset from the vtable it jumps to another method whose =
assembly it's=20
easily recognisable (the release method), but it'snt the one it was =
supossed to=20
call!!!</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> So I wonder if is =
there any=20
way of forcing both compilers to work in the same way.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2> <FONT =
color=3D#000000>Thanks=20
for reading this.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 =
size=3D2> <FONT=20
color=3D#000000>Tony Sanchez</FONT></FONT></DIV></BODY></HTML>
------=_NextPart_000_0028_01BF9367.AB8AFB30--
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
- Raw text -