Re: exporting global variables from dynamically linked libraries

From: Tauno Voipio (tauno.voipio_at_iki.fi.NOSPAM.invalid)
Date: 08/15/03 

Date: Fri, 15 Aug 2003 07:08:41 GMT

"David Schwartz" <davids@webmaster.com> wrote in message
news:bgs23s$6e6$1@nntp.webmaster.com...
>
> "VBDis" <vbdis@aol.com> wrote in message
> news:20030806062302.21428.00001534@mb-m23.aol.com...
>
> > Im Artikel <vitcpm4pr7jt9b@corp.supernews.com>, Boris Bak
> <boris.bak@ni.com>
> > schreibt:
>
> > >The problem I experience is somehow the application has defined its own
> > >copy of those variables.
>
> > This IMO is the defined behaviour of DLLs, at least in Windows. The code
> (CS)
> > is shareable, but the data (DS) are private to the processes.
>
> First of all, this statement is misleading. The code is *NOT* shared
and
> more than the data is. If you don't believe me, modify the code in one
> process that's using the DLL and see if the other process sees the
> modification.

1. The executable pages are not writable to the process having them
executable, unless there is an alias mapping in the hardware (hardware
limitation). You cannot modify the running code. If the code modification
succeeds (with a debugger), you are not seeing the same memory anymore, it's
the COW (copy on write) in action.

2. Although the code is in common memory, it may be mapped to different
linear addresses at each process using it. This is the reason why the shared
libraries have to be position-independent code.

3. If you're after shared memory (like the DLL memory in 16-bit Windows
DLL's, but not in 32-bit DLL's) you need to use different techniques. Google
for Linux shared memory (e.g. <http://fscked.org/writings/SHM/shm.html>).

For a more detailed treatment, see:

W. Richard Stevens, Advanced Programming in the UNIX Environment.

> Both the code and data segments are mapped the same way. They start
out
> as seen in the file and each process' modifications are private.

The data is mapped so that COW creates separate pages per process as soon as
they are written into. This does not normally apply to code.

HTH

Tauno Voipio
tauno voipio @ iki fi

Relevant Pages

  • Re: writing overlays with VB6
    ... memory assigned to the process. ... Windows design guide lines - which have partly been enumerated here (refer ... Unloading a DLL only tells Windows that it is no longer needed by your ... ActiveX DLL (VB itself has nothing to do with loading or unloading of the ...
    (microsoft.public.vb.winapi)
  • Re: Where did my VB function go?
    ... If the VB application loads the C++ DLL, the DLL gets ... And there is a very common error with shared memory, ... A DLL has a shared memory section. ... series of coherent linked lists local to each attached process. ...
    (microsoft.public.vb.winapi)
  • Re: VB and dlls
    ... I have a question regarding how VB calls dll files and loads/unloads them ... 10 minutes) some of these dll's unload. ... Objects are closed under the sole control of Windows. ... Windows holds objects in memory in case they need to be used again. ...
    (microsoft.public.vb.general.discussion)
  • Re: Memory Management Tools
    ... Memory limits in 32 Bit world. ... There is still a fairly high risk in moving ... One area where real optimization actually is possible is DLL rebasing. ... Well, the Windows loader, which loads the DLL into memory (which in ...
    (microsoft.public.windows.terminal_services)
  • Re: new / delete in a dll
    ... memcpy(&ob.pData, pData, width * height); ... In my dll, i'm calling 'new' to allocate the correct amount of memory to ... Is this involving shared memory data segments? ...
    (microsoft.public.vc.mfc)
Loading