Mail Archives: cygwin/1997/01/17/13:43:42
> 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
s2172184 AT cse DOT unsw DOT edu DOT au
-
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 -