Re: lynx-dev lynx2-7-2ms.zip update

[Foteos Macrides]

address@hidden (Michael Sokolov) wrote:
>> Do you have a projection of when a binary will be available?
>   
>   I'm assuming that you mean the DOS binary, not the VAX Ultrix
>one, right?

Correct.


>    Well, before I can make a binary I first need to port
>Lynx v2.7.2 to DOS, and I haven't made any steps in this
>direction yet. Strictly speaking, I need to complete my work
>on DOSSOCK and 32-bit True DPMI before I can even start porting
>Lynx to this environment.

I guess my question then boils down to whether you have a
projection on when those will be available, and apparently
it's still too soon for you to make one.


>                            Once these two cornerstones
>are in place, the Lynx-specific part should be very easy.
>[...]

The two main things beyond networking and DPMI issues are
the URL_path to/from file_system interconversions, and
compressed file handling.

   
>> Will the binary be useable with WIN95  homologously to
>> Wayne's Borland-compiled binary and the MingW32 binary?
>   
>   Since Win95 contains DOS386, the reference implementation
>of True DPMI, the Lynx executable will run beautifully under it.
>It will access the network via DOSSOCK, so if you need it to
>use Win95's native networking implementation, you'll need a
>DOSSOCK shim for Win95. I'll definitely provide one, although
>I don't know yet whether it will access the Win16 WINSOCK DLL
>via an inter-VM communication mechanism or talk directly to the
>VxDs used by this DLL itself (VIP.386, VTCP.386, etc.).

There's also the issue of whether/how to use threading, and in
turn whether that creates compiler dependencies.


>> Note that MSIE and Opera can't access your ftp server.   MSIE
>> hangs, and Opera immediately issues a can't connect message.
>> The MS standalone ftp does succeed, as do the two Lynx binaries.
>
>   Hmm, this is interesting. My FTP server is the most "straight"
>and classical one: a UNIX machine with FTP access enabled via the
>appropriate line in /etc/inetd.conf and anonymous FTP enabled via
>the appropriate line in /etc/passwd. I don't know what could be
>better. OTOH, the OS is Ultrix, which diverges from Berkeley
>UNIX(R) at the level of 4.2BSD (the very first ARPAnet-capable
>version of UNIX in history) and loses the significant networking
>improvements of later versions of Berkeley UNIX(R) (primarily
>4.3BSD and 4.3BSD-Tahoe). If/when I manage to get a copy of those
>tapes Harhan's service should improve dramatically.

 The MSIE ftp gateway is poorly implemented in a number of
respects, but I was surprised that Opera had problems as well,
particularly because those two Lynx binaries didn't.  The Lynx
gateway is using PORT, which works fine with your ftp server.
Your server doesn't know SYST, and returns 500 for that, so
Lynx has to guess what kind of server it is.  Lynx thus does
a PWD for the login directory, then on getting "/" for that
does an MACB, which fails, leading to the inference that it's
a "straight" and classic UNIX machine.  I mentioned it because
the DJGPP binary has problems with ftp (and news) for reasons
that are not yet understood.  But apparently, "strange" failures
can occur, at least for those two GUIs, even when using the
WIN95 native networking implementation.


 On a related note, I've gotten lots of info about the
WIN95 API at this point, though I'm still just "digesting" it.
It has all the VM functions a programmer could want for checking
memory useage and making rational decisions on whether to dump
any VM cache.  The page file size supposedly has a maximum of
4 GB, with sub-maxima of 2 GB for users and 2 GB for the kernel,
and functions also exist for checking page file useage directly.
But having no hands on experience yet with programming for that
API, I was hoping someone would comment on Bela's assessment of
it's bugginess, and prediction that disk caching would be better
in this case.  Particularly with that API having the reputation
of being "whatever MicroSoft did last month", a disk caching
strategy seems more likely to be stable across upgrades of the
API.  On the other hand, I haven't fully grasped what your
"True DPMI" will offer that might be more stable compared to
"whatever MicroSoft did last month".  If disk caching is used,
there's also the option of mapping source files to be treated
like memory (the "most" strategy), which would be fine for source
files (as opposed to the rendered structures for use of software
as a hypertext browser, not just file viewer :).

Fote
-- 
Foteos Macrides