Re: lynx-dev cygwin patch

[Doug Kaufman]

On Sun, 30 Apr 2000, Klaus Weide wrote:

> On Sun, 30 Apr 2000, Doug Kaufman wrote:
> > There are other uses of DOSPATH that could affect cygwin, but
> > they don't all seem appropriate for cygwin. In addition, I
> > believe that we agreed that DOSPATH is deprecated, since it
> > had been used for things other than the path itself. I think
> > we are now trying to use individual defines (e.g. __DJGPP__
> > || _WINDOWS || __EMX__ || __CYGWIN__), 
> 
> I find that quite horrible.  And it seems there are constantly
> problems with keeping track of this kind of stuff, judging from
> the number of patches that fiddle around just with ifdef-conditions.

I agree that this is horrible. I am just not sure what the best
solution is. One of the problems is that I don't know who of the
developers is familiar enough with the different platforms to know
which changes are fine for multiple platforms and which are specific
to individual platforms. I haven't had any trouble with the cygwin
port and cp on my own computer, when compiled with full pathnames.
When I tried to compile without pathnames to create a binary that
might be a candidate for distribution, it picked up my DJGPP cp which
comes earlier in the path, and failed. I guess the question for
distributable binaries is whom they are aimed at. If aimed at (e.g.,
for cygwin) the usual Windows user who just wants to run lynx, it
needs to work with as little special knowledge and setup as possible.
I also thought that different binaries for the same platform (i.e.
Borland or cygwin compiled) should have compatible user interfaces, as
much as possible. This does conflict with keeping cygwin as close to
possible as unix.
  
> > so that quirks of each system can be addressed individually.
> 
> Many of them don't seem to address quirks of the "system" identified
> by the preprocessor macro (in this case, the cygwin environment), but
> some preference that someone (using that environment) thinks is
> more appropriate.

Indeed, the SH_EX changes are Senshu Hiroyuki's preferences, which
have not yet been accepted for general use. Clearly, anyone who
compiles their own binary can change the code as they like. The
question is what should be the default, and how easily should it
be configurable. At the other end of the spectrum we have multiple
defines in lynx.cfg. It seems too much to put all the choices in
lynx.cfg. Some must be made in the code itself. At this point, at
least for platforms where unsophisticated users may be majority of
users, I would favor uniformity within the platform.
  
> The "use cp or not" patch is a good example for this.

Since most Windows users wouldn't have cp, this saves the need to
distribute a compatible cp with the lynx binary.
 
> I am not currently a user of cygwin.  But if or when I become one,
> I image I'll be using it to get an environment that is as much as
> possible "Unix-like".  I certainly don't expect as much as possible
> "DOS-ish" behavior.  I'd expect a "cygwin port" of lynx to use the
> for-Unix code as much as possible (better tested, less bugs IMO),
> and let cygwin do its job of emulating a Unix-like environment.

This works best when the user has all the other unix-like tools and
programs installed. It is a potential problem for stand-alone programs
for distribution.
  
> Others may disagree (they apparently do), but that shouldn't be
> forced on all users of cygwin.

We need a few more people to try compiling a cygwin version of lynx,
so that we can get varied feedback as to where it works well and where
problems need to be fixed.
  
> So if all the input to lynx is in Unix-style form, and output is
> only fed to things that understand Unix-style output, where is the
> problem?  I'd expect lynx to work in that mode as it does on a Unix-like

One of the problems is feeding output to programs that don't
understand unix-style output, such as telnet. I have a telnet shell
script that calls the Windows program, making appropriate conversions.

> > I believe that there are
> > cygwin functions to convert, but they would have to be inserted
> > appropriately into the unix code (cygwin_conv_to_full_posix_path()
> > and cygwin_conv_to_full_win32_path()). 
> 
> I disagree with the premise that all users of a cygwin-using lynx
> would want or need such extra code.

I haven't recommended putting them in, and haven't in my personal
compile. See, howver, the LYSystem code in LYUtils.c when DOSPATH and
__CYGWIN__ are both defined.
  
> I am using neither; but I like the idea that I *could* use a lynx
> that's as-much-as-possible like the Unix lynx, if I went to use the
> cygwin environment.  Making all kinds of DOS-ish behavior depend on
> (just) __CYGWIN__ sabotages that, uhm, dream.

I think the cygwin port is still very much more like unix than like
DOS or Windows.
  
> Where conditional compilation is necessary, there should be sensible
> HAVE_* or NEED_* or WANT_* macros that allow to make a choice, not
> something like
>    (__DJGPP__ || _WINDOWS || __EMX__ || __CYGWIN__)
> that forces one kind of behavior on all users on some set of platforms
> (and is typically without any documenting comments in the code).

I am not sure how many of the defines are not required by the
platforms for binary handling, pathname handling, or TCP handling.
I suspect that very few represent personal choices between viable
alternatives, but I haven't looked closely at them. Once again, we
have a problem of few people on lynx-dev working on these different
platforms. Wayne Buttles has stopped contributing to the DOS or
Windows platforms. Hiroyuki has contributed quite a bit lately to the
Windows platform, but documentation has mostly been in Japanese. I
don't know if anyone is compiling with EMX/OS2. The fact that I am not
a programmer limits my contribution in general to small tweaks when
something isn't working correctly. I think that Leonid may be the main
person working on the DOS platform who is also a programmer
  
> Something like good old "DOSPATH" isn't bad because it is less specific
> than (some combination of) __DJGPP__, _WINDOWS, __EMX__, __CYGWIN__.
> DOSPATH is bad because it has never been defined what it's supposed
> to mean, and it had come to mean the kitchen sink of DOS-like behavior.

I know that FNAMES_8_3 came out of similar discussion. Does anyone
have any suggestions on clearing this up some before 2.8.4 gets
released?
                               Doug
__ 
Doug Kaufman
Internet: address@hidden