.so v/s .dll

Hi,

I have worked on dlls on Windows. I know that so(shared object) files
are similar to dlls.

- Could someone point me to a link where I can read about how so files
are created, their intricacies (like .def file, dependency walker etc
for dlls).
- Also how does one link statically or dynamically to a so file (like
for dll one can use GetProcAddr etc for dynamic linking).

Thanks.

K.M Jr wrote:
> Hi,
>
> I have worked on dlls on Windows. I know that so(shared object) files
> are similar to dlls.
>
> - Could someone point me to a link where I can read about how so files
> are created, their intricacies (like .def file, dependency walker etc
> for dlls).
> - Also how does one link statically or dynamically to a so file (like
> for dll one can use GetProcAddr etc for dynamic linking).

http://www.tldp.org/HOWTO/Program-Library-HOWTO/

opwv_pspl_test2@yahoo.com (K.M Jr) writes:

> Hi,
>
> I have worked on dlls on Windows. I know that so(shared object) files
> are similar to dlls.
>
> - Could someone point me to a link where I can read about how so files
> are created, their intricacies (like .def file, dependency walker etc
> for dlls).

http://www.skyfree.org/linux/references/ELF_Format.pdf

> - Also how does one link statically or dynamically to a so file (like
> for dll one can use GetProcAddr etc for dynamic linking).

That's not static vs. dynamic linking, but what you are looking for is
dlopen() and dlsym().

--
Måns Rullgård
mru@mru.ath.cx

K.M Jr wrote:
> Hi,
>
> I have worked on dlls on Windows. I know that so(shared object) files
> are similar to dlls.

Another useful reference is Sun's libraries and linker guide at
http://docs.sun.com/db/doc/817-1984

Note that in the Winders world, as I'm sure you know, at runtime DLLS
are not completely in-process.  You have all the confusion of how to
share symbols between the process and the DLLs and how to manage memory
allocated on one side versus the other.

In the *nix world at runtime the .so objects are just as in-process as
they would be if you statically linked the equivalent lib*.a.  Your
process has one address space and one symbol name space.  How you
manage memory with malloc and free is independent of what binary
objects were linked together to create the process.

-- ced

>
> - Could someone point me to a link where I can read about how so files
> are created, their intricacies (like .def file, dependency walker etc
> for dlls).
> - Also how does one link statically or dynamically to a so file (like
> for dll one can use GetProcAddr etc for dynamic linking).
>
> Thanks.


--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

Chuck Dillon <spam@nimblegen.com> writes:

> Note that in the Winders world, as I'm sure you know, at runtime DLLS
> are not completely in-process.

I think you are talking about 16-bit Windows here.
In 32-bit Windows (aka NT), the DLLs are just as "in process"
as DSOs are on Unix.

>  You have all the confusion of how to
> share symbols between the process and the DLLs

This confusion does not exist on NT (I don't know if it existed on
"old" Windows).

> and how to manage
> memory allocated on one side versus the other.

Windows support multiple heaps. This has little to do with DLLs:
you can write a single EXE using 2 heaps, and you'll have to keep
track of which heap an allocation came from.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov wrote:

> Chuck Dillon <spam@nimblegen.com> writes:
>
> 
>
>
> I think you are talking about 16-bit Windows here.
> In 32-bit Windows (aka NT), the DLLs are just as "in process"
> as DSOs are on Unix.
>
> 
>
>
> This confusion does not exist on NT (I don't know if it existed on
> "old" Windows).

Sure it does.  By default DLLs have their own "data segment" which is
what I was referring to when I suggested they are not entirely "in
process".  Poor use of terms on my part.

The point is that you have to jump through some hoops to build a DLL
that is close to what an .so is on UNIX.  For example, using
MicroSoft's implementation of the C runtime library (a DLL) can be
problemattic.  The memory/object management in the C runtime is
partitioned relative to the main process.

From the knowledge base article "Creating Dynamic-Linked Libraries
Without Data Segments"...

"By default, each DLL has its own data segment, separate from that of
the calling applications. This default behavior precludes using some of
the standard Windows-application programming practices and C run-time
functions in a DLL. This article discusses techniques to ensure that no
data segment is created for a DLL."

<end of quote>



>
> 
>
>
> Windows support multiple heaps. This has little to do with DLLs:
> you can write a single EXE using 2 heaps, and you'll have to keep
> track of which heap an allocation came from.

and you have to jump through some hoops, that don't exist in the *nix
world, to build a DLL that shares heap/data segment with the main process.

-- ced


--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

Chuck Dillon <spam@nimblegen.com> writes:

> By default DLLs have their own "data segment" which is
> what I was referring to when I suggested they are not entirely "in
> process".  Poor use of terms on my part.

But so do UNIX DSOs.

Where do you think static variables local to DSO reside?
That doesn't make them somehow "out of process".

> The point is that you have to jump through some hoops to build a DLL
> that is close to what an .so is on UNIX.

I understand what you are referring to, but I think you don't have
much (recent) experience with Windows DLLs.

To build a DLL that would function pretty close to a UNIX DSO (at
least WRT malloc) all you have to do is compile and link everything
with /MD switch.

> For example, using
> MicroSoft's implementation of the C runtime library (a DLL) can be
> problemattic. The memory/object management in the C runtime is
> partitioned relative to the main process.

Not if you compiled everything with /MD.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

> > By default DLLs have their own "data segment" which is 
>
> But so do UNIX DSOs.


UNIX DSOs == Dynamic Shared object Library, right ? Those that need
dlopen(), dlsym(). Please correct if I am wrong.
 
>
> Not if you compiled everything with /MD.

Yep, that's right. I once had a Xerces (XML parser) dll that allocated
memory and I had to free the memory on the main program. It didn't
work till the time I told compiler to make it as a multithreaded dll.

So do we likewise need any switch for a UNIX DSOs so one can release
memory allocated by the DSO ?

Thanks.

opwv_pspl_test2@yahoo.com (K.M Jr) writes:

> UNIX DSOs == Dynamic Shared object Library, right ?

Right.

> Those that need dlopen(), dlsym().

No, you don't need to use dlopen() in order to use DSOs any more
then you need to use LoadLibrary() in order to use DLLs.

> So do we likewise need any switch for a UNIX DSOs so one can release
> memory allocated by the DSO ?

No, it works on UNIX without any special switches (which is the
point Chuck Dillon was trying to make, I think).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov wrote:
> Chuck Dillon <spam@nimblegen.com> writes:
>
> <snip>
> 
>
>
> I understand what you are referring to, but I think you don't have
> much (recent) experience with Windows DLLs.

Actually, I only have fairly recent experience.  I don't have much
historic experience nor knowledge of Winders SDK internals so some of
my efforts to elaborate were inaccurate.  My primary point revolves
around the C-runtime implementations in the Winders world and the
various complexities it can introduce.  Those complexities are directly
related to sharing information across/between the libCRT ABIs.  Perhaps
it is inaccurate to extrapolate the seemingly assinine limitations of
the CRT implementations to the architecture of DLLs.

>
> To build a DLL that would function pretty close to a UNIX DSO (at
> least WRT malloc) all you have to do is compile and link everything
> with /MD switch.

Again, *pretty close* is a lot of the point I was trying to make.  It
is over-simplifying things to suggest just link /MD.  When 3rd party
DLLs are involved compatible links might not be possible or might
require special builds from the vendor if they will provide them.  They
might just say: "What do you mean you're not building an MFC app?" If
you need the C-Runtimes (CRT) DLLs you can run into conflicts just
mixing MS technologies.

>
> 
>
>
> Not if you compiled everything with /MD.

Like I said, that is easy to say but not always doable.  It's a
most-of-the-time solution.

-- ced


--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.