Larry Backman (firstname.lastname@example.org)
8 Nov 88 12:40:42 GMT
In article <8811010516.AA05874@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes:
>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?
>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
An individual employee of a vendor's view:
I've implemented NETBIOS on top of ISO as both a host based and
board based protocol under both DOS and OS/2. Observations:
1). The board is 8 Mhz. 80186 based; the board based protocol
is 50% as fast as the host based protocol.
2). The host based protocol takes up 128K of space under
both DOS and OS/2. The board based protocool takes up
less than 10K of space.
3). The board based protocol can support 32 sessions easily;
the host based protocol can support at most 8-16 sessions
before needing another 64K of memory for data buffers.
1). Under OS/2 you want a host based protocol for performance;
under DOS you want a board based protocol for memory.
2). Future DOS NETBIOS protocol stacks will be more cognizent
of Expanded memory version 4.0; there is no reason why
a 128K driver can't use 64K of DOS memory for code, and
a large chunk of expanded memory for data; this would
save valuble DOS memory, and also allow more data buffers;
i.e. more sessions.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:44:29 GMT