From: colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters) Subject: DLL Data and Copy-on-write (was RE: Why is cygwin.dll?) 20 Jan 1997 01:56:40 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com 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'" Original-Cc: "'GNU-Win32'" Original-Sender: owner-gnu-win32 AT cygnus DOT com Fran Litterio[SMTP:flitterio AT amulet DOT com] 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 - colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp -- 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 "gnu-win32-request AT cygnus DOT com" with one line of text: "help".