* How can I get a .dll to resolve at runtime ?
@ 1999-07-07 14:42 Robert Bresner
1999-07-07 15:49 ` DJ Delorie
1999-07-31 18:34 ` Robert Bresner
0 siblings, 2 replies; 16+ messages in thread
From: Robert Bresner @ 1999-07-07 14:42 UTC (permalink / raw)
To: cygwin
Howdy,
I have a .dll which wants to call functions in the .exe. When I
try linking the .dll, I get unresolved externals. NT, you see,
wants to resolve everything at link-time, unlike *nix which wants
to resolve at run-time.
Is there a way, on NT, to get a .dll to resolve externals
at runtime, like *nix, instead of at link time?
I know I can rewrite a whole bunch of everything, and move
functions around and bluh bluh bluh and get a successful
resolve at link-time. That's not what I'm looking for, however.
Any suggestions for this would certainly be appreciated.
Thanks in advance.
----------------------------------------
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 14:42 How can I get a .dll to resolve at runtime ? Robert Bresner
@ 1999-07-07 15:49 ` DJ Delorie
1999-07-07 16:13 ` Tor Lillqvist
` (2 more replies)
1999-07-31 18:34 ` Robert Bresner
1 sibling, 3 replies; 16+ messages in thread
From: DJ Delorie @ 1999-07-07 15:49 UTC (permalink / raw)
To: rbresner; +Cc: cygwin
> Is there a way, on NT, to get a .dll to resolve externals at
> runtime, like *nix, instead of at link time?
I don't think so. What you'd normally do is have the exe call the dll
at startup and pass it pointers to its functions, which the dll would
store in per-process memory (remember that dlls are shared among many
executables).
One thing to try is to export the function with a .DEF file, and see
if that works. 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.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 15:49 ` DJ Delorie
@ 1999-07-07 16:13 ` Tor Lillqvist
1999-07-31 18:34 ` Tor Lillqvist
1999-07-07 17:01 ` Robert Bresner
1999-07-31 18:34 ` DJ Delorie
2 siblings, 1 reply; 16+ messages in thread
From: Tor Lillqvist @ 1999-07-07 16:13 UTC (permalink / raw)
To: DJ Delorie; +Cc: cygwin
DJ Delorie writes:
> One thing to try is to export the function with a .DEF file, and see
> if that works. 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.
Yes, it works quite well (on Win9x at least). You can specify a .def
file when building an .exe with CL (or LINK), and it produces an
import .LIB. With gcc -mno-cygwin it's quite a bit more convoluted,
but it's possible. I came to the conclusion that with gcc you must
mark the exported functions with __declspec(dllexport), the .def file
is ignored. (And you must do the dance with multiple gcc and dlltool
passes.) I might be wrong...
--tml
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 16:13 ` Tor Lillqvist
@ 1999-07-31 18:34 ` Tor Lillqvist
0 siblings, 0 replies; 16+ messages in thread
From: Tor Lillqvist @ 1999-07-31 18:34 UTC (permalink / raw)
To: DJ Delorie; +Cc: cygwin
DJ Delorie writes:
> One thing to try is to export the function with a .DEF file, and see
> if that works. 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.
Yes, it works quite well (on Win9x at least). You can specify a .def
file when building an .exe with CL (or LINK), and it produces an
import .LIB. With gcc -mno-cygwin it's quite a bit more convoluted,
but it's possible. I came to the conclusion that with gcc you must
mark the exported functions with __declspec(dllexport), the .def file
is ignored. (And you must do the dance with multiple gcc and dlltool
passes.) I might be wrong...
--tml
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 15:49 ` DJ Delorie
1999-07-07 16:13 ` Tor Lillqvist
@ 1999-07-07 17:01 ` Robert Bresner
1999-07-07 17:33 ` DJ Delorie
1999-07-31 18:34 ` Robert Bresner
1999-07-31 18:34 ` DJ Delorie
2 siblings, 2 replies; 16+ messages in thread
From: Robert Bresner @ 1999-07-07 17:01 UTC (permalink / raw)
To: DJ Delorie; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 17:01 ` Robert Bresner
@ 1999-07-07 17:33 ` DJ Delorie
1999-07-31 18:34 ` DJ Delorie
1999-07-31 18:34 ` Robert Bresner
1 sibling, 1 reply; 16+ messages in thread
From: DJ Delorie @ 1999-07-07 17:33 UTC (permalink / raw)
To: rbresner; +Cc: cygwin
> a.exe->dll->foo()->a.exe
> b.exe->dll->foo()->b.exe
Aye, there's the rub. It depends on whether NT considers the import
address table to be a shared resource, or a per-process one. One can
only try and see.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 17:33 ` DJ Delorie
@ 1999-07-31 18:34 ` DJ Delorie
0 siblings, 0 replies; 16+ messages in thread
From: DJ Delorie @ 1999-07-31 18:34 UTC (permalink / raw)
To: rbresner; +Cc: cygwin
> a.exe->dll->foo()->a.exe
> b.exe->dll->foo()->b.exe
Aye, there's the rub. It depends on whether NT considers the import
address table to be a shared resource, or a per-process one. One can
only try and see.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 17:01 ` Robert Bresner
1999-07-07 17:33 ` DJ Delorie
@ 1999-07-31 18:34 ` Robert Bresner
1 sibling, 0 replies; 16+ messages in thread
From: Robert Bresner @ 1999-07-31 18:34 UTC (permalink / raw)
To: DJ Delorie; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-07 15:49 ` DJ Delorie
1999-07-07 16:13 ` Tor Lillqvist
1999-07-07 17:01 ` Robert Bresner
@ 1999-07-31 18:34 ` DJ Delorie
2 siblings, 0 replies; 16+ messages in thread
From: DJ Delorie @ 1999-07-31 18:34 UTC (permalink / raw)
To: rbresner; +Cc: cygwin
> Is there a way, on NT, to get a .dll to resolve externals at
> runtime, like *nix, instead of at link time?
I don't think so. What you'd normally do is have the exe call the dll
at startup and pass it pointers to its functions, which the dll would
store in per-process memory (remember that dlls are shared among many
executables).
One thing to try is to export the function with a .DEF file, and see
if that works. 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.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* How can I get a .dll to resolve at runtime ?
1999-07-07 14:42 How can I get a .dll to resolve at runtime ? Robert Bresner
1999-07-07 15:49 ` DJ Delorie
@ 1999-07-31 18:34 ` Robert Bresner
1 sibling, 0 replies; 16+ messages in thread
From: Robert Bresner @ 1999-07-31 18:34 UTC (permalink / raw)
To: cygwin
Howdy,
I have a .dll which wants to call functions in the .exe. When I
try linking the .dll, I get unresolved externals. NT, you see,
wants to resolve everything at link-time, unlike *nix which wants
to resolve at run-time.
Is there a way, on NT, to get a .dll to resolve externals
at runtime, like *nix, instead of at link time?
I know I can rewrite a whole bunch of everything, and move
functions around and bluh bluh bluh and get a successful
resolve at link-time. That's not what I'm looking for, however.
Any suggestions for this would certainly be appreciated.
Thanks in advance.
----------------------------------------
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
@ 1999-07-08 4:50 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
0 siblings, 1 reply; 16+ messages in thread
From: Emanuele ALIBERTI @ 1999-07-08 4:50 UTC (permalink / raw)
To: dj, rbresner; +Cc: cygwin
>I don't think so. What you'd normally do is have the exe call the dll
>at startup and pass it pointers to its functions, which the dll would
>store in per-process memory (remember that dlls are shared among many
>executables).
The DLL image is actually loaded once and memory mapped n-times in the
address space of each process that imports from it.
>One thing to try is to export the function with a .DEF file, and see
>if that works. 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.
Yes, it works. That is actually a quasi-static linking, because the loader
fails to initialize a porcess if it does not find each DLL in the process
image's imports table. You can also call an exported function by calling at
run-time LoadLibrary() and asking for an entry point with GetProcAddress().
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-08 4:50 Emanuele ALIBERTI
@ 1999-07-31 18:34 ` Emanuele ALIBERTI
0 siblings, 0 replies; 16+ messages in thread
From: Emanuele ALIBERTI @ 1999-07-31 18:34 UTC (permalink / raw)
To: dj, rbresner; +Cc: cygwin
>I don't think so. What you'd normally do is have the exe call the dll
>at startup and pass it pointers to its functions, which the dll would
>store in per-process memory (remember that dlls are shared among many
>executables).
The DLL image is actually loaded once and memory mapped n-times in the
address space of each process that imports from it.
>One thing to try is to export the function with a .DEF file, and see
>if that works. 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.
Yes, it works. That is actually a quasi-static linking, because the loader
fails to initialize a porcess if it does not find each DLL in the process
image's imports table. You can also call an exported function by calling at
run-time LoadLibrary() and asking for an entry point with GetProcAddress().
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
@ 1999-07-08 4:54 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
0 siblings, 1 reply; 16+ messages in thread
From: Emanuele ALIBERTI @ 1999-07-08 4:54 UTC (permalink / raw)
To: rbresner, dj; +Cc: cygwin
>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@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-08 4:54 Emanuele ALIBERTI
@ 1999-07-31 18:34 ` Emanuele ALIBERTI
0 siblings, 0 replies; 16+ messages in thread
From: Emanuele ALIBERTI @ 1999-07-31 18:34 UTC (permalink / raw)
To: rbresner, dj; +Cc: cygwin
>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@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
@ 1999-07-08 4:57 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
0 siblings, 1 reply; 16+ messages in thread
From: Emanuele ALIBERTI @ 1999-07-08 4:57 UTC (permalink / raw)
To: dj, rbresner; +Cc: cygwin
>Aye, there's the rub. It depends on whether NT considers the import
>address table to be a shared resource, or a per-process one. One can
>only try and see.
I guess: since the imports table is patched by the loader, it should be
per-process.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I get a .dll to resolve at runtime ?
1999-07-08 4:57 Emanuele ALIBERTI
@ 1999-07-31 18:34 ` Emanuele ALIBERTI
0 siblings, 0 replies; 16+ messages in thread
From: Emanuele ALIBERTI @ 1999-07-31 18:34 UTC (permalink / raw)
To: dj, rbresner; +Cc: cygwin
>Aye, there's the rub. It depends on whether NT considers the import
>address table to be a shared resource, or a per-process one. One can
>only try and see.
I guess: since the imports table is patched by the loader, it should be
per-process.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-07-31 18:34 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-07 14:42 How can I get a .dll to resolve at runtime ? Robert Bresner
1999-07-07 15:49 ` DJ Delorie
1999-07-07 16:13 ` Tor Lillqvist
1999-07-31 18:34 ` Tor Lillqvist
1999-07-07 17:01 ` Robert Bresner
1999-07-07 17:33 ` DJ Delorie
1999-07-31 18:34 ` DJ Delorie
1999-07-31 18:34 ` Robert Bresner
1999-07-31 18:34 ` DJ Delorie
1999-07-31 18:34 ` Robert Bresner
1999-07-08 4:50 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
1999-07-08 4:54 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
1999-07-08 4:57 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
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).