- From: Garrett Arch Blythe <doslynx@falcon.cc.ukans.edu>
- Date: Wed, 13 Jul 1994 21:53:17 -0500 (CDT)
- To: "Daniel W. Connolly" <connolly@hal.com>
- Cc: Multiple recipients of list <www-lib@www0.cern.ch>, lynx-dev@ukanaix.cc.ukans.edu
Hi all, Lynx-devers, this is for you also, we're talking about the language choice (full ANSI C or continue supporting K&R C too) to be used in libwww (CERN's library for the WWW which Lynx uses); to be used in light of our C++ discussion (RE: lynx future.....) On Thu, 14 Jul 1994, Daniel W. Connolly wrote: > In message <Pine.3.89.9407131652.B25291-0100000@falcon.cc.ukans.edu>, Garrett Arch Blythe write > s: > >On Wed, 13 Jul 1994, Daniel W. Connolly wrote: > >> > >> The rest of the users are just that -- users, and they'll be much happier > >> with a compiled binary distribution than a K&R C source distribution, > >> I wager. > > > >This is not going to work. Lynx as it stands has about a kazillion > >different little ifdefs that Lou left me with, so each compiled binary is > >actually different than perhaps the one that I use for debugging which > >has everything turned on. The reason why the configuration is at > >compile time is to leave out some security problems that some people > >simply don't want to deal with, ever. > > Shame on Lou. #ifdef's are evil. But certainly 80-95% of the world's > lynx users are using the same combination of #ifdefs anyway. Right. I'd assume that they are. The vanilla build is most generally used. > I expect that two or three compiled versions of the code would suffice > for the vast majority of the user population: one with all the gaping > security holes wide open, one with all of them turned off, and one > somewhere in between. Probably; the details are not worth explaining. Your point is obvious. > >Precompiled binaries suck. They don't give the person installing full > >control of the options provided (for security) and they can't set it up > >specifically for their system. > > These are not insurmountable problems. A well designed product has > all the installation-time and run-time switches needed by its customer > base. Yes, they aren't insurmountable. What can I say? I don't want ANSI C to cause my users less grief; as I said some only have K&R C; Many of the people I talk to daily are interested in the source and not the precompiled binary. This is not such a bad thing. We as developers want ANSI C to clean up the code/make it easier to read; a very very good thing. I want to hear a clear decision about wether or we should be using ANSI C and to stop supporting K&R C in libwww. I want to know that libwww is going to be in ANSI C so that I can stop worrying about the ARGS macros and start coding ANSI C myself. And mainly for the Lynx-devers: > Folks who aren't willing to wait for supported configurations can > get the source and build it, of course, but they'll need an ANSI C > compiler. > > I think this is the best way to provide quality software to the > largest audience. Witness the explosion of Linux. > > >I also don't have access to all the machines that I would need to provide > >a Lynx binary for, which is every UNIX/VMS/DOS box on the globe. > > But: do you have access to _one_ person using each platform who has an > ANSI C compiler and would be willing to provide binary distribtions? > That's all you need. Okay, truth be known I want parts of Lynx in C++, as soon as I hear the decision you are going to pass down regarding ANSI C, may be a big factor on my decision. If I have to go ahead and make contacts with people to make me pre compiled binaries just for ANSI C, why don't I just go all the way and find people to make C++ binaries for me for the people without a C++ compiler? Many of my users don't have ANSI C; many more of them also don't have C++. But I am sure one of them has a C++ compiler for every different OS/Version. Any takers? Garrett. Trodden Soil I am trodden soil. Dust covers my face. Soles crush my nature Revealing a hard empty space. Garrett Arch Blythe (913)864-0436 User Services Student Programmer/Consultant University of Kansas Computer Center <doslynx@falcon.cc.ukans.edu>
Received on Thursday, 14 July 1994 04:53:20 UTC