Mail Archives: cygwin/1997/01/16/00:01:14
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.
You can't compile the GNU version of grep with Visual C++; if you could,
we wouldn't need cygwin.
The point is that cygwin provides *unix semantics*. While grep
may not need much of that beyond filenames, something like bash
certainly does. There is a lot of code in cygwin.dll. Try reading
the winsupp sources sometime.
> > Figure on that size increase for every program compiled by the gnu-win32
> > kit...INCLUDING THE KIT ITSELF (e.g. everything in the binary
> > directory). Do the math (120+ files in the binary directory * 3 megs =
> 360+
> > additional megs)... and you'll see that a substantial chunk of your hard
> > drive has just disappeared. On top of that, add an additional 3 megs to
> > each executable YOU, as a user, compile with the gnu-win32 kit...
>
> Again, it would only be a very small amount for each program, because only
> a few functions each is only a couple of K for each program.
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.
But without such a static library, everyone is just guessing as to
exactly how much greater. But "a couple of K" isn't right; that
wouldn't even cover malloc. A recent discussion here was about how to
map inode numbers. Given that grep calls stat (if not directly,
then through stdio), and the stat buffer contains the inode number,
then the inode number mapping must be linked with grep, even
though grep has no need for that information. That's just a hint
of the sort of thing that must be included. Linkers on IBM mainframes
have all sorts of arcanery like NO_CALL options that allow you to
omit routines that are referenced but which you are sure will never
be called; these options were invented on small machines long before the
development of paging systems, where there just wasn't room. NO_CALL
is dangerous, and even it wouldn't help with the inode calculation,
since it *will* be called. For such a case, those mainframe programmers
(I were one) would write a stub routine that would return a constant or
junk. Again, very dangerous, and inflexible, and requires knowledge
of library internals. This is certainly not the sort of thing one wants
with cygwin. Heck, no one's even willing to simply add "b" flags to
fopen in all those programs that so desperately need it. [But note
that, in AT&T's UWIN flavor of unix on Windows, there is no such thing
as "text mode" (and they *certainly* don't return EOF upon ctrl-Z
(shudder)). Which, IMNSHO, is clearly the right way to go.]
> > Isn't it just much nicer to have one .DLL instead of statically linking
> > the entire cygwin library in? :) It's easy enough to write an Installer
> > for Win95 or NT which installs cygwin.dll as a shared file (which is what
>
> > I did for my program)... one copy of the file for everything that needs
> > it is much cleaner. ;)
>
> I think the good thing about the DLL is that you can update the dll without
> changing heaps of executable programs. That is the idea with most DLL's.
In the historical motivation for dynamic loading over the last
30 years of my personal experience, that has been a secondary
consideration, and a highly problematic one at that, given incompatible
library versions and programs that make unwarranted assumptions about
library behavior. The primary motivational force behind dynamic
libraries has always been reduction in the size of executables. Anyone
who has experienced static distributions of, say, the X windows system
could appreciate this.
--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -