Subject: DLL Data and Copy-on-write (was RE: Why is cygwin.dll?)
From: [email-masked] (Colin Peters)

20 Jan 1997 01:56:40 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <01BC06F2.09F5FEA0.cygnus.gnu-win32@gbird0>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Original-To: "'Fran Litterio'" <[email-masked]>
Original-Cc: "'GNU-Win32'" <[email-masked]>
Original-Sender: [email-masked]

Fran Litterio[SMTP:[email-masked]] wrote:
>Of course, data pages are a different story.  Does anyone know if NT
>does copy-on-write?  I've heard that NT won't let you put data into a
>DLL -- only pointers to data (but aren't pointers data too?).  If anyone
>can clarify this for me, I'd appreciate it.

NT does copy on write. When calling VirtualAlloc:

LPVOID VirtualAlloc(LPVOID lpAddress, DWORD cbSize, DWORD fdwAllocationType, DWORD fdwProtect);

Add the flag PAGE_WRITECOPY or PAGE_EXECUTE_WRITECOPY to fdwProtect.
Even Windows 95 sort of supports this, except that it does the copy
right away without waiting for a write (yes it's inefficient, but
the semantics are preserved at least).

By the way, from another part of Advanced Windows by Jeffery Richter
(Microsoft Press):

	"When an EXE or a DLL file is loaded from a floppy disk, both
	Windows 95 and Windows NT allocate storage for the entire
	file from the system's paging file. The system then copies the
	file from the floppy into the system's RAM and the system's
	paging file; the paging file is said to back the RAM."

In other words a large DLL does in fact use virtual memory even if
you don't ever call any of it's functions. This does not, however,
eliminate your point as far as physical RAM is concerned (only as
much as is needed is swapped in).

As far as not allowing data in DLLs: simply not true. However, Win32
DLLs are significantly different from Win16 DLLs in that a DLL does
not get it's own data segment that it shares with all other instances
of the same DLL. Instead it's data is mapped into the process
address space and backed separately in the paging file, so each
process's instance of a DLL will act like it is the only instance of
the DLL. This should help keep a crash in one instance of a DLL from
crashing other programs using the same DLL.

In fact Win32 DLLs allow you to export variables as well as function
calls (or they should, the current version of gcc does not, as far
as I know, allow this usage). As far as application code is concerned
a DLL is (almost?) indistinguishable from a static library. Of course
there are still all the issues of static vs. dynamic which have already
been discussed in the "Why is cygwin.dll" thread.

Colin.

-- Colin Peters - [email-masked]
-- Saga University Dept. of Information Science
-- Fundamentals of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/home.html

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".