public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* cygwin DLLs and VC
@ 2000-03-16  7:40 Incubus Incógnita
  2000-03-16  8:04 ` Mumit Khan
  0 siblings, 1 reply; 3+ messages in thread
From: Incubus Incógnita @ 2000-03-16  7:40 UTC (permalink / raw)
  To: cygwin

  I've tried compiling a working VC++ DLL project
using the dllhelpers r2.4 provided with Cygwin B20,
and found out that despite the result worked fine
with Gygwin's GCC compiled exes, it didn't work at
all with the same exes compiled with VC. 
  In fact, it returns exactly the same adress for
the dll imported function in both cases, but when
calling it from VC it causes a GP fault. The exports
are done using old-fashion .DEF style, so I'm
forcing the calling convention to "C" using the extern
"C" directive, that I think that should be supported
by
both compilers.
  If any of you found this problem or have any idea
about solving it, please let me know.
 
--The DLL code
 
----Try.h

#ifndef _TRY_H
#define _TRY_H
 
 
#include <windows.h>
#include "interfaces/ICommon.h"
 
 
 class Try: public O3D::ICommon
 {
 	int numRef;
 public:
 	// Constructor / Destructor
 	Try()
 	{
 		numRef = 1;
 	}
  
  	// ICommon
  	int Release()
  	{
  		if (!(--numRef))
  			delete this;
  		return numRef;
  	}
  
  	void AddReference()
  	{
  		numRef++;
  	}
  
  	ICommon *GetInterface(int iid)
  	{
  		return this;
  	}
  
  	int GetImplID() const 
  	{
  		return 666;
  	}
  };
  
  
 #endif
  
 ----Try.cpp
  
 #include <stdio.h>
 #include "Try.h"
 
  
 ICommon *Create()
 {
 	return new Try();
 }
  
  
 extern "C" void Register(FARPROC* pSt)
 {
   printf("Registering...\n");
 	*pSt = (FARPROC)Create;
 }
 
 ----Try.def
 
 LIBRARY		Try.dll
 
 EXPORTS
 
 	Register
  
  
 --The exe using the DLL:
  
 #include <stdio.h>
 #include <windows.h>
 

 #include "interfaces/ICommon.h"
  
  
  
 int main(int argc, char *argv[])
 {
    printf("\nLoading library...\n");  
  
 HMODULE hLib;
  
    hLib = LoadLibrary("Try.dll");
  	
 void (* pFunc)(FARPROC*);
  
    pFunc = (void (*)(FARPROC*))GetProcAddress(hLib,
 "Register");
    printf("\npFunc: %x\n", pFunc);
  	
 FARPROC Creat;
  
    pFunc(&Creat);
  
 ICommon* pObj;
  
    pObj = (ICommon*)Creat();
    printf("\nID: %i\n", pObj->GetImplID());
  	
    FreeLibrary(hLib);	
    return 0;
 }
  
  
    Thanks for reading this.
  
      Tony Sanchez

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: cygwin DLLs and VC
  2000-03-16  7:40 cygwin DLLs and VC Incubus Incógnita
@ 2000-03-16  8:04 ` Mumit Khan
  2000-03-16 12:17   ` Mumit Khan
  0 siblings, 1 reply; 3+ messages in thread
From: Mumit Khan @ 2000-03-16  8:04 UTC (permalink / raw)
  To: Incubus  Inc gnita ; +Cc: cygwin

Incubus "Inc gnita" <icg_incubus@yahoo.com> writes:
>   I've tried compiling a working VC++ DLL project
> using the dllhelpers r2.4 provided with Cygwin B20,
> and found out that despite the result worked fine
> with Gygwin's GCC compiled exes, it didn't work at
> all with the same exes compiled with VC. 
>   In fact, it returns exactly the same adress for
> the dll imported function in both cases, but when
> calling it from VC it causes a GP fault. The exports
> are done using old-fashion .DEF style, so I'm
> forcing the calling convention to "C" using the extern
> "C" directive, that I think that should be supported
> by
> both compilers.
>   If any of you found this problem or have any idea
> about solving it, please let me know.

Let me see if I understand this.

1. VC++ compiled DLL loaded dynamically from VC++ compiled main app.
   - Works.
2. Cygwin compiled DLL loaded dynamically from VC++ compiled main app.
   - Does not work.

If this is the case, then it's expected. Cygwin v1.1 will have full
functionality to be loaded dynamically by non-cygwin application, but
b20.1 has only partial support.

To make it work with b20.1, and keeping in mind that you'll only have
partial support, use __cygwin_noncygwin_entry@12 as the entry point 
for your Cygwin DLL.

See my examples for Java JNI or Excel DLL etc on:
  http://www.xraylith.wisc.edu/~khan/software/gnu-win32/

Good news is that all this hackery will go away, at least in theory, 
in the upcoming Cygwin v1.1.

BTW, you may need to make loadable functions, such as Register, use
the __stdcall calling convention, or else you may run into stack
corruption. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: cygwin DLLs and VC
  2000-03-16  8:04 ` Mumit Khan
@ 2000-03-16 12:17   ` Mumit Khan
  0 siblings, 0 replies; 3+ messages in thread
From: Mumit Khan @ 2000-03-16 12:17 UTC (permalink / raw)
  To: Incubus  Inc gnita ; +Cc: cygwin

[ previous post regarding Cygwin DLL with VC++ app ]

Ooops, misspelled DLL entry point name. It should be 
  
  __cygwin_noncygwin_dll_entry@12 

NOT
  __cygwin_noncygwin_entry@12 

Of course, a quick search on "noncygwin" in this list or the pointer
I had provided dealing with Java JNI's etc will have picked out the
right name. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-03-16 12:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-16  7:40 cygwin DLLs and VC Incubus Incógnita
2000-03-16  8:04 ` Mumit Khan
2000-03-16 12:17   ` Mumit Khan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).