Subject: Re: Why is cygwin.dll?
From: [email-masked] ("Ben Constable")

17 Jan 1997 13:43:42 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Original-To: "Jim Balter" <[email-masked]>, <[email-masked]>
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Original-Sender: [email-masked]

> You can't compile the GNU version of grep with Visual C++; if you could,
> we wouldn't need cygwin.

With very minor modifications you can compile a lot of character mode unix
code in watcom or visual c++. Besides, my point was that with a tiny amount
of modification, you can get a version of grep without cygwin.dll.
 
> 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.

I know that it is big, and there is a lot of code, but consider how few
programs use all of that code. It makes sense to have the ability to create
stand alone executables, if you want to. I never said that it would be a
good idea for everything, just for some executable files. If you want a
solution for the dll problem, write a proper subsystem.

> 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.

I agree. But some executables would be not very much bigger. Maybe a few K.
Making them easier to distribute over the net to friends.

> 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

Malloc? Why do we have to rewrite malloc? NT already has malloc...

> 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.]

I agree with you on these points. But the fact I was pointing out was
identical to yours. The original poster exagerated the amount of disk space
that static linking would require.

> 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.

For some people it is a primary consideration. Proper version checking
protocols within the library would ensure that version problems do not
arise as often.

And dynamic loading is a pain in the arse a lot of the time. It is fine
when you develop something on a machine for your own personal use, but when
it comes time to distribute the stuff, you have to give a few dll's to
somebody. And write an installation program that can detect versions of
dll's. I am not the only person sick to death of being told to download
this or that DLL.

And I thought that the other good thing about DLL's was that commonly used
code could be shared between applications.

Ben Constable
[email-masked]

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