From: pjfarley AT banet DOT net (Peter J. Farley III) Newsgroups: comp.os.msdos.djgpp Subject: Re: netbd.h, sockets.h, in.h and types.h don't work Date: Sat, 03 Jun 2000 17:33:59 GMT Message-ID: <39393dbc.1761050@news3.banet.net> References: <3936DA62 DOT 9581F9CE AT bigfoot DOT com> <3936feb4 DOT 2522956 AT news3 DOT banet DOT net> <200006020819 DOT LAA02863 AT alpha DOT netvision DOT net DOT il> X-Newsreader: Forte Free Agent 1.21/32.243 NNTP-Posting-Host: 32.100.85.185 X-Trace: 3 Jun 2000 17:32:05 GMT, 32.100.85.185 Organization: Global Network Services - Remote Access Mail & News Services Lines: 77 X-Complaints-To: abuse AT prserv DOT net To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Eli Zaretskii" wrote: >> From: pjfarley AT banet DOT net (Peter J. Farley III) >> Newsgroups: comp.os.msdos.djgpp >> Date: Fri, 02 Jun 2000 01:22:14 GMT >> >> May I make the suggestion that networking headers should not even be >> present in djdev if there is no library support for them? > >Sorry, this isn't possible, at least not in the simple way you suggest >(i.e. removing the headers). Posix requires those headers, and DJGPP >is Posix-compliant. > >I'm sure there are other solutions to such problems. However, to >devise them, one needs to know the particulars (like what headers >and/or macros does the configuration procedure look for). Understood. I thought that might be the answer. In the case of the application I mentioned, it seems to want TCP/IP for sockets, including whatever is needed for http communications. Despite the fact that the product *can* be used for non-networked applications, the developers are quite focussed on its networking applications, so they make many networking assumptions. >> But it really would be finer if the zip-picker asked if >> you wanted DOS networking capabilities, and gave you the appropriate >> networking zips as well as the basic development zips, and if the >> networking zips you downloaded worked just like all of the other fine >> ports which with we have been gifted by the DJGPP workers. > >A similar solution (of having several separate libraries) was found to >be a PITA in DJGPP v1.x: people expected everything to be magically >present in one library that's scanned by default by the linker, and >constantly complained about unresolved externals. So separate >libraries for djdev seem like a bad idea, in the long run. Yes, I can see where that would present a real support problem. Just a further thought for consideration: What if the installation of a (stable, robust) networking library merged it into libc? I.E., instead of establishing a separate library, "make install" for the networking library components would add the ".o" files into libc, thus providing a single source for linker resolution? Along with installing all the networking headers in "standard" include directories, of course. I understand that this presents a far more complex scenario for patches to libc and/or the networking library, and makes re-installation and version/release upgrades more of a PITA, but hopefully our environment is stable enough to make these the exception rather than the rule. >> For those new to the networking libraries/headers, it would be nice to >> see a short FAQ somewhere > >Experience shows that FAQs are not read too religiously... No kidding... But some of us do occasionally remember to RTFM, even if we have to be reminded of it now and then... :) >> Of course, it would also be finer if application package developers >> didn't incidentally *assume* so much, and allowed for environments >> that don't actually support networking. <*Sigh*> > >If the problems with their assumptions are reported to them, they >might do something. But that shouldn't prevent us from trying to make >things easier from our end, as much as possible, without compromising >compatibility and compliance to standards. Agreed, and I plan on reporting what I have seen to the application developer, but since their orientation happens to be network-centric at the moment, I don't see a lot of change coming anytime soon. I also agree that we need to try to make things easier from our end, within standards. ---------------------------------------------------- Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR pjfarley AT nospam DOT banet DOT net)