Fri, 28 Oct 88 09:01:29 edt
> From: hpda!hpcupt1!hpisod1!renglish@ucbvax.Berkeley.EDU (Robert English)
> Saying "users don't want to be bothered" trivializes the issue somewhat.
> There are many DOS applications in which users never see the actual
> files involved. The application presents them with menus to perform
> tasks, and manages the files itself. A user who had to transfer all of
> the necessary files over via FTP would have to be much more
> sophisticated than one who merely used the application.
I agree with most of what you say above.
> Furthermore, there is the issue of file-sharing. If users access the
> files on the remote machine directly, they can share effectively share
> data with other users. If they must copy the data back and forth, they
> are likely to get inconsistent versions, forget to do the copies, etc.
> (I know, you've never walked away from a terminal without writing out a
> Working in a non-transparent environment is significantly more
> complicated than working in a transparent one.
Here is where I have the problem. If you are talking theory or ideals
you are right of course. If you are talking implementations of
NetBIOS/TCP then perhaps the memory issue needs to be revisited.
If you have an MS-DOS machine, you may find 256k or so of your available
memory space gone to provide this transparency (example 3c505, FTP SW,
IBM PC LAN program rdr). Cut off another 60 - 80k for DOS and many
of the applications that provide the user with menus and manage the
files cannot run. Then what does transparency buy you?
There are work arounds. The Excelan implementation requires
less memory, I think it was about 80k for RDR. Also for those
with 80386 chips there are supposedly programs that allow TSR type
SW or device drivers to run in memory space above 1mb. There is
also OS/2 [I'm still waiting for the promised Oct update to my SDK
Microsoft!!!!]. However, for the present, I have serious
doubts that NetBIOS/TCP is providing usable services to anyone.
It is my belief that the vendors who invested time/effort/
brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan,
Bridge [they weren't 3Com at the time], Network Research Corp) wish
they had placed their investment somewhere else like NFS or OSI or
Finally file sharing. A simple file locking scheme may not be
sufficient to make file sharing truly useful. Ever write code
with someone else? What if the only mechanism for
Source Code Control was that the file was locked after
a user had it? That is why we RCS and friends. I have never
written a document with anyone else, but I suspect you would
run into some of the same problems. This is why multi-user
databases handle their own locking (one reason they require so
much memory). The point is you are still likely to get inconsistent
versions with NetBIOS/TCP as your file sharing mechanism. It is
not clear to me that an incomplete, memory hogging, broadcast based,
transparent environment is less complicated than simply explictly
transferring files with a mechanism like FTP or FTAM. Don't listen
to me though, I wasn't able to figure out what a PS/2 would buy me
either and do my development work on a Compaq, you see, I have already
missed the boat :).
Stephen Northcutt (firstname.lastname@example.org)
Disclaimer: I have no financial ties with any commercial vendor mentioned.
I am NOT against transparency. I haven't even given up on NetBIOS
(should the OS/2 extensions prove to work out). It is simply my
personal opinion that NetBIOS/TCP for DOS is not a workable solution.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:57 GMT