[Top][All Lists]

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

Re: lynx-dev How to get Dos lynx to use the Windows winsocket dll

From: Heather Stern
Subject: Re: lynx-dev How to get Dos lynx to use the Windows winsocket dll
Date: Fri, 8 May 1998 16:44:31 -0700 (PDT)

I ate the fortune cookie first, then read what Michael Sokolov wrote:
>    Dear Heather,
>    You wrote:
>> vtailor > First you write this `terminate and stay resident' Windows
>> program
> >
> > If this uses memory space allocated to the DOS-box VM, you might run out
> > of memory for normal apps that might want the feature, even if you could
> > get it to work.  TSRs in general are famous for this problem.
>    I think that what this twit had in mind was not really a DOS TSR, but a
> Win16 task spinning in Windows' VM.

There would still be some memory cost in the DOS-box, if he hopes to have
it bridge between the two.  There'd be the inter-VM switch mechanism you 
mentioned, and it would cost something.

Jumping to the end so lynx folks can tell why I'm in this:
>...but one of my goals is to make the Win32 version of Lynx go away, and
> that requires making the DOS version completely and totally supersede it,
> which in turn requires giving users the option to use MS native networking.

You and I are certainly singing the same tune here, though perhaps in different
keys ...

> > Its "caveman" is a VxD which runs the application in the same VM as
> > standard Windows applications.  The usual benefit is that DOS apps which
> > use plain stdin and stdout (like PKZIP) don't force a new VM to be
> > spawned.
>    This is not a benefit, but a VERY bad idea. In this scenario you first
> have to forget about 32-bit DOS protected mode (DPMI) apps, since Windows
> is a 16-bit DOS protected mode app and the two can never coexist in the
> same VM ...
> > I suspect strongly that lynx-for-DOS does direct screen addressing, and
> > so would not qualify for the caveman VM.  

As for good idea/bad idea, flip a coin.  It saves time, at some risk, which
the JP Software programmers made an effort to avoid.  TCMD is fairly eager to
turn off the "caveman" feature.  If you want more details visit;
they wrote it, they have technical notes, and you're deeper into MSwin code
than I am.

I really mentioned it to introduce the idea of capturing screen I/O which
it does to a very limited degree, and then follow up with my ideas.

> > But a similar one, that provides screen calls that are sufficiently 
> > slang-like, might be the road to a real lynx for Windows.  
> > If it had a companion "DOS screen driver" that answered the same calls 
> > (whether they were slang, or something not-quite) then the same code 
> > could be shared for the rest of lynx-for-Microsofty-OSs.
>    But why not instead make Lynx a totally Windows-oblivious DOS protected
> mode app and have VDD/VKD/VMD trap its I/O and put it in a window, the way
> the DJGPP version works now? All your need to do is to replace Castrated
> DPMI with True DPMI and write a library for accessing DOSSOCK from a True
> DPMI app.

I've been reading horror stories at attempts to run DJGPP stuff co-existent
with other protected mode apps.  Sounds like it would cost extra resources 
for the trapping.  I think depending on the unusual feature of one compiler 
(though it sounds nifty) may also be a less than wonderful idea for
portability.  OTOH if they can provide these "modules" I describe at a level
that's usable to plain Joes, and users of other compilers, rather than having
to be special to each app, that's cool.

My concept would be for the MS' flavors, to seperate the "display" functions
from the action functions (like termcap terminfo ncurses or slang now?  Having
not delved, I suspect that division is already in place)... and take advantage
of it, by having the same main part usable if you're in or out of Windows.

Outside, it would call a DOS display-module (probably pretending to be curses?
Maybe someone can steal the applicable portions of the rogue, nethack, larn
or moria code for DOS?) and your DOSSOCK (or the CWRU version until you're 
done writing it).  If the interface to your DOSSOCK looks enough like WINSOCK
it might aide DOS/MSwin portability for developers staying in those platforms
as well.

Inside, it would call a DLL which would initialize a fixed-proportion screen
of nice size (maybe "nice" would even be user definable?), and make MSwin 
calls to do all the dirty display work.  It would use WINSOCK calls...
therefore it should be invisible to the user whether it use AOL's shim over 
its dialup, your DOSSOCK shim, or some other implementation.  Unless of 
course the "stack" (WINSOCK) version they use is broken.

People who feel like abusing their disk space could possibly have both in 
a single family mode app: "Lynx for Microsofty OS'" as I put it.  

If the DOS "display module", and the MSwin DLL "display module" had exactly
the same calls, this would end the agony of MS-DOS, Win3.x, Win32s, Win95,
and WinNT all possibly being wildly different ports.  (I think we're lumping
95/NT together the way it is right now, dunno about 32s.)  With these and
pssibly the SOCK calls being the same a family mode app wouldn't cost much

Beyond that if the "display modules" were sufficiently like one of the 
display flavors we already handle, we could stop having to think of the MS 
flavors as a nasty porting issue.  It would certainly be less important to
depend on a wild feature of DJGPP, and would likely make many other UNIX apps
far more portable as well.  If it also spoke ANSI, folks might consider it
a flavorful replacement for ANSI.SYS, provided it has a small enough memory

> > This is why the idea of having the true TCP stack at the DOS layer, and
> > providing a WINSOCK.DLL which is a shim over it, sounds more efficient,
> > if you can get it to work.
>    Heather, thank you very much for your support!

A simple matter of wanting networking at the lowest possible level in the
system, close to the bare bits.

>    Basically. A few fine points, though:

I hope the basic diagram was enough to carry it over to folks who don't
understand MSwin's wacky child-parent relations.  Thanks for the expansion;
though you're right, I miswrote "VxD" when thinking DLL.

> >         Windows' startup
>    I'm assuming that you mean WIN386.EXE, don't you? In this case please
> pay disrespect to Adolf the Gates of Hell and call it DOS386. (I'm assuming
> that you have read Andrew Schulman's _Unauthorized Windows 95_ cover to
> cover, haven't you? See page 62 near the top.)

I meant the 12 or 15 pieces that make up the "core" of operations, of which
DOS386 as you put it is the first portion. 

Actually I haven't inhaled that yet, though I have his other two books.  (In
fact just referred someone to his books two days ago at a user's group.) I've 
been pretty deep in the UNIX world in the last few years.  I really should 
get it one of these days... but w95 has such low priority in my life ;)

> Note that the latter can be achieved by means other than tunneling WINSOCK.
> It appears that the MS native networking is really implemented in VxDs like
> VIP.386, VTCP.386, etc., and that MS's WINSOCK.DLL is ALREADY a shim around
> those! In this case it would be a better idea to implement DOSSOCK in terms
> of those VxDs rather than WINSOCK.

This would surely restrict it to usable only within the confines of the
DOS-box rather than in a DOS which has no MSwin installed or running?

Being a DesqView fan I'm hoping for something that I can use across its
multiple sessions.  It's a much better multitasker than MSwin.  Being a 
completist I'd like maximum usability with the least number of moving parts.

  . | .   Heather Stern                  |         address@hidden
--->*<--- Starshine Technical Services - * - address@hidden
  ' | `   Sysadmin Support and Training  |        (800) 938-4078

reply via email to

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