HDTenEightyP/NetNews huggingface dataset:
From: eengelke@steam.uwaterloo.ca (Erick Engelke)
Subject: Re: Socket Libraries for PC compilable with Borland C/ C++
Organization: University of Waterloo
Date: Tue, 1 Sep 1992 15:02:26 GMT

 sbjie@engr.psu.edu (Sanjay Joshi) writes:
>
>Are there any public or commercial socket libraries available that will
>compile using Borland C and or C++ ??
>
>I did get some info from FTP Software INc., in thier info packet is says 
>that the libraries are MIcrosoft C libraries.  Has anybody been able
>to compile and link these with Borland C ?? Are there any other vendors
>out there who wouls supply these libraries.
>

FTP provides C source so you can make any necessary changes.  I think
recompiling is all that's necessary, but I can't remember.

Beame&Whiteside provides C source and it compiles for BCC without problem.
The only downfall is that it's BSD 4.1 emulation, not 4.3.

Novell LanWorkPlace and Sun PC/NFS do not come with source so you will
be linking with Microsoft libraries.  This is not difficult except they
use different 32 bit shift, mult and divide functions which you must
get from someone with microsoft libraries.

Freeware?  Phil Karn's NOS is ftpable from ucsd.edu (but only usable for
private individuals and educational institutions) and my WATTCP
is ftpable from sunee.uwaterloo.ca in pub/wattcp/wattcp.zip (but it
is not quite BSD-ish).

BTW, I don't know if I mentioned this on earlier posts, but BSD emulation
libraries usually do not use identical function names, you will still have
to recode slightly.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
From: mih@eng.ufl.edu (Marc Hoit)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Packet driver for Lantastic card
Date: 4 Sep 92 17:39:37 GMT
Article-I.D.: eng.mih.5.0
Organization: University of Florida (ECS-DS)

Does anyone know if there is a packet driver for the ethernet card sold with 
Lansastic?  Or what it's functional equivalent is ?  (I have all the 
Clarkson drivers but don't see it there)  Mabey who makes the card for 
artisoft ?

thanks

Marc Hoit
mih@ce.ufl.edu
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: FTP PC/TCP as transport for eXceed Plus
Date: 1 Sep 92 17:05:23 GMT
Reply-To: jbvb@ftp.com
Distribution: world
Organization: The Internet


    I am using FTP's PC/TCP as a transport for exceedp Plus (X11 server for
    DOS). When I have exceed plus logging transport errors lots of the
    following error messages are logged:
    
            Read error 19 on socket N
    
If that's the INT 61h API error code (as opposed to 4bsd sockets), it is
NET_ERR_EOF, and indicates that the foreign host has closed its side of
the TCP connection (e.g. sent a FIN), such that data can't be read any more.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488
*note new address & phone*
From: DMPM@mc.duke.edu (James Dryfoos - Postmaster)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Needed:  NDIS -> ODI driver? (thanks DEC).
Date: 31 Aug 92 15:30:44 GMT
Distribution: world
Organization: Duke University Medical Center, Durham NC, USA

Help.

I now need to run NDIS.  Already have mix of packet driver and ODI.
Am now running ODI as the base.  Is there an NDIS to ODI hack around?
Any other suggestions of how to use all three?  Blah.

Thanks in advance,

Jim
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: dale@manet.wustl.edu (Dale Frye)
Subject: Re: LPD for IBM PCs
Reply-To: dale@manet.wustl.edu
Organization: Washington University, School of Engineering, St. Louis MO
Date: Tue, 1 Sep 1992 15:13:39 GMT

In article <16851C670.PA9690@utkvm1.utk.edu> PA9690@utkvm1.utk.edu (Alan  
Luchuk) writes:
> Can, and would, someone please direct me to sources for LPD programs for  
IBM
> PC's or PS2's?   We prefer for-sale vendor-supported products.
> 
> Are special purpose devices available that do LPD?  Something that plugs  
into
> an Ethernet on one side and a printer on the other and doesn't require
> additional software/hardware.  If such a device exists, where can I get  
one?

Call Beame&Whiteside and ask for a free fully functional demo disk. It
does everything just has a timeout. They have a LPD that will support
multiple printers on one PC. (Windows required for multiple printer  
support.) It will also provide multiple FTPd and TELNETd sessions into
the PC (Yes, at the same time!)

Sorry, I'm a little hasty. These are features due out in their next
release (any day now Carl?)

email sales@bws.com

Dale Frye
Washington University in St. Louis
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: bwiner@gabriel.carleton.ca (Bruce Winer)
Subject: PCROUTE 2.24 and Token Ring
Organization: Carleton University
Date: Fri, 4 Sep 1992 14:48:43 GMT


The latest PCROUTE includes packet driver support. Does anyone have
experience using this interface? In particular, has anyone tried to use
the packet driver interface to route between token-ring and ethernet?
Experiences, musings and speculations all accepted .... 

Thanks, 

Bruce Winer                         | Internet: bwiner@ccs.carleton.ca
Faculty of Social Sciences          |
Carleton University                 | Tel: (613) 788-2600 ext. 3919   
Ottawa, Ontario, Canada K1S 5B6     | Fax: (613) 788-3742
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Question:  using QEMM and packet drivers simultaneously
Date: 2 Sep 1992 15:23:42 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <1992Sep2.135723.2437@tamsun.tamu.edu> sam3103@tamsun.tamu.edu (Stan McClellan) writes:
>I hope this isn't a FAQ  8}

It is, but it's not listed in the FAQ file because there isn't one.  :-)

>Whenever I specify the RAM command line switch for QEMM (which is supposed
>to make hi RAM available for loading TSRs, etc) I can't load the packet 
>driver properly ... the keyboard locks up.

Use the exclude option to make QEMM aware of the network card's address
space.  The same goes for EMM386 and any other memory manager, including
Windows.

-- 
"Beware of programmers who     Stephen Trier
 carry screwdrivers."          Network Services Engineering, IRIS/INS/Telecom
       Leonard Brandwein       Case Western Reserve University
                               trier@ins.cwru.edu
From: tto@aspentec.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Problem with Pathwork sockets
Date: 31 Aug 92 11:31:41 EST
Distribution: world
Organization: Aspen Technology, Inc. Cambridge, MA.

I have read some news articles regarding problems with Pathwork TCP/IP's socket
library.  Here's my share of woes:

Our company has an application that uses sockets to open a telnet connection
to a host.  This application runs well on several different sites but fails
rather frequently on a particular client's.  It seems that the host sometimes
takes an unreasonable long time to respond to a simple command.  I decided
to log the characters that were actually sent and received.  It turned out
that in these occasions the command was not echoed for a long period of time.
It looked as if the socket procedure send() were faking sending characters:
it would return 0 but store up the characters in an internal buffer and send
them at a later time.  (Note that the delays were way beyond normal TCP
timeout periods.)

I am using...
  SOCKTSR.EXE "3Com SOCKETS (1.1)"  (I have also tried 1.2)
  TCPTSR.EXE "3COm DOS Unloadable TCP/IP Protocol Driver 1.2"
  TCPDRV.DOS "3Com Resident TCP/IP Protocol Driver 1.2"

Here is some related info:

3COM wrote the socket library; DEC only licensed the binary (and not the
source).  After a lot of phone calls and delays, I finally got someone in
DEC who promised that he would try to get the info from 3COM to help solving
my problem.

Does anyone has any insight?

Tak.
-----------------------------------------------------------------------------
Tak To                                                    (617) 497-9020 x377
Aspen Technology, Inc                                Fax: (617) 497-7806
243 Vassar St, Cambridge, Ma 02139.                       tto@aspentec.com
-----------------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: TSRs ...
Organization: University of Waterloo
Date: Wed, 2 Sep 1992 19:28:06 GMT

 tto@aspentec.com writes:
>eengelke@steam.uwaterloo.ca (Erick Engelke) writes:
>
>> use a malloc(), a definate no-no in tsr development!
>
>Yes, many developers have no idea how to do things properly in the DOS
>environment, let alone making programs suitable for a TSR.  E.g., Sun's
>PC/NFS uses malloc() and DEC's Pathwork TCP/IP (written by 3Com) traps
>INT 2F (AX=1122) and promptly undoes itself whenever one issues an
>INT 21 (AH=31) to terminate and stay resident!
>

HP and 3com co-developed that product and it seems to have Microsoft
involved somehow.  Since I've only dealt with the tech staff, we were
all quite uncertain how many lawyers it takes to write a network stack.
 
Anyways, it's a bit of a challenge to TSRize their programs.  You must
write a function with the same name as their function which intercepts
the int 2f interceptor to prevent this from happenning.  That one caught
me by surprise too.  But I didn't think it was widespread enough
a system to comment on it, but it took me a day to figure out.

>> [ftp's] internal API can be called practically any time.  
>> Compeditors systems which only provide the BSD-ish interface 
>> can rarely be called during DOS i/o, and sometimes have difficulty
>> when called during interrupt calls.  
>
>Another nice thing about FTP's PC/TCP package is that it allows an easy
>access to the global file descriptors.  With other packages one has
>to do more work in order to share a descriptor among several applications.
>(By the way, sharing file descriptors is one of the few things that can
>be done more easily on DOS than on Unix.)
>

Yes, most of the others require you to change your PSP back to the 
originator's.  That's easy enough when they provide source, but the 
one's that don't are a true headache because you have to reverse engineer 
or run through hoola hoops just to do shared access.  I don't mind
doing the work, but when it cuts into processor performance or carves
out more memory, I start looking at new solutions.

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: alistair@microsoft.com (Alistair Banks)
Subject: Re: Named Pipes
Date: 04 Sep 92 02:43:49 GMT
Organization: Microsoft Corporation

In article <9209021556.AA06310@ftp.com> jbvb@ftp.com writes:
>
>    .... Still, this leaves the question, where are the RFC 1001/2 equivalents
>    for doing Named Pipes on TCP/UDP? Not worth the effort??
>
>My personal opinion (which may be from way out in left field, since I've
>not done any actual named-pipes applications) is based on my understanding
>that Microsoft based named pipes on a Netbios-style flat namespace, with
>broadcast name defense implied.  This works badly in an internetworking
>environment, just like Netbios.  I think you can run at least some
>named-pipes applications with a glue layer that thranslates to Netbios calls,
>and that appears to be satisfying whatever demand there is...

The NamedPipe semantics don't assume flat namespace - they're simply an
IPC mechanism with a namespace that's part of the filesystem namespace. In
LanMan for OS/2 & MS-Dos they were based on the SMB protocol on top of
Netbios, but Novell implemented the same NamedPipe APIs to their SPX
protocol, and Banyan to Vines.

NamedPipes are only "another" high level, convenient IPC mechanism. The
advantage in  the LanMan implementation, was that being implemented on
top of SMB, they were authenticated in the same way as file access

A major disadavantage in both MS-DOs & OS/2 implementations is that the
NamedPipe services are supplied by a single .dll, which makes the
co-residence of multiple implementations very hard

In Windows NT, NamedPipe services are provided by a FileSystem driver, like
any other file system driver, so while the SMB-based/LanManager NamedPipes
are built in, its hoped that the Novell/SPX and Banyan/Vines versions will
co-exist. It would probably be possible to implement NamedPipes with some
glue onto tcp/ip in the same style as Novell & Banyan

I'm not about to enter into "the universal IPC mechanism" debate! NamedPipes
is just another pretty convenient one, from my point of view, if you dont
implement it on top of a secure protocol (and of course MailSlots is the
datagram partner API to session-based NamedPipes)

-- Alistair
From: JOCELYN@novl1.ci.cuslm.ca (Jocelyn Nadeau)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: pc-route/pc-bridge, suggestions wanted
Date: 4 Sep 92 15:55:34 GMT
Reply-To: jocelyn@cuslm.ca
Organization: Centre univ. Saint-Louis-Maillet

Bonjour Gary,

I am running PcBridge and PcRoute all over the place around here.

I have a PcBridge over leased lines running to link a remote site.  TCP/IP
works fine but a little bit slow.  Novell is a pain.  Not to bad for
copying files, printing or email but just too slow for running remote
application (even login!).  Mind you, the leased line is only running at
9600.

I have PcRoute configured to route IP and bridge IPX between 2 or 3
ethernet interfaces.  Once it is up and running, it runs and runs....

I also have PcBridge configured to bridge between 2, 3 or 4
ethernet interfaces.

And finally I have a PcRoute AppleTalk-IP gateway up and running.

Salut

Jocelyn
------------------------------------------------------------------------
Jocelyn Nadeau                                   Jocelyn@cuslm.ca
Centre universitaire Saint-Louis-Maillet         506-737-5050 ext 5277
Edmundston, NB Canada                            fax 506-739-5373
E3V 2S8
------------------------------------------------------------------------
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: "Tony C. Cheng" <tcheng@bronze.ucs.indiana.edu>
Subject: Looking for a driver...
Organization: Indiana University
Date: Sat, 29 Aug 1992 13:25:50 GMT


I'm looking for a PD driver for NE2000 to work with AT&T Lan Manager.  
Any info. will be appreciated.

_Tony C. Cheng
From: mcentral@netcom.com (Media Central)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: PC <-> UNIX : Any suggestions ?
Keywords: WINOWS PC UNIX NETWORK
Date: 2 Sep 92 22:25:44 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


Hi,
Iam a Systems administrator on a SUN machine. I have to connect  PC running
MS-Windows to the UNIX box with the following objectives:
	a) telnet,ftp etc
	b) access mail from the UNIX server
	c) access netnews from the UNIX server

Since I dont know anything about networking on a PC, I will be needing
all possible info on this subject.

Thanks a lot,

shahid ahmed.
From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Eight bit characters with CUTCP?
Date: 2 Sep 1992 15:20:21 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

In article <MARK.92Sep2124640@gopher.dosli.govt.nz> mark@gopher.dosli.govt.nz (Mark Wright) writes:
>When the application is accessed via cutcp, it looks to me like the eighth bit
>is being ignored (I get text instead).

CUTCP uses a strict interpretation of both the VT102 and Telnet specs.  The
Telnet spec says a telnet connection is seven bits only unless Binary mode
has been negotiated, while the VT102 docs say that a VT102 can only handle
seven-bit data.

>Anyone know of a way to get eight bit graphics with cutcp? I can't see
>anything about it in the documentation.

No.  You have to understand that there's more than one "eight bit graphics"
character set, too.  Which one do you need?  Do you want ISO 8859-1, IBM
Code Page 437, DEC Special and Graphics characters, or something else?

In other words, the way the extra 128 characters is implemented will vary
depending on what the program author is trying to do.  In CWRU-PC/IP Telnet,
I chose to implement eighth-bit-set characters in a flexible manner, but
the default configuration is ISO 8859-1.

>Are there any pc implementations of tcp-ip that support eight bit characters?

Yes.  CWRU's supports eight bit traffic, and I believe Kermit does, too.
I'd be surprised if WATTCP's INT14 redirector did not, although you will
have to find an eight-bit-capable term program to run on top of it.

-- 
"Beware of programmers who     Stephen Trier
 carry screwdrivers."          Network Services Engineering, IRIS/INS/Telecom
       Leonard Brandwein       Case Western Reserve University
                               trier@ins.cwru.edu
From: jim@CAI.LSUC.ON.CA (Jim Mercer)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: [Help] Working example of BootpTab file for KA9Q, anyone?
Date: 3 Sep 92 23:17:13 GMT
Distribution: world
Organization: The Internet

> The KA9Q documentation does not say much about the Bootptab file. Looking
> at RFC951 and RFC1048, I tried a couple of permutations, but I still don't
> get the bootp server to allocate the desired ip numbers to the specified
> hardware addresses. It works OK for dynamically assigning numbers from a
> range, but those addresses can disappear when KA9Q is re-started. So, would
> someone with a working (non-trivial) version of the bootptab file for NOS
> 910612 please mail me? Thanks in advance...

i discovered the same thing about gateways and such in ka9q's bootp response.

the way we "fix" it is by specifying the gateway in the config.tel file for
ncsa/cutcp, or whatever stack you are using.

here is a snippet from our autoexec.net and bootptab files:

autoexec.net:
---------------
arp add 142.57.2.255 ether ff:ff:ff:ff:ff:ff
arp add 142.57.3.255 ether ff:ff:ff:ff:ff:ff

bootpd dns 142.57.1.1
bootpd logfile bootpd.log
bootpd logscreen on
bootpd start
---------------

bootptab:
---------------
logscreen on
dns 142.57.1.1
host pc-aa.sg.lsuc.on.ca Ethernet 00:00:c0:b5:34:2b 142.57.2.2 keith
host pc-ab.sg.lsuc.on.ca Ethernet 00:00:c0:e9:2a:1c 142.57.2.3 jim
host placeholdend Ethernet 00:00:d0:00:00:d0 142.57.99.99 none
start
---------------

the bootptab file is loaded into ka9q by the "bootpd start" command, and
internally it is as if each line in bootptab was typed at the net> prompt
prepended with a "bootpd ".

our bootptab file contains entries for subnet 142.57.2.0 and 142.57.3.0

142.57.2.0 is pc's attached to novell, using ethernet, packet drivers and
talk to an econfig'd novell server.

142.57.3.0 is pc's connected using Starlan 1Mbit, using the IPXPKT packet
driver.

the config.tel file lists 142.57.2.1 as the primary gateway, and 142.57.3.1
as the secondary gateway.  (although i think the starlan PC's actually use a
config.tel which lists them in the other order).

i know it looks like some duplication, but, hey, it works.

if it ain't broke, don't fix it.  8^)

-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!uunet.ca!lsuc!jim  +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA  ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]
From: msr@oliafd.shel.isc-br.com (Michael S. Romaniw)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: WinQVT/Net and LanManager not cooperating
Date: 27 Aug 92 18:42:19 GMT
Organization: Olivetti Advanced Finance Development

Hi,
	I can't seem to get QVTnet running with along with LanManager.
It always responds to it's own ARP and then complains about a conflict
with itself.
	
	Currently running:
		Windows 3.1
		LanManager 2.1 (NETBEUI...no TCP)
		QVTNET27
		DIS_PKT9.DOS Packet Driver
		PKTINT       shim

There are no RARP servers running anywhere.  

QVT runs fine without the LanManager installed.

Any ideas ?

Mike Romaniw - Olivetti Systems and Networks Advanced Finance Development 
2 Enterprise Drive, Shelton, CT 06484-0868  (203)337-1407
Internet:  msr@oliafd.shel.isc-br.com
From: fit106@mis.csiro.au (Kent Fitch (Project Computing))
Subject: tn3270 and microtn - NCSA source and versions info reqd
Summary: NCSA telnet and microtn source reqd
Keywords: ncsa telnet tn3270
Organization: CSIRO DIT (Melb.)
Date: 31 Aug 92 23:24:35 GMT

I am investigating adding HLLAPI support to the NCSA telnet and microtn
programs, probably porting them to MSC V6 in the process.  Can anyone tell
me what the latest or best version of these programs are and how to acquire
the source.  Also, anyone's experiences in working with the source for these
programs would be appreciated.

Kent Fitch
Commonwealth Scientific and Industrial Research Organization (CSIRO)
Canberra
AUSTRALIA         Kent@its.csiro.au
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: airon <airon@edm.isac.ca>
Subject: Tn3270 Emulator using Pathwork socket library
Followup-To: poster 
Summary: Problems with Pathwork (DOS) socket read
Organization: ISA Corporation, Edmonton, AB
Date: Fri, 28 Aug 1992 11:19:39 GMT


--------------------------------------------------------------------
I have the same problem when using Pathworks for DOS TCP/IP version 2.0.
I have included the first mail that I sent out for your reference.
--------------------------------------------------------------------
*** Previous mail ***

Hi, folks :
I have modified the NCSA Telnet/TN3270 emulation program to work with
Beame and Whiteside TCP/IP socket library and everything works fine.
However, I encountered some problems when I tried to port the program to
work with DEC Pathworks socket library.  It seems that the socket read
function in the Pathworks socket library does not clear the internal
storage buffer before each call (by the way, I clear my own storage
buffer before socket read is called each time).  Consequently, each time
the program reads new information from the network, there is some
leftover stuff from previous socket read calls.  This causes the Telnet
negotiaiton for 3270 sessions to fail.  I had similar problems when I
used the same 3270/Pathwork program (running in VT100 mode) to connect
to our Sun 4.

Can anyone help me ?  Here are some details about the program :
  Pathworks for DOS version 4.1
  Pathworks for DOS (TCP/IP) version 1.1A
  The NCSA/3270 program was ported from Turbo C (v 2) to MicrSoft C (v 6)

Please reply to my e-mail address and I will post the summary of
response.  Thank you.

-- 
Airon Y.S. Yiu 		         mail: airon@edm.isac.ca
ISA Corp.			 uucp: !{uunet, alberta}!isagate!airon
Edmonton, Alberta, Canada       phone: (403) 420-8081
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: NDIS (ARRRGGGGHHHH!!!!)
Date: 25 Aug 92 13:19:38 GMT
Reply-To: jbvb@ftp.com
Organization: The Internet


    ....  No problem (or so I thought).  I just downloaded a copy of
    DIS_PKT9.DOS from one of the handy-dandy archives, and installed it as
    per the instructions.

I've seen a report of DIS_PKT9.DOS not working correctly with PC/TCP.  I
haven't investigated, but if you have PC/TCP available, try a copy of the
DIS_PKT.GUP that we distribute (1.30 is shipping with PC/TCP v2.1).  You
could also try the original version of DIS_PKT that we released as freeware
(1.05), which I think can be found on vax.ftp.com.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901