www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/07/08/07:55:51

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <19990708115338.74139.qmail@hotmail.com>
X-Originating-IP: [193.207.88.164]
From: Emanuele ALIBERTI <ealiberti AT hotmail DOT com>
To: rbresner AT olf DOT com, 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 ?
Date: Thu, 08 Jul 1999 04:53:37 PDT
Mime-Version: 1.0

>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

No, it doesn't. Only the internal module reference count is set to two.

>	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()...?

DLLs (for EXEs it is the same) are memory mapped in the importing process 
address space, not shared.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019