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

[Michael Sokolov]

   Dear Fote,
   
   You wrote:
> 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.
   
   Correct.
   
> The two main things beyond networking and DPMI issues are
> the URL_path to/from file_system interconversions, and
> compressed file handling.
   
   I don't think there will be any problems in these areas.
   
> There's also the issue of whether/how to use threading, and in
> turn whether that creates compiler dependencies.
   
   Few implementations of 32-bit protected mode multitasking DOS are
multithreaded (most provide multiple VMs but only one thread in each), so I
won't use threads in something as generic as Lynx. I'm assuming, however,
that you are talking about interruptible DNS lookups, aren't you? In this
case what the ass-headed address@hidden doesn't realize is that you DON'T
NEED things like WSAAsyncGetHostByName() in Winsucker in order to get the
ability to interrupt DNS lookups. DOSSOCK will be much closer to the true
BSD sockets than to WINSOCK. Under UNIX gethostbyname() is a library
routine that compiles into apps themselves, and only things like socket()
and connect() are actual system calls. The same will be true for DOSSOCK.
Among other things this means that you can customize the resolver routines
in any way you want. For example, you can modify them to use non-blocking
sockets and periodically check a flag (a global variable) while waiting for
a DNS response, aborting with an error return if the flag is set. Voila!
You now have interruptible DNS lookups! Actually, the same can be done
under UNIX too, providing a much nicer way to interrupt DNS lookups than
the current ugly forking scheme. (Under True Berkeley VAX UNIX(R) with the
True Berkeley VAX virtual memory implementation a fork is expensive, since
there is no copy-on-write feature.)
   
> The Lynx
> gateway is using PORT, which works fine with your ftp server.
   
   As it should, since PORT is what the Holy Original FTP RFC calls for.
   
> Your server doesn't know SYST, and returns 500 for that, so
> Lynx has to guess what kind of server it is.
   
   This is certainly an Ultrixism. I'm pretty sure that all flavors of
4.3BSD support SYST.
   
> 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.
   
   What's MACB? I don't think it's in the RFC, although I don't have it
handy to check.
   
> I mentioned it because
> the DJGPP binary has problems with ftp (and news) for reasons
> that are not yet understood.
   
   These problems are understood very well by me. They are due to the
crappiness of WATTCP, the TCP/IP stack that's statically compiled into the
DJGPP version of Lynx. Note that the DOSSOCK version won't have any stacks
statically compiled-in by definition, so its performance and reliability
will depend solely on those of the DOSSOCK implementation you are using.
   
> 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.
   
   This has zero relevance to my version of Lynx. You are talking about the
Win32 API here, and Lynx should be (and will be in my version) written for
DOS32 (properly called DOS Protected Mode Interface).
   
> 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".
   
   True DPMI has been stabilized some time in the fall of 1989. As far as
virtual memory is concerned, DPMI pretty much leaves this up to the
implementor. Since Lynx should work will any True DPMI implementation, it
should not (and will not in my version) tinker with virtual memory aside
from pagelocking interrupt, exception, and real mode call-back handlers as
required by the DPMI spec and marking the DOS memory it uses as pageable
and discarding the contents of the pages it doesn't use as recommended by
the same spec.
   
> If disk caching is used,
> there's also the option of mapping source files to be treated
> like memory [...]
   
   While some True DPMI implementations support memory-mapped files, most
of them don't, and I won't rely on this in Lynx.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden