Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com X-Apparently-From: Message-ID: <002d01bf935f$752a8400$1400a8c0@tester01> From: "=?iso-8859-1?Q?Manuel_S=E1nchez?=" To: Subject: cygwin DLLs and VC (again) Date: Tue, 21 Mar 2000 19:00:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BF9367.AB8AFB30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 ------=_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
    This message = follows to the=20 one I posted on March 16.
    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:
 
    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.
    VC uses the eax = register as=20 storage for the returning value... I think GCC uses the = stack.
    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!!!
 
    So I wonder if is = there any=20 way of forcing both compilers to work in the same way.
 
    Thanks=20 for reading this.
 
        Tony Sanchez
------=_NextPart_000_0028_01BF9367.AB8AFB30-- __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com