lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Re: lynx_w32.zip feedback


From: tailor
Subject: lynx-dev Re: lynx_w32.zip feedback
Date: Fri, 17 Apr 1998 00:14:21 -0500 (CDT)

>     * From: Foteos Macrides <address@hidden>
>     * Date: Thu, 16 Apr 1998 23:21:05 -0400
>>
>>> >Foteos Macrides <address@hidden> wrote:
>>> >Wayne and Doug,
>>> >on invoking the W32 Lynx.  However, when I 'd'ownloaded a text file
>>> >(LYMail.c from the dev5 source breakout) and subsequently tried to view
>>> >it with Notepad, it was garbled due to non-recognition of newlines.  I
>>> >went to the MS DOS prompt and opened it with that editor, and it displayed
>>> >OK.  I then Save'd that, and it displayed OK in Notepad too.  This seems
>>> >to mean that Notepad needs CRLF, but the DOS editor doesn't, to recognized
>>> >newlines, and the DOS editor converts LFs to CRLFs on Save's.  Do you have
>>> >any recommendations on how to deal with all this more conveniently when
>>> >trying to view files 'd'ownloaded by Lynx when accessing them via Desktop
>>> >utilities?
>>> >
>>> First of all, depending on the exact version you downloaded, there was
>>> an _fmode = O_BINARY statement which evolved into a series of _fmode
>>> statements in the latest version, but the overall effect was to make
>>> text transfers look like Unix text.  Removing the _fmode statement has
>>
>>My understanding is that mode O_BINARY will make files PRINTed from lynx
>>have 0A EOL's, but will not convert text files already in MSDOS format,
>>with 0D 0A EOL's.

Not true.  When you are transferring text to tempfiles to pass to the 
mailto and postto editors, you end each line with putchar('\n'), which
on a Dos/Windows system becomes printf("\n\r"), unless _fmode==O_BINARY.
I think the code for this is in LYUtils.c.

Will someone please explain to me why oh why FNAMES_8_3 uses getpid(),
without (a) casting the value to unsigned and (b) doing a
getpid() % 10000?

>>archive file. There are several options. One is to convert them to DOS
>>form with a simple utility like "flip". The other main option is to use
>>utilities that deal with both unix and dos text files. Buerg's "list"
>>program and the "less" program work fine for viewing files. For an
>>editor, I prefer "vim", which has been ported to DOS and Win95. I
>>presume that "vile" also works fine with both types of files. I don't
>>use Win95 much, so I can't comment on its native editors, but the above
>>utilities can be used either directly from Win95 or in a DOS window.
>]
>     In src/HTFWriter.c there is code for modifying the characteristics
>of files downloaded to VMS.  Using that as a model, it would appear what
>is needed for the DOS/WIN/NT ports is code to check if the the downloaded
>file is text/*, and if so, something to "flip" it from streamLF to native
>DOS format.

You don't always know if the downloaded stream is text/*.  I suggest you
save your creativity for new features in lynx.
>
>        I would appreciate some substantive discussion of the pros and cons
>for choosing among the various compilers for Windows 95 systems.
>
>        I tried the MINGW32 Lynx, and it works fine, but I'm not clear on
>what comparisons are intended with the dev5 binary.

The point is that it works fine, and it doesn't crash when you use the
threads version of NSL_FORK. It also uses Dos `copy', `erase', etc.,
with no apparent ill effects. And, the lynx.cfg file can be set up to
do all sorts of nice things that you have come to expect under Unix.

>  Also, what is mc.exe?

GNU Midnight Commander ported to Win32 and looking mighty fine.

>The GTE server allows up to 10 MB for personal web pages, and address@hidden
>(What's your name?) has plenty of room for an HTML or text file that explains
>what those _exe.gz files are all about.
>
Just call me the masked man with the silver bullets.  And, it's 5 MB these
days and 250 MB traffic per month.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]