Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sourceware.cygnus.com
Message-ID: <3783E9CF.16D0430D@olf.com>
Date: Wed, 07 Jul 1999 19:59:11 -0400
From: "Robert Bresner" <rbresner@olf.com>
MIME-Version: 1.0
To: DJ Delorie <dj@delorie.com>
CC: cygwin@sourceware.cygnus.com
Subject: Re: How can I get a .dll to resolve at runtime ?
References: <199907072246.SAA07598@indy.delorie.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Groovy, groovy.

> You'd have to build an import library for your
> executable and link the dll against that, but I'm not sure if NT would
> even *allow* such a hack.

Now we I did think of this, actually, and when I read yours, I 
had to remember why I let it slip from my mind. 

Here's the thing:
I'll actually have function foo() statically linked in 
a.exe and b.exe ( from another library static library).
And, a.exe and b.exe would be linking to the 
dll. This throws a bone in the works, doesn't it? 

If a.exe and b.exe were both running... 
and both load the .dll... which become part of
the process's address space... Does this mean 
the .dll is 'loaded' twice? Such that 
	a.exe->dll->foo()->a.exe
and 
	b.exe->dll->foo()->b.exe
If that makes sense? The .exe calls a function in 
the dll, which is calling a function back in the exe.
So, if a.exe calls the dll, does the dll go back to a.exe
for the foo()... and if b.exe calls the dll function,
does the dll go back to b.exe for foo()...?

I might just be babbling incoherently at this point..

Any thoughts ?


----------------------------------------
Robert Bresner          rbresner@olf.com
Open Link Financial    516-227-6600 x216
http://www.olf.com/    fax: 516-227-1799
----------------------------------------
Opinions expressed are explicitly my own
"No more talking!  Cerebus has a SWORD!"

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