From: jqb AT netcom DOT com (Jim Balter) Subject: Re: Why is cygwin.dll? 16 Jan 1997 22:22:44 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <32DED6F1.6095.cygnus.gnu-win32@netcom.com> References: <009AE761 DOT 42405F80 DOT 7322 AT ifk20 DOT mach DOT uni-karlsruhe DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: dahms AT ifk20 DOT mach DOT uni-karlsruhe DOT de Original-CC: gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com dahms AT ifk20 DOT mach DOT uni-karlsruhe DOT de wrote: > > Hi, you wrote: > > : Ben Constable wrote: > : > > : > > Now, figure on programs like grep.exe (91,648 bytes) having to include > : > > that library in their .EXE...grep is now 3 megs, instead of 91k. > : > > : > No. That is totally wrong. Go compile grep or a similar program with watcom > : > or visual C++. You will find that they do not have to be that big. It is > : > because when you link the program, you only link the bits you need. > > : Any university offers courses that will cover the tradeoffs between > : dynamic and static libraries; it seems some readers of this group > : could benefit from such an education. Given a static cygwin library > : (but we *aren't* given one, not yet), the sum of the sizes of all the > : executables linked with such a library would be considerably greater > : than the current distribution. Not nearly 3M * 120 greater, true. > > What was not mentioned yet is that a DLL is only loaded once into RAM and > shared by multiple processes. So you occupy never more than 3MB RAM > regardless of how many processes are running at the same time. > And even then a modern OS need only to page in that parts actually used. Silly me; you and Barry Roberts are of course right to point out the very significant shared memory aspect that I omitted to mention. A staticly linked executable can of course only share among multiple instances of itself; no pages are shared across executables (static library routines won't even be at the same location within a page). I used to live and breath unix kernel paging code; too much time out of those trenches, I guess :-) Paging brings up an interesting issue: a well-organized shared library can reduce memory usage and paging by localizing functions on the same page that end to call each other. I don't know how many people bother to do this, or if there are automated tools (there ought to be). -- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".