How can I get a .dll to resolve at runtime ?

How can I get a .dll to resolve at runtime ?

[Robert Bresner]

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

Re: How can I get a .dll to resolve at runtime ?

[DJ Delorie]

> 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

Re: How can I get a .dll to resolve at runtime ?

[Tor Lillqvist]

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

Re: How can I get a .dll to resolve at runtime ?

[Robert Bresner]

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

Re: How can I get a .dll to resolve at runtime ?

[DJ Delorie]

> 	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

Re: How can I get a .dll to resolve at runtime ?

[Robert Bresner]

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

Re: How can I get a .dll to resolve at runtime ?

[DJ Delorie]

> 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

How can I get a .dll to resolve at runtime ?

[Robert Bresner]

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

Re: How can I get a .dll to resolve at runtime ?

[DJ Delorie]

> 	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

Re: How can I get a .dll to resolve at runtime ?

[Tor Lillqvist]

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

Re: How can I get a .dll to resolve at runtime ?

[Emanuele ALIBERTI]

>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

Re: How can I get a .dll to resolve at runtime ?

[Emanuele ALIBERTI]

>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

Re: How can I get a .dll to resolve at runtime ?

[Emanuele ALIBERTI]

>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

Re: How can I get a .dll to resolve at runtime ?

[Emanuele ALIBERTI]

>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

Re: How can I get a .dll to resolve at runtime ?

[Emanuele ALIBERTI]

>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

Re: How can I get a .dll to resolve at runtime ?

[Emanuele ALIBERTI]

>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