From: s2172184 AT cse DOT unsw DOT edu DOT au ("Ben Constable") Subject: Re: Why is cygwin.dll? 17 Jan 1997 13:43:42 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <970117050831.2887.cygnus.gnu-win32@cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Original-To: "Jim Balter" , X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Original-Sender: owner-gnu-win32 AT cygnus DOT com > 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".