Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Message-ID: <3783E9CF.16D0430D@olf.com>
Date: Wed, 07 Jul 1999 19:59:11 -0400
From: "Robert Bresner" <rbresner AT olf DOT com>
MIME-Version: 1.0
To: DJ Delorie <dj AT delorie DOT com>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: How can I get a .dll to resolve at runtime ?
References: <199907072246 DOT SAA07598 AT indy DOT delorie DOT 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 AT olf DOT 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 AT sourceware DOT cygnus DOT com