Mail Archives: djgpp/2000/06/03/13:46:47
"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> 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...
<Grin> 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)
- Raw text -