Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!nic.csu.net!beach.csulb.edu!csus.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!newsun!keith From: keith@ca.excelan.com (Keith Brown) Newsgroups: comp.dcom.lans Subject: Re: NetWare Driver Standards Keywords: Novell Message-ID: <1991Mar5.230910.6786@novell.com> Date: 6 Mar 91 07:45:31 GMT Sender: news@novell.com ( Lines: 77 The News Manager) Nntp-Posting-Host: ca Reply-To: keith@ca.excelan.com (Keith Brown) Organization: Novell, Inc. San Jose, California References: Distribution: comp Date: Tue, 5 Mar 1991 23:09:10 GMT In article martino@logitek.co.uk (Martin O'Nions) writes: >This [the packet driver] technique is not directly compatible with Novell's >ODI standard, Although it is not directly incompatible with it either! The ODI is more of a "true" link layer API than either the PD or NDIS/APIs. It understands link encapsulation protocols and does a very good job of concealing them from overlying protocol implementations. A good example of the value provided by an interface such as the ODI can be found in our new version of The LAN WorkPlace for DOS (our TCPIP product for DOS PCs, which uses the ODI). It contains a single binary TCPIP.EXE TSR which is capable of running over Ethernet, Token Ring and Arcnet medias. All you have to do is switch the underlying ODI driver to support the hardware/media combination that you have. There is no overhead in the TCPIP.EXE to support all these medias. The media support is down in the ODI driver. This is in contrast to DOS TCPIPs that use the packet drivers. They have to ship different TCPIP TSRs for each media that they support (thats how they avoid overhead). I'm not implying one way is better than the other of course. It really amounts to two different ways of accomplishing the same end. Personally, I leave my own prayer mat in a locker at the temple of the ODI. Some leave theirs in the temple of the Packet Driver across the street. The vast majority of our customers don't go to church, they just want to get useful work done! >by the packet IPX, but this does not restrict access to NetWare 386 servers - >it merely means that some of the new driver features are unavailable. Specifically, the packet drivers don't allow you to use IPX over a couple of encapsulations that we support through the ODI. Packet driver users tend to run IPX on Ethernet II ("ECONFIG"d in NetWare 286 parlence). The support for "traditional" IPX on raw 802.3 is a little untidy within the PDs. In fact Russ Nelson, the Arch Deacon at the temple of the Packet Driver, forgot to lower his undercarriage while trying to land the IPX/802.3 support in release 8.0 of the things. I believe he's rushing for the fire extinguishers even as I type. > >Novell have stated a number of times that they regard ODI as the way ahead, >and refuse to make use of the NDIS specification in their standard releases. As I've stated in previous postings, an ODI driver for the NDIS "board" isn't a completely stupid idea. Niether is one for the PDs. The ODI adds value on top of both of these pieces of software and so an ODI driver for NDIS would in fact be more than a worthless converter "kludge" sitting taking up memory. Maximum performance would usually be obtained via a "straight to the metal" ODI driver, but producing ODI drivers for NDIS and the PDs might appease worshippers at the other temples and prevent a holy war breaking out. > >If anyone out there would like to expand on this, I'm always interested in >new info. (or corrections........). Are you joking? This is one of my favorite subjects! >P.S. Novell's comment on the one-sided NFS release is that it is designed >to permit Unix client access, and is consequently more like the Macintosh >support, where the server mimics the client's native networking system, >than a full integration tool. Roll on phase II. We already have two ways of providing transparent file services from DOS PC's to UNIX systems. One is called Portable NetWare and the other is to use the LAN WorkPlace for DOS in conjunction with Beame and Whitesides NFS client software for our transports. You want another? Jees, some people are never happy :-) Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM